Hacker News Reader

Crystal is definitely not production ready, I mean a language without thread support...

Yeah, it’s only now MT schedulers is work in progress to bring multithread fibers to Crystal

https://github.com/crystal-lang/crystal/pull/7214

Thread support in interpreted languages isn’t that parallel to begin with.

JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.

I’m wondering.. what is the effect of letting the JVM handle synchronization then ? Wouldn’t they still need to synchronize within JvM ?

Is it really a "choice" if the alternative is really hard to achieve in practice? It's like calling python's GIL a choice... with numerous projects trying to get rid of it in various ways and never really succeeding to do it while keeping the single threaded performance and the extensions API.

It is a choice to keep backwards compatibility with the C extensions API.

The GIL would be quite easy to replace otherwise.

> It is a choice to keep backwards compatibility with the C extensions API.

IIUC for CRuby it's mostly about how to keep the VM simple. Koichi Sasada is working on an ownership based model like Erlang has, which sidesteps a bunch of theses issues.

Reply on news.ycombinator.com