3 ms·

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

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

jmillikin 4y ago
> 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/Handler/Warp/PackInt.hs 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 https://github.com/vsedach/Vacietis
- Capricorn2481 4y 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?

jmillikin 4y ago

> 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/Handler/Warp/PackInt.hs 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 https://github.com/vsedach/Vacietis

Capricorn2481 4y 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?