Hacker News Reader

Comment by RhysU | Hacker News Reader

> Then it turns out that for historical path reasons, dynamic scripting languages are also really bad at multithreading and using multiple cores...

What would a dynamic scripting language look like that wasn't subject to this limitation? Any examples? I don't know of contenders in this design space--- I am not up on it.

View on HN

The big difference from Python is probably having to use a real tracing GC instead of automatic reference counting. For a single-threaded program, refcounts are beneficial in multiple ways, being fairly cheap, having a smooth performance profile, maintaining low resident set size, and providing deterministic freeing.

But because of the way cache coherency for shared, mutated memory works, parallel refcounting is slow as molasses and will always remain so.

I think Ruby has always used a tracing GC, but it also still has a GIL for some reason?

It would look pretty much the same. It would just have been written to be multithreaded from the beginning, and lack the long list of restrictions and caveats and "but it doesn't work with our C extensions" and such. There wouldn't be a dozen major libraries trying to solve the problem (which, contrary to many people's intuition, is often a sign that a language lacks a good solution). This is part of why I say there's no fundamental reason this can't be done, it's just a historical accident.

There are dynamic languages that were built with concurrency in mind like Clojure. It’s also a surprisingly fast language considering it’s both dynamic and functional.

Reply on news.ycombinator.com