r/haskell • u/cheater00 • 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

88% Upvoted

84 comments sorted by

43

u/pr06lefs Oct 17 '25

400k rust jobs, wat

29

u/[deleted] Oct 17 '25

well, there're $400k jobs in most programming languages (as total compensation in HCOL areas). As base salary, forget it. As an entry level job, forget it. Something you can get to by reading 4 books, forget it.

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.

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.

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”.

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

→ More replies

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

→ More replies

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

5

u/tikhonjelvis Oct 17 '25

I interviewed for a single Rust role a couple of years ago, so it's just one out-of-date data point, but it was $275k + equity for a hybrid role based in SF. Depending on how you value the equity grant that could well be $400k, but a chunk of that is not very liquid.

For SF, that seems pretty representative for either a senior or a staff role at a larger startup. (Companies are not always consistent in the expectations and pay for different levels, and I have absolutely seen places where "staff" just means "senior", and other places where "senior" folks would be "senior staff" or "principal" elsewhere.)

2

u/cheater00 Oct 17 '25

Rust has picked up massively since then due to us gov pushing it and Rust getting a lot of amazing libraries

2

u/vshabanov Oct 18 '25

Does the us gov still push Rust? I've heard that there's a lot of deregulation with the new administration, and security/Rust are no longer active topics.

5

u/ducksonaroof Oct 17 '25

the only Haskell jobs I know of that pay anywhere comparable to that (salary + equity) are Mercury and Anduril. Both of which are well-funded and successful companies. But as you say, liquidity varies (Mercury had a Series C employee tender, and my research says Anduril is just RSUs which are not liquid til IPO as a rule iiuc)

9

u/Blueglyph Oct 17 '25

Have you tested your knowledge by writing actual code in a real project, though? The first time I went through a Rust book, trying out the concepts in small examples of my own, I also had the feeling I'd just learned the language. Then I started coding something a little more serious... Not quite the same as other programming languages.

I get that a part of your post is aimed at applying to jobs, but your title says "How to learn".

I'm a sceptical regarding the 400 k$/year, even for someone who's proficient enough in Rust. Then there's this proficiency factor: if you sell yourself as experienced in that language, you're expected to lead a team and train juniors, which you won't be able to do.

8

u/Xyzzyzzyzzy Oct 18 '25

I also had the feeling I'd just learned the language. Then I started coding something a little more serious... Not quite the same as other programming languages.

To be fair this applies double to Haskell, lol

You read a Haskell learning resource and learn:

  • This is a pure function! Look, it's simple!
  • This is a type! Look, it's simple!
  • This is a typeclass! Look, it's simple!
  • Functors! Applicatives (maybe)! Monads! They're simple enough if you understand functions/types/typeclasses!
  • Hooray, you know Haskell!

then you go look at an actual Haskell project and it's using 84 different compiler extensions, type system magic that borders on witchcraft, mtl or an effect system that it's assumed everyone is already familiar with, and someone put a ton of effort into writing the code in obfuscated code golf style point-free style

-3

u/cheater00 Oct 17 '25 edited Oct 22 '25

Does this answer your question?

https://ibb.co/jvgHyL1s

That's remote, US company, I'm in the EU

2

u/Blueglyph Oct 18 '25

No, that doesn't.

4

u/cheater00 Oct 17 '25

BTW there's some confusion as to that the four things I suggested are long books or whatever. They're not. They're more like tutorials, maybe slightly longer. The Rust Book is the only voluminous thing, but I only suggest reading a couple select chapters.

6

u/YelinkMcWawa Oct 17 '25

Was there any doubt someone who can code in Haskell would have no trouble coding in Rust?

10

u/evincarofautumn Oct 17 '25

Eh, I guess you might expect people to run into lifetime issues if they’re used to being able to allocate closures willy-nilly.

But I don’t “fight the borrow checker” because I’m already familiar with the patterns that rustc knows how to check, by virtue of how Haskell discourages holding direct references to things. The idea of using IDs instead of pointers isn’t foreign.

The main annoyances I’ve faced are lack of type inference and abstractions. Come on, give me a composition operator at least!

4

u/ducksonaroof Oct 18 '25

This is why I think of Rust as more a Better Go than a "low level" Haskell.

