undefined | Better HN

0 pointsCapricorn24813y ago0 comments

    >> On the other hand, Haskell is not great when you need predictable optimization or precise memory management. A lot of modern commercial software is basically business logic scaffolded over an HTTP or RPC server, which is maybe a worst-case scenario for Haskell

Why is this a worst case for Haskell? Aren't databases and HTTP the real blocker to performant web apps?

    >> It's possible for a C expert to read C code from pretty much any codebase and understand what's going on at a tactical level. This is not true of research-y Haskell and it's very not true of idiomatic Lisp.

I don't know enough about CL, but if you stay away from macros, is the average LISP developer anymore likely to make a non industrial code base than a Rust developer? It seems like the real cause of difficult to grok codebases is not just macros, but extreme abstraction, which can be done with just passing functions around.

0 comments

2 comments · 1 top-level

jmillikin3y ago· 1 in thread

  > Why is this a worst case for Haskell?

You generally don't want a garbage collector in the core request-dispatch loop, and Haskell's lazy evaluation makes it really easy to accidentally write code that can't be compiled to efficient output. It's not impossible to write a high-performance HTTP server in Haskell[0], but the skill requirement is much higher than in C++, Rust, or Go[1].

  > is the average LISP developer anymore likely to make a non industrial
  > code base than a Rust developer?

Yes. Not because of the developer, but because of how extremely flexible and dynamic the Lisp-family languages are. The power and joy of Lisp is in how it's almost a meta-language, so every project can become its own EDSL. The most famous (infamous?) example of this is Vacietis[2], which is a Common Lisp library that allows C code to be imported directly(!!).

[0] IIRC the Yesod framework's Warp does well on benchmarks, and when you look at code like https://github.com/yesodweb/wai/blob/master/warp/Network/Wai... you can see the lengths they had to go through to work around the choice of implementation language.

[1] Go has a garbage collector, but exposes the stack/heap distinction more directly than Haskell, so it's easier to write allocation-free code in hot paths.

[2] https://github.com/vsedach/Vacietis

Capricorn2481OP3y ago

Are you referring to writing an HTTP server from scratch? Or simply making a REST API with existing libraries? I don't see how a garbage collector would be a problem for the latter. When is the speed problem for your REST server gonna be the garbage collector vs the database calls or the network requests themselves?

j / k navigate · click thread line to collapse

>> On the other hand, Haskell is not great when you need predictable optimization or precise memory management. A lot of modern commercial software is basically business logic scaffolded over an HTTP or RPC server, which is maybe a worst-case scenario for Haskell

>> It's possible for a C expert to read C code from pretty much any codebase and understand what's going on at a tactical level. This is not true of research-y Haskell and it's very not true of idiomatic Lisp.