Learning Haskell before Rust?

is it a good idea to learn Haskell before learning Rust?

It might be a good platform to understand the concept of functional programming.

Or is it a waste of time and it is better to dive directly into Rust?


1 Like

It’s certainly not necessary, but it might be a good idea depending on your background and goals. Rust mixes a Haskell-style type system with C-style imperative programming. Idiomatic Rust uses a balanced mix of techniques from both programming styles, but you can write working code by leaning heavily on either one.


It is probably somewhat easier to learn Rust if you learn Haskell, but I'm not convinced the advantage is large enough that you should learn Haskell first unless you also have an interest in Haskell directly.


Please don't learn Haskell before Rust. If you do you might come back writing tons of Rust in a Functional style that us normal programmers can't understand.

:slight_smile: Joke. I'm making a little joke. Honest.

By all means learn Haskell first. Why not if you have the time for it?

Conversely I could suggest that it's beneficial to learn, and write a lot of code in C/C++ first. Then you will have a good understanding of stack, heap, memory leaks, null pointer use, use after free, data races, segfaults, randomly corrupted data etc.

That is to say you will appreciate the problems Rust has been designed to solve and how it has chosen to solve them.


I have some experience in C and ASM (mostly embedded projects), Python and Lua. I never got along with OOP in general and C++ in particular.

But I'm still not sure if Haskell is a good idea or a waste of time. I don't think I have any use for it later and the FP paradigm in general is not too hard to understand (but probably hard to master).

I think I will try to understand FP by learning Rust becaus my focus is still embedded programming

1 Like

I don't see the merit in learning C/C++ before Rust. The Rust compiler is your best friend and teaches you about everything you cannot do. It's just a little bit strict.

However, it's much better than the C/C++ compiler with their hands-off learning approach: "Oh, you have a gun pointing at yourself? Well, if you use the trigger, it's not my fault. I told you everything in the standard about what you can and cannot do. If you cannot remember everything, there's nothing I can do for you. Sorry buddy! :wink:" and in the off-chance it gives you a compile error, it doesn't tell you anything useful about the error.

I believe the C in C/C++ is taken from Charles Darwin and those who survived C/C++ switch to Rust in excitement.

There are only few reasons to not switch to Rust:

  • The architecture you're working on is not supported
  • You've reached a venerable age
  • Your boss doesn't allow you to use Rust
  • You develop your own programming language to suit your needs