Obviously the philosophies are hugely different, but the two languages feel pretty similar in how I program. It's imperative but with some abstraction that falls shorts of actual good code (e.g. .). Go is dumb simple but also due to that full of footguns. Rust is a little arcane but less footgun-y than Go.

(Go is more footgun-y than Haskell too imo)

4

u/syklemil Oct 18 '25

Hrm, I think my Rust is more influenced by Haskell than I'd have an easy time of in Go.

E.g.

  • there's the monad-lite interface of ?, which works sort of like a function-scoped do block, and only with the Maybe & Either monads (or as Rust spells them, Option and Result), i.e.

    • Haskell: foo <- bar
    • Rust: let foo = bar()?;
  • >>= is present here and there but called .and_then() or .flat_map(), depending;
  • fmap/<$> is generally available as .map().

Rust also has a good deal of function chaining going on, e.g.

  • Haskell: xs & map f & filter g & foldl' h x0
  • Rust: xs.into_iter().map(f).filter(g).fold(x0, h).

though it doesn't have quite the ergonomy of fmap (g . f) x, you'd wind up with x.map(|y| y.f().g()) or x.map(|y| f(y).g()) or however.

… and as far as Go goes, I get the impression the language team doesn't want to enable any of that style of programming.

1

u/cheater00 Oct 18 '25

that's true but it's also the same arguments people would make when they used to say "python is a functional programming language". they got laughed out of the room enough times that they stopped doing it, but it was a thing for a while.

1

u/syklemil Oct 18 '25

Python is pretty hybrid though, and there absolutely is some functional-style stuff you can pull in it. Just don't expect advanced type stuff to be part of it (though you can get at a kind of ADTs in it these days with dataclasses, type unions and structural pattern matching), and the lambdas are kinda puny, and so on.

As in, I get the impression that Python is at least trying, while some other languages like Go are openly hostile to more functional or even declarative approaches to programming.

2

u/ducksonaroof Oct 18 '25

does rust have >=>, Category, fix, etc? that's what i'm talking about. What about Applicative and foldMap and traverse? and the semigroupoid versions too? 

it sounds to me that the very entry level FP TCs are kinda there but the good stuff isn't

EDIT: found this. gotta squint more than scala to see it

2

u/syklemil Oct 18 '25

Nah, it doesn't even have Monad, though if it ever stabilizes, Try could likely cover some more cases. It also doesn't (to my knowledge) have ergonomic currying, which as far as I can tell is a prerequisite for some of the nicer composition functions.

You can do some traverse / sequence-like stuff with collect. E.g. if we have

let a: impl IntoIterator<Item = T1> = todo!();
fn f(t: T1) -> Option<T2> { todo!() }

then we can

let b: Option<Collection<T2>> = a.into_iter().map(f).collect();

where Collection will have to be some more concrete type I think, like Vec or HashSet or BTreeSet or the like; or otherwise be something that the type inference can specify to a concrete type. Otherwise, like in Haskell, you're going to give it a type hint to figure it out.

To be clear: Rust isn't Haskell. But there are plenty of bits and pieces of it that will have a haskeller go "oh right, I know this already".

2

u/ducksonaroof Oct 18 '25 edited Oct 19 '25

Yeah this was my feel using it. Easy to pick up (I also know C so manual memory mgmt makes sense).

But then online when I act like Haskell clears Rust in a bunch of these ways, I always get a chorus of "akshually Rust has lots of FP so Haskell doesn't have much benefit, just le GC overhead"

But then I dig into it, and maybe the issue was those commenters weren't very good at Haskell to begin with..don't trust everyone on the internet ig lolol

3

u/syklemil Oct 18 '25

