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

201–210 of 249 posts

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

#201

Post by k_bx »

uecker wrote: post #198
thrawa8387336 wrote: post #189

Earlier quoted context omitted.

No you cannot

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 does not have parametric polymorphism, nor rank-2 quantifications, so no, this cannot be done in C.

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

#202

Post by Boxxed »

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…

"It's possible to write in " is a common trope, but "It's possible to write in Rust" is painful and borderline impossible in my experience. I don't mean this as a defense of rust, I just think it's why the learning curve is so harsh.

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

#203

Post by spopejoy »

maz1b wrote: post #2

I think perhaps contrary to popular belief, Mercury choosing Haskell and their early leadership having such a storied experience in it probably played some non-insignificant role in their success. As a customer of Mercury, it's truly one of the critical companies my toolkit, and I just can't help but feel that their choosing of Haskell made their progress, development and overall journey that much better. I realize t…

I would counter that it was probably their startup-oriented fintech focus and execution that led to their success. I love good tech culture as much as the next HNer but I've seen companies with great tech die because of bad biz focus.

I might further argue that the startup-y fintech culture led to good tech culture. The fact that they didn't start as a bank (as opposed to say SVB) means that they didn't have to be as conservative, or integrate with some horrific ancient tech stack.

I'm pleased they've had such success with Haskell, but much like Jane Street and OCAML, I think the language choice is almost accidental*, as much as the companies would like you to believe otherwise.

I would like to know however what they're doing for front-end. I would guess that all of this Haskell is back-end only.

*EDIT by "accidental" I mean to the business side. Jane St had some good trades, Mercury had great focus and execution. They also have some good tech :)

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

#204

Post by spopejoy »

germandiago wrote: post #138

I am currently reading Real-World Ocaml and I am really learning more about functional programming, though I was already familiar with a few things. Looks to me like you can build amazingly robust pieces of software with functional programming. However, I am divided. I have a backend that works in NiceGUI for a product. It does the job. The code is reasonable and MVVM. The most important task it does is connecting to…

Not sure about Ocaml but with Haskell you can use ghci/`cabal repl` and get blazing fast reload of a web app as you develop. Tbh a lot of haskellers don't take advantage of this IMO.

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

#205

Post by sn9 »

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…

To disambiguate search results in the future, I've had great luck appending "lang" like so: "roadmap 2026 rust lang".

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

#206

Post by atombender »

Darmani wrote: post #197
atombender wrote: post #180

Earlier quoted context omitted.

I'm not a Rust expert by any means, but I'm surprised to hear this. In my Rust code, doing anything with a database connection is not at all different from, say, Go or TypeScript. For example, I use the deadpool-postgres crate for database pooling. Getting a connection looks like this: let conn = self.pool.get().await?; Because of RAII, you don't need a higher-order function helper, but if you really wanted to make o…

Just investigated -- looks like this works now! Yay! For this family of examples, had been completely stymied by AsyncFnOnce not being released yet. IIRC it had been in the works for several years, was still an experimental feature when I was trying to use it, and I gave up after much frustration at trying to get a version of Rust with experimental features working under devenv (nix). A subtraction then to my frustra…

That explains it. I think async closures were stabilized a year ago. Before that, you'd have needed to write out the async signature as non-async with futures (that's what async is syntactic sugar for, anyway). Something like:

    f: impl FnOnce(Object) -> impl Future>

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

#207

Post by sn9 »

spopejoy wrote: post #177
ironmagma wrote: post #28

Earlier quoted context omitted.

That would not run counter to the popular (whether true or not) idea that by using functional programming languages you filter for a higher quality labor pool / applicant pool.

That wouldn't apply here, since as the article says they hire "generalists, and most of them have never written a line of Haskell before joining." In any case, I think the "Haskell tax" concept (where you can pay well-paid programmers less if you have a Haskell shop) is stale by now. Rust attracted away a lot of FP-ers, plus mainstream langs like C++, Java and even Typescript got smarter. Haskell's biggest problem by…

The post explicitly makes the case for the filtering playing a role. Ctrl-F "Python".

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

#208

Post by tikhonj »

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…

You can do a great job of navigating that as long as you have some experienced engineers with taste building the core pieces. You can't have it all, but you can have a lot.

I interned at Jane Street years ago and they seemed to do a great job of walking that line (in OCaml rather than Haskell, but same difference). They moved remarkably quickly despite working in an area with a lot of inherent complexity and where reliability and correctness are an existential concern to the business. (Which, perhaps surprisingly, is massively more the case for a trading firm than for a Mercury-like neobank...) In hindsight, a key thing Jane Street did was hire some experienced OCaml programmers with great taste (like Stephen Weeks, the author of MLton) and let them build the core libraries and guide the whole codebase from the beginning.

Unfortunately, this is one of the things that Mercury didn't do anywhere near as well.

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

#209

Post by myst »

intrinsicallee wrote: post #171
myst wrote: post #57

Earlier quoted context omitted.

Costs are a skill issue ;-)

You demonstrate well the problem: yes anything that is computable can be than in any computation system. That's not what discussions about tooling are about. If a tool can help enforce some ways of doing things, or if it doesn't constrain people much, that has consequences for the type of work that gets done with them and the systems you encounter running out there that you might be invited or find the need to work w…

Does everybody _need_ to do it?

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

#210

Post by troupo »

imoverclocked wrote: post #9
le-mark wrote: post #6

It’s hard to imagine what two millions lines of Haskell could possibly be doing. I mean that’s a lot of code and I have the impression that Haskell is “tight” meaning a little code can do a lot. Maybe they have a lot of libraries to do things like json serializing/deserializing, rest api frameworks, logging etc?

From TFA: > The problem is that we cannot trust code we cannot instrument. If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace except by squinting at it and developing theories. So we write our own. More work upfront, but the client…

> If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace

Given that tracing etc. is IO, are they just threading IO through the entirety of all their Haskell code?

Post reply on HN