I was into Haskell before Rust existed (I suppose, don't know when it came out.)

The functional language that Rust seems more obviously related to is OCaml, and that's a fine choice for an intro if you want to go that way. It's a much more practical language in some ways, too.

I'm not sure the similarity to OCaml was an advantage for me, though. While it's good for thinking in functional terms, I don't see that Rust really rewards that so much. Like, would we say it's really natural given a simple problem to write some recursive functions on cons lists? Meanwhile OCaml (and Haskell) have a very different storage model - as ZiCog mentions, there's no stack or heap - and while I've been using C and C++ for many decades, with Rust's superficial similarity to ML it was initially easy to forget that Rust is really a C type language.

I would never say that learning a different way of thinking is a waste of time. Every language has something to offer and the more you know, the more tools you'll have at your disposal for tackling a wider range of scenarios.

When I learned functional programming it gave me a better understanding of how you can transform data and the power of things like recursion and immutability. It also gives you an appreciation for using strong type systems to enforce your business logic and constraints at compile time (the typestate pattern, "Making illegal states unrepresentable", etc.), instead of just adding checks at runtime.

Likewise, when I learned Rust it gave me a better understanding of resource management and ownership, and writing unsafe code taught me a lot more about how computers and programming languages actually work.

I do a lot of C# at my day job and even though it is a very object oriented language, my experience with Rust and way it makes you think about who owns what data lets me create better, more maintainable code.

TL;DR: This is a Rust forum so we're obviously going to be biased and say Rust is definitely worth learning... but you should give Haskell a shot too. Maybe you'll like it, maybe you'll find it cumbersome, either way you'll benefit by exposing yourself to different ways of writing code.

I wrote Haskell for many years before learning Rust. In Rust I'm able to "say everything I want to say, in the way I want to say it", but with C performance, no GC, more memory safety, and smaller binaries.

Rust I would say has very adeptly distilled the lessons of Haskell into a modern language.


Sounds like you are in good shape to dive into Rust.

Like me you have experience of the low level nitty-gritty world of C and ASM, an appreciation of the high level world of Python etc, and were never sold on the OOP everything idea.

Be warned that fighting with the Rust compiler can be very frustrating. But soon you realize it is only stopping you from making all those mistakes that had you made them in C would cause your program to crash and burn and a lot of debugging effort afterwards.

Still, I think having a look into Haskell in your spare time is a good idea. A little bit different view of what a program and programming actually is.

Wait up a minute...

I have reached a venerable age. I switched to Rust after only a week or so of looking into what it was all about. After decades of using languages that implemented ALGOL, badly.

Luckily all architectures I might be interested in have Rust support.

Luckily I am my own boss :slight_smile:

Hmm.. long ago I realized that dreaming up my own programming language, whilst fun to do and implement, is probably not a good idea.


I found that my intuition in rust improved after I had spent some time with C, in some machine programming / operating systems classes. However, I think that's because "knowing" C is mostly just knowing the concepts of how RAM and functions and such works, with C being the equivalent of say, a barebones uncovered car that lets you see how the gears and stuff move around.


Naturally, if you already know a related programming language, that will help you learning your objective Language faster.

But I don’t see how possibly learning 2 languages you don’t know yet could possibly be any faster than learning 1 directly.

1 Like

Well, meanwhile I agree. It doesn't make sense to learn Haskell just to learn Rust.

Thanks a lot

1 Like

Do the opposite - learn Haskell after Rust, if you would still want to master functional programming after getting good in Rust. But I doubt it. As was said before, Rust is pretty balanced. Haskell is a bit extreme for practical purposes.

Another good reason not to switch to Rust is if you don't really need to subscribe to the "I won't use a garbage collector. If you make me do it, I'll hold my breath until I turn blue" philosophy.

There are certainly situations where garbage collectors are not appropriate. But there are also many situations where garbage collection is not an issue. Having written over 10,000 lines of Rust, I can tell you that there is a real price to be paid in doing without one. That price is both the difficulty of learning Rust (I wrote my first line of code in college 60 years ago and I know every program language you can think of, including Haskell, and some you can't, and Rust is the most difficult language to learn that I have ever encountered) and the readability of the code.

There are viable alternatives, such as Go or D or Nim, that are far easier to learn and write and provide performance very comparable to Rust, without the cost of fighting with the borrow-checker or getting into lifetime hell. And the code will be more compact and readable than Rust, especially after rustfmt has gotten its hands on your code and turned it into something similar to "The Long Tale" from Alice in Wonderland.

That is a rather scathing critique of Rust which I'm compelled to provide a counter balance for.

I can't quite match 60 years of programming, having only typed my first line of code into a computer in 1974 but that is longer ago than I care to think about. I have also been around the block with many different programming languages. Despite that I have a rather different experience of Rust.

I will grant you that learning Rust is a bit of a challenge. However I see it as similar to C++ in that respect and not much harder than getting to grips with Javascript or Python proficiently. To me it's a lot more approachable than some other languages, Haskell for example.

In my first year of Rust I have hardly any "fighting with the borrow checker". Certainly one has to organize ones code and data in such a way as to keep it happy. But you need to do that in C/C++ etc to avoid "fighting with the debugger", which is a much more unpleasant and expensive experience. Garbage collected languages save one from that to a large extent, but not always.

Similarly I have not experienced "life time" hell. In a years worth or Rust I don't think I have even one life time annotation in any of my code. I really don't want to see those tick marks uglifying my source.

Likely my solutions would be a bit shorter if they were written in Python of Javascript or whatever, but I don't see that as much of a downer.

When it comes to readability I would say Rust is doing better than C++ and not much worse than languages like Javascript and Python. Arguably having types in Rust makes things a lot clearer than they do. All in all when I stand back and compare my Rust source with other languages it's about a wash for readability.

Having said that, I make a point of writing Rust in such a way that my non-rust using colleagues stand some chance of understanding it by virtue of their experience with other languages, even if they don't know enough to be able to modify it. I don't want to frighten them away with something totally alien looking. Mostly my Rust looks like anything I'd write in most other languages.
(That might upset those who have a thing about "idiomatic Rust", sorry)

I do wonder why rustfmt is upsetting you so badly. Generally it hardly changes my code at all from the way I wrote it. Sometimes I might flinch at some little rearrangement it has made but I let it be, it's not so bad.

All in all, I don't see the price of escaping from the garbage collector with Rust as being that high. And there are great benefits to be had from putting in that little extra effort.

Still, we all have our opinions, formed by whatever experiences we have had.


Actually I was wondering why you included D or Nim as alternatives. Go I can understand but the others are hardly mainstream. Who uses them? For most people the comparisons to GC languages would be to Java, C#, Python, Javascript etc.

In fact I don't see any mention of garbage collection in Nim here: https://nim-lang.org/. Quite the opposite:

  • Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.

Looking at the example Nim code on that page it looks very much like the Rust I write (minus the curlies). Sniffing around Rosetta Code I don't see Nim being more, or less, readable than Rust.

Interesting stuff.

I presume you talk about maximum line length before the formatter begins wrapping them. You can configure that in the rustfmt.toml e.g. via max_width = 120. You can find some more options here:

P.S.: Please, don't derail the topic by starting insignificant discussions like which language looks nicer to you, as that is very subjective and doesn't lead us anywhere, unless you compare to esoteric languages, which are terrible to read by design.

As I said in another post IoT or embedded devices are my primary target. There you don't want to have a garbage collector on bare metal.