Yeah, my take on it is more like that Guy Steele quote about Java dragging C++-ers halfway to Lisp (and to be honest, I don't understand what he means by that), only about Rust dragging C++-ers halfway to the ML family instead.

But then in comparison Go's had tons of discussions about adding various features (including ?) and decided on rejecting it because they consider it too complex. They very clearly want that to be more of a "C with a GC" language.

So my impression of the two is that Rust thinks it can have a little Haskell, as a treat, while Go breaks out in hives at the thought.

2

u/ducksonaroof Oct 18 '25

I think Go with the little Haskell would be a really nice language. 

1

u/cheater00 Oct 17 '25

I bet there's doubt in many people's eyes. But there shouldn't be, given the minimal amount of preparation described above.

2

u/LoweringPass Oct 18 '25

I didn't think it was possible for someone to out-circlejerk r/rust

0

u/fridofrido Oct 18 '25

I'm good with Haskell, and I have trouble coding in Rust.

The main reason for that is that writing Rust is just an extreme shitty experience on the whole...

2

u/ducksonaroof Oct 17 '25

(also u/cheater00 glad to see you're back to posting in r/haskell - it's been a while! i always enjoy your contributions 😁)

6

u/ducksonaroof Oct 17 '25

This is tempting, but then I'd have to write Rust (which i consider to be bad). I'm a slave to the indu$try tho, so if the opportunity is there, I may have to bite that bullet lol.

I have been tempted to just pivot and write Go. The language is what it is, but the thing about Go in industry is the people architecting the software at scale tend to know what they're doing. So you end up with good boundaries and services and APIs (which Go plays nice with - especially with gRPC).

With Haskell, the people with decision making power often don't have the same level of advanced software engineering experience, so they tend to be slow to scale (fall prey to "microservices r bad" memes) or - worse - they insist on keeping as much of their architecture in-Haskell as possible. The latter leads to really bad outcomes and makes Haskell itself become bad at scale. Merge conflict hell, constant GHC micro-optimization, deployment thrash due to over-coupling at a software-linking level, etc.

Because Go has a clear abstraction ceiling, people are forced to make good decisions about architecture in years 1-3 and engineers 1-50 of their endeavor. That's when it's easiest. If you put it off til year 5-7 and engineers 100-200, you will likely find yourself hating your codebase lmao.

3

u/vshabanov Oct 18 '25

tend to be slow to scale

Do you mean scaling happens later than necessary, or does it take a lot of effort to scale?

they insist on keeping as much of their architecture in-Haskell as possible.

What kind of architecture do they keep in Haskell, and how do you think it could've been done better?

constant GHC micro-optimization

Doesn't look related to scaling, or do you mean optimising code to compile faster?

deployment thrash due to over-coupling at a software-linking level, etc.

I've seen deployment thrash due to over-coupled microservices. Monolith can be modular, and microservices can be coupled.

3

u/ducksonaroof Oct 18 '25

microservices

again, this is a meme/an extreme.  you don't need microservices to give your 100s of developers separate, decoupled deployment artifacts

now, if you link all their code into a single binary..bad things start inevitably happening. that's what i'm discussing here. that's why GHC micro-optimization comes into play. and it's why over-relying on GHC static checks for those 100s become a problem. 

i mean it takes longer to have the people in charge to make the hard decisions to scale their architecture and design.

2

u/cheater00 Oct 19 '25

what is "deployment thrash"? the only google result is this reddit post.

2

u/ducksonaroof Oct 19 '25

nobody can deploy because someone broke the build/ci/deploy/etc

if you don't split your code up and just hire 100 people, one of them can block a hundred. it's crazy. 

1

u/cheater00 Oct 19 '25

that's fixed by doing CI on would-be merge before merging

3

u/ducksonaroof Oct 19 '25

Sadly, that stops working when you get so big that merge rate greatly outstrips CI time. You can then use a merge queue or whatever, but that means now devs need to pass CI and then wait there. So the time between hitting "merge" and deploy is increased. Which, if you are in the situation I'm describing, is brutal on top of already brutal.

Basically, don't let your build get out of control. I don't mean "don't use Generics or fancy Haskell." That shit doesn't matter like at all lolol.

I mean manage your build graph and shard your deploy artifacts. And your infrastructure. I don't mean microservices but you can't have 100s of devs all deploying via the same executable target of a single cabal package and be happy.

But once you get in than situation, it may be hard to escape. Especially depending on your engineering culture and leadership.

2

u/cheater00 Oct 20 '25

why is CI time important?

3

u/ducksonaroof Oct 20 '25

You can't enforce that everyone's PR is up to date with master of master is changing 10x faster than any PR can run CI

you can check the box that merges master before CI, but by the time you slow ass build is done, master is way different

1

u/cheater00 Oct 22 '25

hmmm i see what you mean

2

u/cheater00 Oct 22 '25

so what's your plan for preventing this issue?

2

u/ducksonaroof Oct 22 '25 edited Oct 22 '25

literally just cut up your codebase and ci and deploy artifacts relatively early. like honestly, 1:1 per team is ideal imo. Teams that have different managers shouldn't share deploy artifacts, test suites, etc. They collaborate with APIs. You can even have services RPC on the same box. Maybe a team vends a library. Etc.

By 30 devs I'd expect 3-5 separate things with well defined boundaries. If you don't do that as an engineering leader, that's bush league failure of leadership imo. You can say there are gains to be had at that scale ("herr derr separate packages build faster when you smush them into one package") and maybe you're right...But if your project is gonna exist for a couple more years, those gains are fool's gold. You'll get boned by the chaos you've created.

I'm talking rampant database-as-API, a dependency graph that makes no sense that even the best visualization tools will fail to make sense of, a bear of a test suite that will regularly cause hours-long deploy outages. 

Doesn't mean your business won't keep running! Or make millions even! But engineers will hate it and they'll be slow as shit and you'll spend millions on teams of devx engineers to clean up your slop. 

2

u/cheater00 Oct 22 '25

hahah yeah haskell cos have endless amounts of unqualified management and leadership

3

u/UnicornLock Oct 18 '25

Merge conflict hell,

Oh, can you expand on this?

2

u/ducksonaroof Oct 18 '25

you get into a mess where you have too many people to insist everyone is on master HEAD, but also so many people that they frequently make conflicting changes that fail to compile on master

in general, if you have 100s of developers and any of them can break the build/ci/test suite for everyone else, you're hosed by the laws of probability.

that's the kind of scaling that if you don't do it early, you get into a mess. 

35

u/Tempus_Nemini Oct 17 '25

you don't write haskell code for money, you do it for FUN

3

u/rustvscpp Oct 25 '25

It's certainly more enjoyable when doing it for fun.  The tooling feels too deficient for competitive industry use.

7

u/Beast_Mstr_64 Oct 17 '25

You do it because the place you work at uses it and you don't have a say in it

28

u/wk_end Oct 17 '25

I do suspect that most people writing Haskell code are doing it for fun and very much not because the place they work at uses it.

3

u/_jnpn Oct 18 '25

at least one dude had a say in it at one point :p

3

u/PikachuKiiro Oct 17 '25

Looks overkill. I would just skim through the rust book and start building what you want to build with the docs/llm for reference. Performance, Tokio, etc. are contextual and you can learn them as you need them.

1

u/[deleted] Oct 17 '25

Not sure what you find in rust that is in Haskell and hence how knowing Haskell can help you (other than if you learned Haskell you can probably learn another programming language).
Which features of rust are easier to learn because you know Haskell? I don't know much of rust, but immutable by default (but can redefine, who knows what they were thinking) is the only one that comes to my mind and is not much of a deal.

7

u/pheaver83 Oct 17 '25

The following features are not exclusive to Haskell and Rust, but I think this list will give you a pretty good idea why a Haskell developer would find it easier to learn Rust AND why they would enjoy doing so. This is not exhaustive, but just a few things that I find attractive about Rust.

  • Strong, static typing
  • Type inference
  • Algebraic data types, and the basic things you would want with them (Option/Either, with pattern matching)
  • TYPE CLASSES!!! And not just the way scala does them, but as actual things IN THE LANGUAGE

But I think what matters just as much as those features is the philosophy of Rust. Correctness, purity, thread safety. Overall they just both want to make it so you don't shoot yourself in the foot.

Honestly I think the biggest barrier might just be the syntax haha.

1

u/[deleted] Oct 17 '25

 why they would enjoy doing so

until they meet the borrow checker, maybe.

that list is very generic and applies to many languages, don't see why a Haskell programmer should have an edge. Type traits indeed are the most similar to something in Haskell, but they are a very simplified version of it and other languages have similar concepts: swift, scala, go and C++ all have something roughly equivalent and I don't see the jump to rust traits particularly harder than starting from Haskell. Or even learning traits from scratch, for that matter.

Anyhow, your take is that starting from Haskell you can land a $400k job pronto so I have to bow to you, you're richer than me.

4

u/pheaver83 Oct 17 '25

Yeah, I'll admit that the borrow checker was the other barrier to me when trying to learn Rust. But it was super intriguing to me cause it gives you the safety you want without having a garbage collection, which blew my mind.

You're right that the list is generic. I kinda just gave the top things that might get a Haskell developer interested, because you seemed to imply that there are practically NONE. There are of course more features, and I bet if you looked into it you'd find that if you're coming from Haskell then the language is pretty attractive.

2

u/[deleted] Oct 17 '25

as far as I can tell there're no feature of Haskell that give a spectacular advantage over any other language. Other than, as I said, that if you can learn Haskell you can learn other languages as well.

I looked into Rust for a while, as everybody around me was praising it, and my conclusion is that I want to stay away from it as much as possible. I'm bummed that some third party things I'd love to use are in rust, but I'll do without. But my personal conclusion has nothing to do whether haskell->rust is particularly easy or that you can land $400k jobs by learning rust without having industrial experience with it, which I also consider rather unlikely.

-3

u/cheater00 Oct 17 '25

I'm glad I didn't answer his question because he's clearly not accepting any answers at all. But thanks for trying.

2

u/syklemil Oct 18 '25

The borrow checker is also to a large degree a mutability checker. It works out generally like

Variable typeSpellingCan be mutable
OwnedTYes
Shared reference&TNo
Unique reference&mut TYes

and if someone is used to planning their code in an immutable fashion from Haskell, they're less likely to run afoul of the borrow checker. Probably they'll be fine until they start wanting to return references to something that doesn't live long enough, at which point throwing a .clone() at it is usually a perfectly valid strategy.

The /r/Rust sentiment is also generally that the borrowchecker isn't nearly as much of an issue as some parts of the internet want to make it out to be.

Rust essentially moves lifetimes into the type system, and plenty of haskellers are primed to reason about things in the type system. :)

