4 ms·

Well, I am using it mostly for CLI applications where multi core is not a problem, but the type system is a bliss. An we can just compile to native or bytecode

Well, I am using it mostly for CLI applications where multi core is not a problem, but the type system is a bliss. An we can just compile to native or bytecode and deploy a single file (just like Go). Does Haskell support CSP (channels, cooperative threads)?

thoughtpolice 11y ago
The runtime is SMP-capable and lightweight threads are preemptable, multiplexed on top of epoll (or kqueue) based event loops. So it's a preemptive N:M model. Haskell threads basically try to behave like OS threads as much as possible (with semantics that look like they're blocking) but they have a lot better cost model overall, so you don't need to do manual callback-based programming. It's pretty nice. There are really dozens of concurrency abstractions you can choose from, and yes, CSP-style programming is an option, available as a library: http://hackage.haskell.org/package/chp http://hackage.haskell.org/package/chp - and common abstractions like MVars (which are essentially simple, concurrent 1-place queues) can get you a long way even without that. There are other libraries for more specific needs; like graph/dataflow based parallelism, array parallelism, GPU-based programming, DSLs for image processing, etc etc. All that said I'm very happy and hopeful to see OCaml 4.03 adopt multicore support. OCaml has an excellent, robust and lightweight toolchain and implementation, and is very straight-forward and powerful out of the box. It's not my personal cup of tea, but we'd be worse off if they weren't here.
- istvan__ 11y ago
  Thank you for the detailed response. OCaml is not my cup of tea either, but it is really interesting to learn it. If you have any ML like experience than I guess it is less interesting though. The toolchain is great this was one reason I decided to try it out.
evincarofautumn 11y ago
Yeah, GHC’s runtime provides lightweight threads (forkIO) as well as OS threads (forkOS). The runtime and various libraries provide a wealth of parallelism and concurrency primitives—Chan, MVar, STM, TVar, &c. Concurrent programming in Haskell is delightful. It gave me a better understanding of how to do it in imperative-land, too.

thoughtpolice 11y ago

The runtime is SMP-capable and lightweight threads are preemptable, multiplexed on top of epoll (or kqueue) based event loops. So it's a preemptive N:M model. Haskell threads basically try to behave like OS threads as much as possible (with semantics that look like they're blocking) but they have a lot better cost model overall, so you don't need to do manual callback-based programming. It's pretty nice. There are really dozens of concurrency abstractions you can choose from, and yes, CSP-style programming is an option, available as a library: http://hackage.haskell.org/package/chp http://hackage.haskell.org/package/chp - and common abstractions like MVars (which are essentially simple, concurrent 1-place queues) can get you a long way even without that. There are other libraries for more specific needs; like graph/dataflow based parallelism, array parallelism, GPU-based programming, DSLs for image processing, etc etc. All that said I'm very happy and hopeful to see OCaml 4.03 adopt multicore support. OCaml has an excellent, robust and lightweight toolchain and implementation, and is very straight-forward and powerful out of the box. It's not my personal cup of tea, but we'd be worse off if they weren't here.

istvan__ 11y ago
Thank you for the detailed response. OCaml is not my cup of tea either, but it is really interesting to learn it. If you have any ML like experience than I guess it is less interesting though. The toolchain is great this was one reason I decided to try it out.

evincarofautumn 11y ago

Yeah, GHC’s runtime provides lightweight threads (forkIO) as well as OS threads (forkOS). The runtime and various libraries provide a wealth of parallelism and concurrency primitives—Chan, MVar, STM, TVar, &c. Concurrent programming in Haskell is delightful. It gave me a better understanding of how to do it in imperative-land, too.