Hacker News Reader

Comment by mrdoops | Hacker News Reader

Running into concurrency woes of that whole generation of languages (Ruby/Python/PHP/Java/JS) is how most Elixir developers happen I think ;)

View on HN

I think Java is accidentally on that list, because it's had excellent concurrency stories since it came out, got complicated when they removed "green threads", thereby pushing thread pool management into the programmer's set of responsibilities, but is reworking its former ergonomics with its project loom.

for the rest of the listed languages, definitely agree.

Hard disagree. The java concurrency story was absolutely awful when it came out. It had terrible ideas which panned out as well as checked exceptions did, and got forgotten when the collections were reworked. The only things it had going for it were showing concern and a well defined memory model, but that was broken until JSR 133.

Java concurrency got a lot better with JSR 166, by accreting new APIs. But those require awareness of their existence and purpose, the langage baseline is no better.

Project loom does not fundamentally change any of that. It’s goal is to increase efficiency, aka get more wrong answers faster.

What do you mean by "get more wrong answers faster"? Given that volatile / synchronized have largely gone the way of the dodo, ditto Object.wait etc. , and that concurrency safe atomics and collections are de rigeur, how do green threads reverse that? (I understand your point that you need to use the good stuff to take advantage of it, and that the old bad stuff is still in the base language, but I feel that's true for pretty much every language that's 30ish years old.)

I spent years working on concurrent Java apps post JSR 166, and the only concurrency issues I met were PEBKAC, and some of the awful things people did with Vert.x and it's event bus.

Do you have a good resource or summary on why volatile / synchronized are problematic and java.util.concurrent should be preferred?

I always remembered the same, but was recently in a conversation with Java devs who contradicted it, and could not articulate well why this is the case. and could not find good resources on it.

Not off the top of my head. Just experience that they're easily used wrong.

PHP's unit of concurrency is the shared-nothing web request. [1]

It has proved a very successful model, combined with tools that cache PHP bytecode like opcache, and keep a pool of reusable PHP workers like php-fpm.

[1] https://slack.engineering/taking-php-seriously/

Isnt the php concurrency story distinctly good, with every request spawning its own process?

Anyone can do "concurrency" by starting from scratch with a fresh process each time. That isn't "having a concurrency story" it's rather the opposite I think. It's very wasteful of system resources, energy, etc.

PHPs model would be okay if they used green threads/goroutines. That way, you can have a far larger number of workers, as most of them are blocked on database connections or HTTP requests to other services.

PHP's model is different, not a mistake.

It has proved successful so far. The shared-nothing, short-lived process avoids classes of issues such as with slow memory leaks, accidentally blocking event loops, and shared memory threading issues.

Most PHP sites will utilise php-fpm, so it isn't really true that each request will spawn another PHP process.

The language historically hasn't been that great, but its shared-nothing architecture has always been the good part.

On the other hand its simple and works for many many people and apps. I wouldn't just discount it. The fact that "Anyone can do" it is a pro.

Only in the same way that "off" is an excellent TV channel

That's not how most typical default php setups work, for quite some time. They do get their own interpreter, but not every request is a fork.

Reply on news.ycombinator.com