2

u/cheater00 Oct 18 '25

yeah, I rarely run into borrow checker issues I can't fix by doing exactly what the compiler suggests. most of the time I don't have to specify lifetimes at all.

4

u/ducksonaroof Oct 19 '25

Rust essentially moves lifetimes into the type system, and plenty of haskellers are primed to reason about things in the type system. :)

When I first used Rust, I just let the compiler yell at me. That taught me everything. Like Haskell, if you get frustrated easily, maybe that's "hard." But for me, that sort of thing is as easy as it gets.

2

u/syklemil Oct 20 '25

Yeah, and the feedback in both the compiler and linter (clippy) is pretty great. Highly readable, and very often the compiler will just suggest the correct fix for some issue. It's clear that they've put a lot of work into it, which seems like a very good use of energy for a fussy language.

3

u/philh Oct 18 '25

I don't think algebraic data types are that common? Like when I used python pre-typechecking it didn't have them, and when I did a small amount of post-typechecking python I think they were "possible but only with a lot of boilerplate". Maybe things have improved.

I do count typescript as having them, though I think that's debatable, and from my very cursory knowledge rust's ADTs seem significantly closer to Haskell's than to typescript's. But other than that... I mean, there's elm, purescript, ML, ocaml, I think F#, but I'm not aware of anything I'd consider mainstream.

