Nim is very attractive to a previous CoffeeScript user like me. I used it to build my own [ClojureScript clone](http://calcit-lang.org/), but finally found I really want ADT and pattern matching, which drove my to Rust.
Object variants could support this need. But I was already amazed by those Haskell features.
> I really want ADT and pattern matching
I feel like many people go to the Rust bandwagon for the wrong reasons while mosts would benefit more from a higher level and more expressive language such as scala 3
Not much, I would say. Something important in CoffeeScript is "everything is an expression". That was a feature in Lisps, in Haskell, in Rust, but would never be default behavior for JavaScript. JavaScript is becoming less odd with modern features, but still far from being liked.
a bad aspect of CoffeeScript I see is "it's not an industry language". too flexible, insufficient integrations with standard tools, slow fixes and new features. The industry definitely need as lot of features for pushing and also controlling work.
CoffeeScript's syntax make a lot more sense than ES6, and CoffeeScript 2 compiles down to ES6 primitives. It's a shame that it's usage is pretty low in the industry.
Having a single Result type as standard has a huge benefit. You can do error handling for every library you use in exactly the same way. You also get decent stack traces because the runtime can reason about a single error type. Unified error handling is, IMO, necessary for making a language a pleasant experience.
Is it Rust's static lifetime constraints? Is there some feature you would miss if you used Nim instead? Or would you prefer to use Rust because more organisations are using it?
It's interesting to know what the perceived weaknesses and strengths are. Nim does have pattern matching but it's rarely used, whereas it seems to be used a lot in Rust (probably because of the prominence of enums). Nim has static lifetime management, but it's mainly used for eliding and thread safety (for now). Traits are an interesting feature, and make a good example of why I'm so bullish on Nim: someone has already replicated them with a macro: https://github.com/haxscramper/nimtraits
The popularity critical mass thing is mainly getting eyes on the language, but I think Nim has a slight advantage in that it's incredibly cooperative with its compile targets and FFI. Like Python, it's great for good glue code and 'scripting' without the performance penalty, and I hope that helps it meld into people's toolboxes over time.
Nim's concepts [0] are sort of like Rust's traits or Haskell's typeclasses - maybe more expressive in some ways. Pattern matching can be added on as a simple library and has been done several times, maybe most pedagogically outlined here [1]. Lifetime annotations just seem unproductive to me. Nim with ARC/ORC does have safe [2], automatic memory management without "a GC" or need for lifetime annotations.
Lel 1) JVM languages can compile to ELF binaries with GraalVM 2) lifetimes are an antifeature that is not needed outside of niche performance critical purposes. Moreover in the real world it's much easier to produce slower code in low level and non gc based languages. Btw I'm pretty sure SOTA latency critical GCs such as ZGC (<0.1ms max pause time) has outperformed non-gc memory management for latency critical workloads.
More importantly the jvm ecosystem has received order of magnitude more resources at optimisation for complex needs (drools,lucene, the whole Apache empire, etc)
Rust is a joke compared to Scala featureset.
Object variants could support this need. But I was already amazed by those Haskell features.