3 ms·

> If you are a systems programmer, if you are used to C and C++ and to trying to solve systems programming types of problems, Rust is magical, just like when yo

> If you are a systems programmer, if you are used to C and C++ and to trying to solve systems programming types of problems, Rust is magical, just like when you learned your previous favorite programming language. Ok... > If you are not, Rust is overkill for your task at hand and you shouldn’t be using it. I earnestly recommend Haskell. That's... unusual advice. There's a lot to be learned from Haskell, but if I was recommending languages for the application space, there are other languages I might mention first.

choeger 5y ago
Haskell has the downside of being lazy and thus very unintuitive. OCaml, with multicore might be a better choice, if the community gets a tad more vibrant. But in general, I get the sentiment. For high-level projects, use a high-level language. And if you look at the sad state of js, python, et. al., there is plenty of room for improvement. Maybe it would even work if someone strapped Rust's type system on go or go's GC on Rust.
- jll29 5y ago
  I had to (ask my team to) port a system implemented in Haskell to Java because we couldn't find knowledgeable developers (people who knew Haskell + NLP). This was around 2006-7, not sure if it changed since. Any important codebase should rely on a language for which sufficient talent and community support (StackExchange...) exists, otherwise you add yet another risk to your project.
  - choeger 5y ago
    Wait a second. Your team was capable of porting from Haskell but incapable of maintaining an existing Haskell code base? Are you sure they just didn't want to use Java because of their own personal reasons?
- Zababa 5y ago
  > Haskell has the downside of being lazy and thus very unintuitive. Haskell uses monads for lots of stuff, which can be unintuitive too. From what I've seen, multicore OCaml will allow you to write programs in direct-style (instead of monadic-style) and still be async, which would be great. I hope multicore OCaml will be that "garbage collected Rust" that many people seem to want.

choeger 5y ago

Haskell has the downside of being lazy and thus very unintuitive. OCaml, with multicore might be a better choice, if the community gets a tad more vibrant. But in general, I get the sentiment. For high-level projects, use a high-level language. And if you look at the sad state of js, python, et. al., there is plenty of room for improvement. Maybe it would even work if someone strapped Rust's type system on go or go's GC on Rust.

jll29 5y ago
I had to (ask my team to) port a system implemented in Haskell to Java because we couldn't find knowledgeable developers (people who knew Haskell + NLP). This was around 2006-7, not sure if it changed since. Any important codebase should rely on a language for which sufficient talent and community support (StackExchange...) exists, otherwise you add yet another risk to your project.
- choeger 5y ago
  Wait a second. Your team was capable of porting from Haskell but incapable of maintaining an existing Haskell code base? Are you sure they just didn't want to use Java because of their own personal reasons?
Zababa 5y ago
> Haskell has the downside of being lazy and thus very unintuitive. Haskell uses monads for lots of stuff, which can be unintuitive too. From what I've seen, multicore OCaml will allow you to write programs in direct-style (instead of monadic-style) and still be async, which would be great. I hope multicore OCaml will be that "garbage collected Rust" that many people seem to want.