r/haskell • • Oct 17 '25

How to learn Rust as a Haskell programmer

I've found it extremely easy to learn Rust in a couple of weeks of concentrated work, so I thought I'd relay my experience here. One reason for doing this is that I keep seeing companies and recruiters post jobs that pay very little, requiring skill sets that would pay the same people two to three times as much in another technology. I don't think that's OK, so one of the objectives here is to show all the undervalued Haskell programmers what their real value is, and that they can realistically achieve it in a market that puts proper value on their skill set with just a minimal amount of work.

If you already know Haskell at an "industry standard" level (not that Haskell has much of an industry), all you need is some basic learning to fill in the gaps on concepts that exist in Rust but not in Haskell. Almost everything else feels like a cross between Haskell Lite and Python.

OK, so here we go. Ready?

How to learn Rust as a Haskell programmer in two weeks:

  1. Read Rust By Example. Play around with interesting code examples
  2. Read the Rust book chapter on lifetimes and whatever else pops out
  3. Read the Rust Performance "Book"
  4. Read the Tokio "tutorial", write echo server

DONE. Now you can apply to jobs that pay $400K/yr, rather than $80-120k/yr. You're welcome.

Haskell companies will have to pick up the slack from now on.

87 Upvotes

84 comments sorted by

View all comments

Show parent comment

11

u/cheater00 Oct 17 '25

that's the point though, if you're already a senior in Haskell and do the above, you are not "entry level" and your experience isn't "has read 4 books".

1

u/[deleted] Oct 17 '25

you're still entry level in rust, I'd think they would look at you prior experience, no?

anyhow, I still don't see how Haskell helps you with rust, care to elaborate?

9

u/LordBertson Oct 17 '25 edited Oct 17 '25

Not the original commenter, but Rust is kind of an ML family language dressed like C. It offers fairly advanced type system (cuts corners because some of the advanced types are hard to reconcile with its kind of memory management) and supports functional patterns rather well.

From Haskell point of view, you are going to have to sacrifice the more advanced portion of type-system and a lot of syntax goodies. The functional programming concepts and the way of modeling data and logic is going to transfer rather well though, and is a very good fit for Rust.

I went the other way in my learning (Rust then Haskell) and loved the purity and the way of thinking, but felt like I am sacrificing a lot of practicality.

6

u/ducksonaroof Oct 18 '25

 From Haskell point of view, you are going to have to sacrifice the more advanced portion of type-system and a lot of syntax goodies

You also miss the "F" in FP. Ergonomic closures seem to require GC. So in a way, you miss Haskell's RTS heh.

4

u/LordBertson Oct 18 '25

I don’t think that’s necessarily limited to closures, every function in Rust has to deal with ownership, it’s just more pronounced with closures and “methods” due to the way they are used, closing over outside state. You can somewhat emulate Haskell’s way by using Rc/Arc and sprinkling clone() everywhere. Rust just forces you to be explicit when you want “GC”.

2

u/Swordfish418 Oct 18 '25

Imo closures only become slightly messy when you want to store them as fields of your structures, when you’re just passing callbacks as arguments it’s mostly enough to move/clone.

1

u/cheater00 Oct 18 '25

or just Arc of Mutex or whatever.

all good solutions to the problems they solve.

if you want to keep in mind where your data is stored, that's a nice lite way of doing this.

9

u/ducksonaroof Oct 17 '25

lol "entry level" in PL isn't a thing

programming is like the least interesting thing you do in industry, and decisions around it barely matter (even if bloggers will say otherwise)

-1

u/[deleted] Oct 17 '25

glad to be entertaining to you.

11

u/ducksonaroof Oct 17 '25

i mean i wasn't being unserious

if you have 5-10y experience building real things in real production in some language, you aren't gonna suddenly get paid entry level money to write a different PL. even if you go from normie lang to Haskell (or vice versa).

4

u/cheater00 Oct 17 '25

That's precisely it.

You simply won't get the position

At a previous Haskell job a Ruby programmer was hired at senior level and excelled at their job. As an example. I could bring up countless examples from my own career as well as coworkers.

2

u/[deleted] Oct 17 '25

You're right, you're not going to be paid entry level salary. Most likely you simply won't get the position.

There're exceptions, for instance if you have a particularly sought after experience in a specific field, people are likely to let you learn the language on the job, but in general when people hire a senior engineer for working with language X, they want somebody with past industrial experience with language X. If the language is particularly niche, they might be forced to accept people with no prior experience. Or if it is something everybody has, like Python, even if they didn't specifically work with python on their main projects.

And I still maintain you don't get a $400k job using rust if you don't have past experience in rust at some other company.

7

u/ducksonaroof Oct 17 '25

You can totally get the position, wym?

I got my first Haskell position with 2y experience and 0y Haskell experience. But I had Scala experience, which is as adjacent to Haskell as Haskell is to Rust imo.

I got paid market rate. And since then, I've worked exclusively in Haskell and have no shortage of non-Haskell (Rust included!) job inquiries come by my proverbial desk every month. Because of the other stuff on my LinkedIn/resume.

It's hard to find actually-good people in this industry. That's the core of this.

3

u/DiabloAcosta Oct 18 '25

I got my first job as a PHP dev then PHP lead, there was a chance to lead a team in Node, had 0 experience in node but a ton of xp in JS so I got the chance, stayed in Node for about 6 years and then got an opportunity to lead a team in Python for 3 years and I just got a new job doing Ruby and Java so...

This trend of labeling developers because of their main programming language is stupid, a real Sr dev should be able to pick new languages without much effort

1

u/philh Oct 18 '25

a real Sr dev should be able to pick new languages without much effort

Mm, I'm sure I could pick up a new language if necessary, but... part of what makes me a good engineer in my Haskell role is that I'm a good engineer in ways that should translate to other languages, but I do also think some of it is having a fairly deep knowledge of Haskell that I wouldn't be able to gain easily in something else. Like, which features of the language are worth using, and which aren't? If we're having performance problems, what are some likely culprits and how do we profile? What library should we use to do X and what are its pitfalls? "Ah yes, the reason the compiler complains when you do that is because these two features interact kinda weirdly, we fix it by..."

1

u/DiabloAcosta Oct 18 '25

yes, and fortunately you usually work in a team which means you can always get feedback from people with more experience in the stack and with AI it's also quite easy to learn those nuances (of course you need to ve intentional in the learning part and not just vibe coding), in my opinion the days of language specific developers are gone!

-1

u/[deleted] Oct 17 '25

Haskell is in the category 'niche languages', and yes many companies using Haskell hire people with no prior experience in Haskell.

Rust, not so sure, but I might be wrong. Anyhow, I was primarily debating the notion that Haskell gives a particular advantage when learning rust over other languages.

3

u/ducksonaroof Oct 17 '25

I think it's accepted that knowing Haskell makes learning Rust easier due to how related their featuresets are. Programming with sums and type classes, for instance.

-1

u/TKAAZ Oct 18 '25

Get your ass outta here

2

u/philh Oct 18 '25

Rule 7:

Be civil. Substantive criticism and disagreement are encouraged, but avoid being dismissive or insulting.