To offer a different perspective on the Rust vs Haskell debate, I personally moved the other way around.
I started with Rust, ended up using it heavily in startups for various backend services.
After a lot of frustrations with runtime errors in JavaScript and TypeScript to some extent, I was looking for a language and ecosystem actually designed with static typing in mind and Rust felt like a huge step up.
With no prior Haskell experience, two things made me look for a Rust replacement a couple years in:
For the type of backend services I’m usually writing (live data streams processing, web APIs …), Rust feels a bit too low level. I certainly got used to the borrow checker, to the point were I wasn’t really noticing it anymore, but make no mistake, you will spend a significant amount of time thinking about lifetimes and what type of references to use here and there. This is especially apparent later on, as things need to be refactored. Since what I’m doing isn’t particularly performance sensitive, I felt like I was sort of wasting my time thinking about all these things (seemingly for no benefit).
There’s a clear divide between the sync and async ecosystems in Rust. This is further exacerbated by the fact that there are multiple async runtimes that behave slightly differently. Library authors have to make a choice between sync, async and which async runtime to target. The async ecosystem is still maturing, so there’s currently no async Drop or async Traits out of the box, things usually work differently than in the synchronous world.
In contrast, for concurrent applications, Haskell seems much simpler, there’s only one way to do IO (if you want concurrency, just fork a thread) so some of the footguns are gone and the ecosystem isn’t split like the Rust ecosystem is. The language is obviously higher level so you don’t need to think in terms of lifetimes and references either, but it is still compiled and GHC generates pretty fast code.
All in all, I sort of agree that it doesn’t necessarily make sense to “compete” with Rust for performance sensitive applications.
… But at the same time, because Rust is “newer and cooler”, I feel like it is used a lot in situations where Haskell would do great. Namely, your average concurrent application.
Personally, from a purely technical standpoint, I would default to Haskell for concurrent applications.
And since both languages are FFI-friendly, Rust is actually a great pick to complement Haskell for the performance sensitve corners of a code base !
Having used Go for years in production, I wouldn’t recommend it if Haskell is already an option for you - unless you desperately need a faster hamster wheel (compile times).
I appreciate languages that (try to) make it easier to write correct programs. Go has nullable pointers, no sum types, no pattern matching, non-existent error handling and at the time it didn’t even have generics or a package manager.
It doesn’t really provide anything I’m looking for in a programing language.
It comes with a nice concurrent runtime, but so does Haskell ¯\(ツ)/¯
That is really the only thing it got going for it… (I worked with Go too professionally)
It’s also very easy to make fully statically linked binaries, as well as making it painless to compile for other operating systems and architectures. As much as I’m not a fan of the language itself, within an hour I was able to write an application with a GUI on my aarch64 linux machine, compile it for x86_64 windows, send it to the relevant person and when they went to use it, it worked perfectly.
I just learned about this from the “Certainty by Construction” book:
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.
I’ve been progamming for nearly 40 years now and I have learn (or least checked) pretty much every language you can think of. Haskell seems pretty high to me. However if you find me a new exciting language to learn, I am oll for it.
I’ve found it : after 42m07s he explains why state management is the next fight of moore’s law and after 43m51s Haskell is mentionned as one of the languages that have “suddenly become important because of this multicore problem”.
Pros: The guy is a mentor and argues that only FP can succeed in exploiting multiple cores
Cons: it’s a 2014 talk and we still don’t have 256 cores on every standard laptop - and yes, Rust can also shine at FP
Thanks for the GC argument
@kamek-pf Very detailed and opiniated answer, have my +1
I was the person who made Juspay a successful Haskell company from the technological point of view.
When I came to Juspay in mid 2017, there was some experimental PureScript code that didn’t do anything useful. There was an obvious problem: the lack of overall architecture and design of the Haskell-like project. I, being the author of my Hierarchical Free Monads architecture, and the author of Functional Design and Architecture book, proposed my design to achieve their goals:
allow for less competent developers to write business logic in PureScript
this should not be difficult even for managers to participate in development (and they did!)
connect the logic to the other infrastructure in JS and do this conveniently for the business logic writers
make the business logic testable
…
This is how the Presto.Core Free monadic framework for mobile apps has been born. I designed it using my ideas from the book, and folks from Juspay implemented the connectors to the mobile ui code they had.
Then Presto.Backend was introduced (I participated a lot). It is a PureScript reincarnation of Presto.Core for backends, also uses my architecture.
Then, I and my team created EulerHS for Juspay, a Haskell port of Presto.Backend.
Folks from Juspay were mostly working on the business logic with the tools and project structure we provided them with the frameworks.
This definitely wasn’t “just looked for phrasebooks”, and “just modified code samples”, and “somehow the project worked”.
There were definite challenges that could easily become a stopper for Juspay on the early PureScript ages if not me and my book.
I am doing the very same for my containerized Haskell programs. But it’s a completely different story when you need to bind to glibc, which is typically what you’d expect from a programming language like Haskell with good system programming potential, or simply to write a CLI. If you need to bind to glibc, Haskell suddenly becomes strictly inferior to Go or Rust.
If you statically link against glibc, some function calls will still try to dynamically load certain libraries (for example, things around localisation or domain name resolution), which in turn will try and dynamically load glibc (making it rather pointless to statically link glibc if you know this is going to occur). There are other libcs (like muslc) which don’t have this problem.
The latter, of course. Imagine trying to ship a fully statically linked program that the (Linux, macOS) user wants to just install and run from their machine (i.e. a CLI). I’ve been there. I think it took me more time to build than it took me to write the actual thing.