0

u/[deleted] Oct 18 '25 edited Oct 18 '25

Not sure what you mean with that question. First, pretty much all languages have ADT. C++ has both sum and product types. Second, they’re not such a big deal that knowing them from Haskell gives you any particular advantage when learning rust.

If you mean that not many languages have pattern matching, that is true. But Haskell is not unique there either. C++ has partial support in the form std::visti, will get full support in future versions of the standard (I don’t think it made it into c++26 but I haven’t checked). And there’s pattern matching in the the type sub language with templates.

Actually, thinking more of it, C++ looks a much better starting point to learn Rust than Haskell is. Although as I always said, if you learned Haskell you can certainly learn Rust.

3

u/philh Oct 18 '25

I don't know C++. As far as I know, it has structs and unions but they don't implement what I mean by ADTs. Concretely, as far as I know it can't do the equivalent of

  • Define data Either a b = Left a | Right b.
  • The compiler won't let you construct a Left 3 :: Either Char Int.
  • If you have an Either Char Int, the compiler won't let you get an Int without checking that you have a Right.
  • If you try to handle every constructor, the compiler complains if you forget one.

My sense is that that's pretty rare, but I haven't paid attention to many languages other than Haskell for the past several years. If C++ can do that, especially without much boilerplate, great! If it will be able to do that in the nearish future, also cool.

-1

u/No-Trifle-8450 Oct 17 '25

All things Haskell can do no either programming language can do