
When Rust Makes Sense, or the State of Typed Languages (2015) - kornish
https://m50d.github.io/2015/09/28/when-rust-makes-sense.html
======
galangalalgol
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.

~~~
kornish
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.

~~~
pinkythepig
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...](http://chimera.labs.oreilly.com/books/1230000000929/index.html)

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...](http://chimera.labs.oreilly.com/books/1230000000929/ch03.html#sec_parlist)

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.

