When Rust Makes Sense, or the State of Typed Languages (2015) | Hacker News Reader

When Rust Makes Sense, or the State of Typed Languages (2015)

m50d.github.io

5 pointskornish4 comments

This old article seems like it might be a troll by kornish although perhaps not the author. It nearly lost me at referring c++ being niche. I realize I am in a completely different echo chamber being in the embedded world. But c++ is everywhere and spreading. C gets there first but c++ is never far behind. And it is still the default game dev language too. I'm glad I didn't stop reading though. It is a good article. My echo chamber discounts anything with garbage collection as a toy, so it was somewhat of a shock.

Hey, thanks for your comment. FWIW, I also disagree with the portrayal of C++ as niche, which is clearly a preposterous statement to anyone not living under a rock. That said, one poor point does not invalidate the article.

I've been getting into Rust for side projects and was looking to start a conversation about the tradeoffs of Rust vs other languages with robust static type systems.

One conclusion I've come to in my past couple years of hacking on the side - the vast majority of which has been in Haskell, OCaml, Clojure, or Erlang/Elixir - is that there's a niche that's yet to be filled for a language with the following attributes.

1) ergonomic and expressive (so, most likely functional)

2) correct (read: statically typed, good type system), and

3) easily concurrent.

OCaml almost hits the spot but multicore concurrency has been promised forever and still hasn't made it in so my hopes are dwindling. Additionally, the ecosystem is somewhat lacking in places. Rust right now seems to be potentially the best candidate for that language, so I'm looking to see if anyone else has arrived at a similar conclusion.

Anyways, not a troll.

Your list of 3 is filled by Haskell, have you looked into the concurrency options available? If not, there is a good book that you can read online: http://chimera.labs.oreilly.com/books/1230000000929/index.ht...

I can't really imagine there being an easier way to have concurrency unless it were to be something inherently built into the language (which would cause all sorts of other issues).

As one example from that book: http://chimera.labs.oreilly.com/books/1230000000929/ch03.htm...

In that example, you initially build the program as a single threaded application and can validate that it's behavior is correct. Once you know that it is, you can literally 'bolt on' concurrency without changing the result of the computation.

Reading the whole book is extremely eye opening on what sorts of strategies are available.

Yeah, sorry about that, I've gotten hypersensitive from all the rust hate blogs. It isn't perfect but as you say, it is the best mix for my uses that has come along. My pain points are similar to the article author's. But in addition I have trouble with the way batteries included is implemented. It is still cumbersome to developed without internet access in rust, which is something I do often.

Reply on news.ycombinator.com