Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rust is younger than Scala. It makes sense for it to still focus on features


But Go has proven that the ecosystem is way more important than the language.

It's time to shift priorities.


Yet it's Go that added big language features recently (generics, iterators, changing semantics of for loop) and not Rust. Rust hasn't gotten any new major features since adding async ~7 years ago. Rust is much more stable language-wise than Go, partly because it had much more features in 1.0, and Go has to gradually add them (what's next? enums?). It also has much more advanced mechanisms allowing to both evolve the language and not break existing code (editions). Things that neither Go nor Scala figured out yet.


Go has proven that people want cheap threads. If it didn't have it, it wouldn't get anywhere.

Now even Java has cheap threads (Loom).

And Go even has generics. Just 20-ish years later than Java. And it's likely that more features that now Java has will trickle into Go. If Go wants to survive.

All this to say that there is no space in the market for another language which is a stupid simple Algol. Go already occupies that space. And even Go will have to add features developers want/need, if it doesn't want to get cornered out of the market.

It's not only Scala that must evolve.


Go has proven that we still need the backing of large corporations for success in the tech world despite the fact that open-source powers most major tech companies today

Java needed Apple, Go needed Google, React needed Facebook, TypeScript needed Microsoft, etc

In this way Rust is actually a pretty unique success story in that there's no singular major tech firm pushing it


> Now even Java

Java is one of the few languages that does have it, besides Erlang, Haskell and Go. That "even" is absolutely not warranted.


> Now even Java has cheap threads

If by "cheap threads" you mean M:N threads a.k.a. fibers/green threads, Java had that on Solaris well before Go.


That's not even remotely the same thing as the current virtual threads, that automagically turn (many kind of) blocking IO into non-blocking.


If "automagically" means "the way Golang does it" then that's kinda the whole point of M:N threads/fibers.


My point was that green threads are not at all the same as virtual threads.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: