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

221–230 of 249 posts

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

#221

Post by pkolaczk »

gf000 wrote: post #70
dasyatidprime wrote: post #42

Earlier quoted context omitted.

> There's a performance cost to this That part is (de facto) required for dynamically typed languages, but not for statically typed ones where the newtype constructor/deconstructor can be elided at compile time. Rust and C++ especially both do the latter by having true value types available for wrappers that evaporate into zero extra machine code. But then just this moment I wondered: do any major runtimes using mode…

Well, java can do escape analysis, so a wrapper with a single field may end up as a local variable of the embedded field. As for other JVM languages like Kotlin and Scala, they have basically what "newtype" is, but it can only be completely erased in the byte code when they have a single field.

Java escape analysis is very weak, much weaker than what stack allocation and moving allows in languages like C, C++, Rust.

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

#222

Post by pkolaczk »

k_bx wrote: post #100
miki123211 wrote: post #22

Earlier quoted context omitted.

This isn't specific to Rust or Typescript. You can do this in basically any language. Imagine you have to distinguish between unescaped and escaped strings for security purposes. 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). There's a performance cost to this, so that's a tra…

What you cannot do is compile-time safety guarantees, and in languages like Rust type system isn't strong enough to do some advanced compile-time guarantees (via types). So no, you cannot do this in basically any language (unless you turn it into Haskell).

Rust (and Scala) type systems are somewhat stronger and more expressive in some areas than Haskell. Weaker in some other. But it’s not a clear cut that Haskell type system offers more safety guarantees.

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

#223

Post by adastra22 »

Darmani wrote: post #218
adastra22 wrote: post #214

Earlier quoted context omitted.

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-comp…

I am sorry that Rust isn't for you. There is beauty in a systems programming language, but you have to be willing to think as a systems programmer. That's not for everybody.

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

#224

Post by pjmlp »

derriz wrote: post #140
pjmlp wrote: post #112

Earlier quoted context omitted.

That conflates type classes with extension types, in type theory. Actually in modern Java you can simulate type classes approach with a mix of interfaces and default methods implementations. In C# you can have the experience more straightforward with extensions types introduced in C#13. Then we have yet another way to approach type classes in Scala, with traits and implicits. And so on, as I haven't yet run out of ex…

> Actually in modern Java you can simulate type classes approach with a mix of interfaces and default methods implementations. Can you? The beauty of traits/type classes is that you can attach them to any type - in a world where 90% of the functionality of any piece of software is supplied by dependencies - external types which you cannot change - this is a vital feature.

Simulate was the word, not map 1:1 the exact experience.

It isn't pretty, but one can try to achieve a similar approach.

https://godbolt.org/z/TjPha3obs

Failing that, there are always Clojure, Kotlin and Scala on the JVM, which expose language features to achieve the same, which you naturally can mix and match with plain old Java.

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

#225

Post by pjmlp »

pkolaczk wrote: post #221
gf000 wrote: post #70

Earlier quoted context omitted.

Well, java can do escape analysis, so a wrapper with a single field may end up as a local variable of the embedded field. As for other JVM languages like Kotlin and Scala, they have basically what "newtype" is, but it can only be completely erased in the byte code when they have a single field.

Java escape analysis is very weak, much weaker than what stack allocation and moving allows in languages like C, C++, Rust.

Depends on which JVM you are taling about.

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

#226

Post by pjmlp »

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…

There are plenty of debuggers for FP languages, it is no different from a language like C.

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

#227

Post by Darmani »

adastra22 wrote: post #223
Darmani wrote: post #218

Earlier quoted context omitted.

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-comp…

I am sorry that Rust isn't for you. There is beauty in a systems programming language, but you have to be willing to think as a systems programmer. That's not for everybody.

This is getting pretty funny. In this branch of the thread alone, I've seen the defenses of: (1) "Rust is fine, you're just expecting the affordances of a GC language." (2) "Rust is fine, you're just expecting the affordances of Haskell," and now (3) "Rust is fine, you're just not used to systems programming"

It's okay if your language has problems (I have plenty of criticisms of my favorite languages), but I find it odd and concerning how frequently I've seen Rust programmers try to deflect instead of engaging in criticism.

I actually have a huge systems programming background and identify as a systems programmer. C and C++ by and large do not have the problems I've written about. These things are Rust problems, not systems problems.

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

#228

Post by Darmani »

pjmlp wrote: post #160
Darmani wrote: post #128

Earlier quoted context omitted.

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

Sounds like a fun life :)

Have found in that roadmap things that would help me personally like making async functions dyn-compatible. Have not found the deeper stuff I thought you were hinting at.

Last year, I wanted to use the 5- line Result.flatten function, abs then found it had been stuck in experimental....for 5 years. That left me with no confidence of the language's dev velocity.

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

#229

Post by germandiago »

spopejoy wrote: post #204
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.

Ocaml seems to have a REPL as well, not sure how it works outside of Emacs (in Emacs with utop looks good what I am trying).

Haskell is so so correct that it tends to get a bit on the way and you tend to encode everything in the type system. This is a blessing for correctness and a curse for other stuff (tracing, debugging, adding side-effects).

This is the reason why I am looking at Ocaml instead of Haskell: not so pure, more pragmatic and supports imperative programming well.

As I said, it is double-edged.

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

#230

Post by intrinsicallee »

myst wrote: post #209
intrinsicallee wrote: post #171

Earlier quoted context omitted.

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?

Everybody? Need? Obvious answer is no.

Some people, teams and orgs can benefit from it. "I don't need it" is missing the point. "Not everybody needs it" is missing the same point from a different direction.

Post reply on HN