3 ms·
Haskell has always been the best. Go's did the same as Haskell. In either case IO is automatically async. If you want concurrency you create very light weight t
by gregwebs 4y ago
Haskell has always been the best. Go's did the same as Haskell. In either case IO is automatically async. If you want concurrency you create very light weight threads. This approach works very well for most use cases, but when you want the best performance possible the light weight threads can still be too much. Zig is going for a lowest possible overhead approach like Rust but has an interesting take: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
- 3np 4y agoAre you sure you are talking about Haskell and not Erlang? I'm not aware of how Haskell IO would be "automatically async".
- chowells 4y agoThat's definitely a description of GHC Haskell. All network IO in Haskell goes through a subsystem called the IO manager, which makes use of platform appropriate high-performance non-blocking APIs. (Actually, I think windows isn't getting an IOCP implementation until the next major release, but Windows has always been a bit undersupported by GHC.) The nice thing about this is... You don't have to care. Haskell is a good enough programming language to just put the platform-specific non-blocking hell APIs in a library and let you write code that looks linear and blocking. If you want more control you can get down to the low level non-blocking APIs, but that's usually not going to be worth the trouble.
- marcosdumay 4y agoYeah, many people don't even see a reference about Haskell IO being async. That's what the "automatic" part is doing. Haskell IO is basically as async as Javascript, as in every operation is fully asynchronous, you need to call some foreign function if you want otherwise. Except that you have parallelism and can have concurrency too added if you want.