Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A couple million lines of Haskell: Production engineering at Mercury

blog.haskell.org

Post reply on HN
Print view View original

211–220 of 249 posts

Re: A couple million lines of Haskell: Production engineering at Mercury

#211

Post by troupo »

dnnddidiej wrote: post #3

I think you have to get a Haskell job early in career and stick to Haskell jobs. Breaking in is really hard as you come without experience there will be plenty of others with Haskell experience to compete. And because the jobs are rare if it doesnt work out (company becomes bad to work for or layoff) you can be unstuck (or I guess you would switch to Rust, Scala or F#)

> you can be unstuck (or I guess you would switch to Rust, Scala or F#)

Yup, I've seen too many of these engineers, trying to shoehorn a poorly thought-out half-working Haskell into every language they come in contact with :)

Re: A couple million lines of Haskell: Production engineering at Mercury

#212

Post by zelphirkalt »

metaltyphoon wrote: post #162
dirkt wrote: post #55

Earlier quoted context omitted.

> works really well in Rust and TypeScript too And of course Rust and TypeScript were heavily influenced by Haskell... they just don't mention it and call things differently, to avoid the "monads are scary, I need to write a tutorial" effect. Though it's less about monads and more about things like type classes. Imitation is the sincerest form of flattery.

> heavily influenced by Haskell... they just don't mention it and call things differently Rust wikipedia says otherwise

Afaik Rust and Haskell both inherited from (S/Oca)ML.

Re: A couple million lines of Haskell: Production engineering at Mercury

#213

Post by markdennis »

isatty wrote: post #53

I don't believe I'm the target market (I'm plenty happy with my small CU), and seeing their billboards makes me want to never use them BUT: seeing this post and their culture and that they use Haskell is kinda changing my mind.

What’s wrong with their billboards?

Re: A couple million lines of Haskell: Production engineering at Mercury

#214

Post by adastra22 »

Darmani wrote: post #98
yobbo wrote: post #94

Earlier quoted context omitted.

If your goal is to translate Haskell (or other garbage collected code) pattern-for-pattern into Rust, you will almost certainly burn out.

It seems to be a common reflex of Rust advocates that, whenever an issue with using the language is asked about, the response is "That's just a garbage-collected code pattern" followed by "and therefore you shouldn't want it." It's happened multiple times in this thread. [Edit: and both the times I was thinking of were from you, so need to weaken that conclusion] Aside from having vibes of "I've chosen to get hit wee…

Rust makes you be explicit about memory management. I guarantee you if you threw everything into a box inside an Arc, your copy closures would have still worked just fine and your Haskell idiom would translate cleanly. Only now everything is heap allocated and reference counted. Before LLMs took over the reins, this was the hallmark of beginner rust code because it WOULD work, just with unnecessary allocations and copying and pointer dereferencing.

Rust makes the tradeoffs explicit, and Rust programmers tend to obsess over minimizing those tradeoffs to get abstractions that are zero-cost. So doing it “the rust way” is often very complicated and tricky to get right while satisfying the borrow checker and type system, but once found is lean, fast, clean, and safe.

Re: A couple million lines of Haskell: Production engineering at Mercury

#215

Post by Weebs »

GuB-42 wrote: post #157

The problem I have with functional programming is debugging. Or more precisely, I would say it is a strength of imperative programming, especially the procedural kind. In functional/declarative style, you generally describe how things should be, not how things are made, and you let the language piece everything together to get the expected result in the end. It is all well and good (and even better) if you did everyt…

A lot of code ends up being easy to factor out into small pieces for tests. I can't speak for Haskell but coming from another ML with eager evaluation step debugging works as you would expect

Re: A couple million lines of Haskell: Production engineering at Mercury

#216

Post by Darmani »

nothinkjustai wrote: post #193
Darmani wrote: post #72

Earlier quoted context omitted.

I have heard this reaction from others before. One of the Rust expert friends I consulted with told me "I'm not convinced you're not trying to write Haskell-style code in Rust;" I told him the patterns I was struggling with were both trivial and common in Java. The things I found quite difficult or impossible in Rust were to me pretty basic patterns for modularity and removing duplication that it's really shocking th…

> Rust afficionados are some combination of people who came to Rust early and never learned traditional software design and don't know what they're missing, and people who were raised on traditional good software engineering but then got hit with Rust's metaphorical baseball bat of lack-of-modularity over and over until they got used to being hit with a baseball bat as a normal pain of life. Oh please. I came to Rust…

I respect that your experience is different.

Please respect the fact that I do not understand how one can like Rust without giving up caring about modularity.

I have pretty good reason for thinking this is a possibility. Directly, because the Rust experts I asked for help did in fact advocate giving up modularity. Indirectly, in that I've seen something similar but much stronger in a different language. That culminated in a conversation with several of the creators of that language, in which they argued their language was great for generic programming...while revealing some pretty basic holes in their understanding of generic programming (while calling me a "Haskell weenie," among other abuse). I am very confident in my conclusion about this other language community and not interested in getting into the details of this event. I am just sharing where I'm coming from, in not immediately dismissing this idea as too absurd to consider even when I have no other hypothesis.

I acknowledge that you feel personally insulted by me having a hypothesis that requires a large group of people behave in ways I consider strange. I have evidence for that hypothesis, and have been unable to find a better one. I hope you can see how the comment I am responding to crosses an extra line and is directly personally insulting.

I would very much like to come away from this discussion no longer believing that Rust programminh is at odds with modularity. I have shared some fairly basic and detailed criticisms, the ones I still remember after a year out of the language. Perhaps your can play a role in offering solutions to them -- or admit that these are indeed problems your hadn't noticed before or had gotten used to

Re: A couple million lines of Haskell: Production engineering at Mercury

#217

Post by wbsun »

> We serve over 300,000 businesses. We processed $248 billion in transaction volume in 2025 on $650 million in annualized revenue

> The system we've built has worked well for years, through hypergrowth, through the SVB crisis that sent $2 billion in new deposits our way in five day.

This is a strange way to describe a transaction processing system with total amount of money it processed. The reliability or scalability is not measured as O(n) dollars. In theory, $248bln or $2bln can be done in one transaction although I know it is not the case in reality. It would be impressive to see the typical system design properties like transactions per second, latency distribution, etc.

Re: A couple million lines of Haskell: Production engineering at Mercury

#218

Post by Darmani »

adastra22 wrote: post #214
Darmani wrote: post #98

Earlier quoted context omitted.

It seems to be a common reflex of Rust advocates that, whenever an issue with using the language is asked about, the response is "That's just a garbage-collected code pattern" followed by "and therefore you shouldn't want it." It's happened multiple times in this thread. [Edit: and both the times I was thinking of were from you, so need to weaken that conclusion] Aside from having vibes of "I've chosen to get hit wee…

Rust makes you be explicit about memory management. I guarantee you if you threw everything into a box inside an Arc, your copy closures would have still worked just fine and your Haskell idiom would translate cleanly. Only now everything is heap allocated and reference counted. Before LLMs took over the reins, this was the hallmark of beginner rust code because it WOULD work, just with unnecessary allocations and co…

Oy. It is also a common experience that, when I struggle in Rust to use a pattern that's common in nearly every other language or find another way to achieve the same goal, people who know of my Haskell background call it a "Haskell pattern," and thereby avoid facing the suggestion that their favorite language is missing some pretty basic affordances.

No, boxing everything does not magically make things more dyn-compatible. It will not magically solve the issue that tokio does a whole-program transformation that does its most restrictive checking only after all local checks have been resolved. It will not magically allow more reuse between datatypes. It will solve none of the problems I encountered... because if beginner-Rust could solve any of these problems, then they would have ceased to be problems for me by the time I became intermediate.

> Rust programmers tend to obsess over minimizing those tradeoffs to get abstractions that are zero-cost. So doing it “the rust way” is often very complicated and tricky to get right while satisfying the borrow checker and type system, but once found is lean, fast, clean, and safe.

You and I must be using very different definitions of "lean." For me, "complicated" and "lean" do not go together

Re: A couple million lines of Haskell: Production engineering at Mercury

#220

Post by uecker »

k_bx wrote: post #201
uecker wrote: post #198

Earlier quoted context omitted.

They described the use of abstract data types. One can certainly use those in most languages - for sure in C.

> runST :: (forall s. ST s a) -> a > The rank-2 type (that is, the type s is scoped within the parenthesis and can't escape) of runST ensures that the mutable references created inside the computation cannot escape due to being tagged with the type s. Internally, all sorts of imperative nonsense may occur. Externally, the function is pure. The world outside the boundary gets none of the mutation, only the result. C d…

This was not the original claim in the thread I responded to which as "even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods)." so this was about abstract data types and not polymorphism.

Regardless, you can also have some limited parametric polymorphism in C with macros. This is very poor, but parametric polymorphism in Rust is based on monomorphization so it is also quite poor. You can also have higher-order polymorphism in C but then you need to use subtype polymorphism.

Post reply on HN