Hacker News Reader

Comment by blacktriangle | Hacker News Reader

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.

View on HN

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

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.

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?

management was open to "exploring alternatives" whenever a component needed to be redone.

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

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.

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

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.

Reply on news.ycombinator.com