undefined | Better HN

0 pointssidkshatriya4y ago0 comments

> An ML that competes with rust+tokio is an exact description of haskell.

Haskell only exceeds rust+tokio in terms of overall code elegance and succinctness.

When it comes to performance, rust+tokio is going to be much more performant by default as there will be no GC, no hidden traps with laziness, no subtle memory leaks etc.

Sure, a Haskell wizard will be able to reduce the gap further and solve issues but it is going to be difficult to consistently beat rust+tokio. By the time said Haskell wizard makes changes to the code, the famed elegance of Haskell is going suffer as the code will be littered with strange incantations of strictness annotations, possibly some C-ffi and other magic. This will not be the beautiful Haskell that you learn in textbooks. Only very few people know how to make Haskell truly fly. If you're one of them, then you're lucky!

0 comments

2 comments · 1 top-level

wyager4y ago· 1 in thread

> When it comes to performance, rust+tokio is going to be much more performant

This is nonsense without significant further qualification.

I guarantee the tokio scheduler and async stack model gives you net worse results for many real workloads.

sidkshatriyaOP4y ago

While quoting me you omitted the phrase “by default”. I said “When it comes to performance, rust+tokio is going to be much more performant by default”.

What I meant was in the typical case, you can expect rust+tokio to be faster than Haskell. This is not a surprise as rust is much more low level, does not have a GC and its compiled output maps better to modern processors rather than the pure functional lazy style of Haskell.

Plenty of benchmarks across a variety of workloads and program confirm that Haskell is slower than rust on average. For webserver type use cases (which uses a lot of Async) Rust is faster. Check out tech empower benchmarks for example.

j / k navigate · click thread line to collapse