5 ms·

I feel the same way and I can't help but feel like I am missing something. Concurrency is still inherently more complicated than serial processing no matter wha

I feel the same way and I can't help but feel like I am missing something. Concurrency is still inherently more complicated than serial processing no matter what language features you add, and it's amazing how far you can get just by scaling across OS processes. I know there are plenty of domains that do want multicore (ML, graphics), but it seems like even the people writing line of business apps think lack of multicore is a deal breaker for them.

hderms 5y ago
Yeah I really don't know because OCaml already has async constructs. It doesn't seem like it should be a dealbreaker for most. That being said, it has a reputation for being extremely performant so it might just be that people feel like it's so close to being usable in a lot of situations it currently isn't so there is more aggregate desire to allow for multicore execution
toolslive 5y ago
Often, it's just about finding a stick. They don't want to use OCaml and the absence of multi-core features gives them the excuse they were looking for. Now they can inform management: "OCaml is not an option. we'll stick with <insert PL here>"
- sshine 5y ago
  It often is. But sometimes it is also about finding more reasons to use one of your favorite languages. I’m doing pseudo-async PHP at work, and having proper support would certainly make these solutions less brittle.
  - deleted 5y ago
    [deleted]
- Buttons840 5y ago
  I learned Haskell instead of OCaml in part because of this. Yeah, it probably wasn't that important, it was an emotional decision, and it wasn't "fair" to OCaml. But whatever it was or wasn't, I learned Haskell instead of OCaml. Also, if I read between the lines correctly, in your scenerio it's management who is interested in OCaml and the developers want to use something else? Wonder if that has ever actually happened?
  - toolslive 5y ago
    management was open to "exploring alternatives" whenever a component needed to be redone.
gwmnxnp_516a 5y ago
Forking new processes is less efficient than spawning new threads as processes uses more machine resources and more memory. In addition, communication between threads is far more simple than communication between processes. Multicore may not be deal-breaker for server applications, but it matters for applications that require parallel processing.
- gmfawcett 5y ago
  Forking a process on a modern Linux is relatively cheap these days, and for many jobs you will just prefork all the workers anyway. Passing messages via thread mailboxes or IPC pipes are about equally complex endeavours. If threads had never been invented, I suspect that 90% of modern multicore programs would have done just fine on a mixture of multi-processing and asynchronous I/O. (The other 10% would have done poorly, though.)
- blacktriangle 5y ago
  Less efficient for the machine, making the program deal with async is less efficient for the programmer. I'm just confused when I see people working on CRUD apps ruling out tools because they lack first-class async support.

hderms 5y ago

Yeah I really don't know because OCaml already has async constructs. It doesn't seem like it should be a dealbreaker for most. That being said, it has a reputation for being extremely performant so it might just be that people feel like it's so close to being usable in a lot of situations it currently isn't so there is more aggregate desire to allow for multicore execution

toolslive 5y ago

Often, it's just about finding a stick. They don't want to use OCaml and the absence of multi-core features gives them the excuse they were looking for. Now they can inform management: "OCaml is not an option. we'll stick with <insert PL here>"

sshine 5y ago
It often is. But sometimes it is also about finding more reasons to use one of your favorite languages. I’m doing pseudo-async PHP at work, and having proper support would certainly make these solutions less brittle.
- deleted 5y ago
  [deleted]
Buttons840 5y ago
I learned Haskell instead of OCaml in part because of this. Yeah, it probably wasn't that important, it was an emotional decision, and it wasn't "fair" to OCaml. But whatever it was or wasn't, I learned Haskell instead of OCaml. Also, if I read between the lines correctly, in your scenerio it's management who is interested in OCaml and the developers want to use something else? Wonder if that has ever actually happened?
- toolslive 5y ago
  management was open to "exploring alternatives" whenever a component needed to be redone.

gwmnxnp_516a 5y ago

Forking new processes is less efficient than spawning new threads as processes uses more machine resources and more memory. In addition, communication between threads is far more simple than communication between processes. Multicore may not be deal-breaker for server applications, but it matters for applications that require parallel processing.

gmfawcett 5y ago
Forking a process on a modern Linux is relatively cheap these days, and for many jobs you will just prefork all the workers anyway. Passing messages via thread mailboxes or IPC pipes are about equally complex endeavours. If threads had never been invented, I suspect that 90% of modern multicore programs would have done just fine on a mixture of multi-processing and asynchronous I/O. (The other 10% would have done poorly, though.)
blacktriangle 5y ago
Less efficient for the machine, making the program deal with async is less efficient for the programmer. I'm just confused when I see people working on CRUD apps ruling out tools because they lack first-class async support.