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

151–160 of 249 posts

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

#151

Post by mhh__ »

bri3d wrote: post #7

> Haskell gives you tools to encode these incantations in types so they cannot be forgotten. This is, for my money, the single most valuable thing the language offers a production engineering organization. Haskell is admittedly, probably the most powerful widely (or even somewhat widely) used language for doing this, but this general pattern works really well in Rust and TypeScript too and is one of my very favorite…

This is more of a question of Affordances than type systems as per se e.g. you can do this quite happily in C# or something it's just that the amount of visual clutter is more than the actual type definition.

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

#152

Post by chuckadams »

zerr wrote: post #147

I once saw a real world Haskell code (from a huge investment bank) - the abundance of single letter variable names and short cryptic function names was striking.

Half the time the function names are operators, so you end up with an explosion of typographical symbols that makes perl look like cobol. Not my favorite aspect of the Haskell ecosystem.

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

#153

Post by sillysaurusx »

exe34 wrote: post #85
sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

> I’ve been able to wire transfer money without having to worry it might disappear I thought that was the whole point of banks - does money randomly disappear when people do wire transfers?

Shockingly yes. Or at least it happened to me. Nat wanted to wire me $10k to fund Tensorfork, and all I had at the time was a crummy US Bank account. I spent over an hour on the phone with them trying to get a wire transfer number, and in the end the number they gave me was wrong. The money never showed up.

That’s how I found Mercury. I was looking for a bank that wasn’t amateur hour. Once I had an account the money showed up overnight.

I still don’t know if Nat even got his original $10k back. I hope so. But yes, the failure mode is very much “if your wire transfer details are wrong, the money is just gone”. Apparently.

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

#154

Post by sillysaurusx »

LoganDark wrote: post #91
sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

I badly want to try out Mercury, in fact I have an account already, but they don't yet support Zelle. I really hope their national bank charter application gets approved. (They applied for one last December.) Once they support Zelle, I'll drop U.S. Bank, as their app sucks and they don't have an API.

Ironically I dropped US Bank for Mercury too. You’ll be glad you did.

You could try them out while still having your US Bank account.

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

#155

Post by techpression »

cyberpunk wrote: post #104
ossopite wrote: post #102

Earlier quoted context omitted.

I'm not convinced it really works well in typescript. the lack of nominal types requires you to remember some pretty hacky incantations if you want something like a newtype wrapping a primitive type my experience is that ocaml is more powerful than rust for enforcing this sort of type safety, because you have gadts that give you more expressive power, and polymorphic variants and object types (record row types) that…

It really feels like we’re solving the wrong problem sometimes. If a bad type can crash your application, sure, type safety is one answer but I have to admit I like the erlang approach; if something unexpected happens crash the process (not os process, erlang process) which has a very small blast radius on a well architected system (maybe doesn’t even fail the individual request that caused it). I wish more languages…

For me this has been a life saver being the only back end developer at the company. I don’t have the energy nor time to think about every possible scenario, especially not the mobile client sending random strings to something that should be parsed as an uuid (has happened more than once). By letting it crash I can have a look at the traces at my own leisure and a lot of them I never fix, because I don’t have to.

The amount of silencing (implementer error, but quite prevalent) of errors I’ve seen in typescript codebases are horrifying. Essentially ”try happy path, catch everything else and return generic error”, the result is is mostly the same for the user, but night and day for me who is trying to fix it.

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

#156

Post by tauroid »

jappgar wrote: post #141

It's a double-edged sword. Two million lines is a major feat. It's also represents a significant maintenance burden. The advantages to Haskell are theoretically obvious. The downsides are harder to intuit. The temptation is to model _everything_ as types. The codebase itseld becomes a _business specification_, not an application. Every policy change is a major refactor (some of which are shockingly high-touch thanks…

[dead]

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

#157

Post by GuB-42 »

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 everything right, but what if you didn't and you don't get the expected result? How do you find the bug?

In a language like C, it is relatively straightforward: go line by line, look at the execution state (the RAM, essentially) between each step and if it isn't as expected, something wrong must happen at that line, so you step in and progress like that. Harder to do when the language goes out of its way to hide the state from you, as it is the case for functional programming.

It is interesting that the longest section of the article is about this problem: "design for introspection", where the author has to go out of his way to make his code debuggable. A good insight on the often overlooked practical use of Haskell.

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

#158

Post by matt-noonan »

cubefox wrote: post #37

I know this is not the point of the article, but I find the anecdote in the beginning about null pointer errors somewhat ironic. Haskell's solution to null pointers are option types (`Maybe x` in Haskell), but these are known to be suboptimal. In languages with option types, if you want to weaken the type requirement for a function parameter, or strengthen the guarantee for a return type, you have to change the code…

This is really a non-issue in practice. In the olden days, you’d just make the change and then spend a pleasant hour or two fixing the callsites by responding to compiler errors in a pretty low-thought, mechanistic way. Nowadays you can outsource that part to a coding agent and get on with your life.

In any case, the fact that the compiler knows what code needs to be updated is a real superpower.

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

#159

Post by germandiago »

mplanchard wrote: post #149
germandiago wrote: post #143

Earlier quoted context omitted.

Some people ask me why I do not use Rust as opposed to C++ if it is already safer and more modern. But I see the forums (and I also trued some toy stuff at times) plagued with rigidity problems that in C++ have obvious solutions. For example, I am not going to fight a borrow-checker all the stack up to get a 0.0005% perf improvement, if sny, when I can use smart pointers. I am not going to use Result everywhere when…

“I’m not going to use Rust because I don’t like it” seems like what you’re saying, which is totally fine. Plenty of people, myself included, manage to write and enjoy writing general application code in Rust. You’re allowed to not get it, just like I’m allowed to dislike writing C++.

No. That is not what I am saying. I am saying there are contexts where you do not get value out of it and you can potentially decrease your productivity because it is more rigid. You have examples above if you want to read through.

In no way I am saying it is useless. I just see niche uses for it compared to alternatives.

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

#160

Post by pjmlp »

Darmani wrote: post #128
pjmlp wrote: post #110

Earlier quoted context omitted.

Exactly, and that is why after Rust's break into mainstream, several garbage collected languages are trying to mix advanced type systems with their approach to garbage collection (GC, RC, a mix of both, whatever). This is also not strange for those in the Rust community with type systems experience, hence the Roadmap 2026 proposals for a more ergonomic experience. Thus we have Linear Haskell, Swift 6 ownership, D own…

Interesting. But when I search `"roadmap 2026" rust`, I only get results for the video game. Am familiar with Linear Haskell (and actually went on a walk through Tokyo with one of the authors just a few months ago). IIRC: still no resources allocated to add the things that would actually make it useful. Had not been aware of most of those, except the dependently-typed ones. Cool to know about the others. Yay linear t…

I wish, I got the luck to do some C++ at CERN and Nokia Networks, but nothing out of the ordinary.

Just happen to be a nerd with interests across systems programming, languages, graphics, that rather reads books and papers than watching dull TV shows.

Day job is boring enterprise consulting across the usual stacks you might imagine.

Here is the roadmap.

https://rust-lang.github.io/rust-project-goals/2026/goals.ht...

Post reply on HN