5 ms·

I totally get what Matz said about threads, and it's also no mystery to me that there are so many GIL's around. Adding threads complicates the interpreter, to

by codr7 5y ago

I totally get what Matz said about threads, and it's also no mystery to me that there are so many GIL's around. Adding threads complicates the interpreter, to the point where I'm beginning to doubt it's worth the effort. For my own interpreters I've had success running separate interpreter instances in their own threads and communicating via channels. This allows multi-threading without making a mess. https://github.com/codr7 https://github.com/codr7

jerf 5y ago
To amplify your statement, it seems to be borderline impossible to 1. develop a world-class interpreter for over a decade and then 2. retrofit multithreading onto it. I don't have an example of that I'd call successful, where here I'm defining "success" as "the entire community casually uses it whenever it is useful and there are no special warnings to be given about the threading support". There are some implementations, but last I knew they all tend to be sort of dangerous and things the community will warn you away from, and some languages just don't have them. I would be intrigued to see someone try to create a modern dynamically-typed language or interpreter written from the beginning to be threadable, but it seems to me the energy in the dynamic typing community may not be there any more to sustain it. While it's not "dying", I suspect that as static typing is getting better the dynamic typing community is, shall we say, losing the updraft it has ridden these last 30 years. It's not like it's going to crash straight to the ground or anything, but I don't know that there's a whole lot of people chomping at the bit to write such a thing rather than write something static and useful. Especially when you deal with the fact that even the fastest dynamic languages are still ~10x slower than compiled languages on general tasks now, and it's hard to justify going crazy with threading when a single thread in a modern statically-typed language, which may only be modestly harder to write now than with a dynamic language (if that), starts out with such a performance advantage, one that only continues to multiple if the static language also starts spawning threads.
- Scarbutt 5y ago
  I would be intrigued to see someone try to create a modern dynamically-typed language or interpreter written from the beginning to be threadable There is Clojure, is dynamic and allows for multithreaded programming, courtesy of the JVM. The JVM being a very dynamic system is a good target for new dynamically typed languages. But as you said, they are a hard sell today not only because of performance but more because of static typing.

by codr7 5y ago

jerf 5y ago

To amplify your statement, it seems to be borderline impossible to 1. develop a world-class interpreter for over a decade and then 2. retrofit multithreading onto it. I don't have an example of that I'd call successful, where here I'm defining "success" as "the entire community casually uses it whenever it is useful and there are no special warnings to be given about the threading support". There are some implementations, but last I knew they all tend to be sort of dangerous and things the community will warn you away from, and some languages just don't have them. I would be intrigued to see someone try to create a modern dynamically-typed language or interpreter written from the beginning to be threadable, but it seems to me the energy in the dynamic typing community may not be there any more to sustain it. While it's not "dying", I suspect that as static typing is getting better the dynamic typing community is, shall we say, losing the updraft it has ridden these last 30 years. It's not like it's going to crash straight to the ground or anything, but I don't know that there's a whole lot of people chomping at the bit to write such a thing rather than write something static and useful. Especially when you deal with the fact that even the fastest dynamic languages are still ~10x slower than compiled languages on general tasks now, and it's hard to justify going crazy with threading when a single thread in a modern statically-typed language, which may only be modestly harder to write now than with a dynamic language (if that), starts out with such a performance advantage, one that only continues to multiple if the static language also starts spawning threads.

Scarbutt 5y ago
I would be intrigued to see someone try to create a modern dynamically-typed language or interpreter written from the beginning to be threadable There is Clojure, is dynamic and allows for multithreaded programming, courtesy of the JVM. The JVM being a very dynamic system is a good target for new dynamically typed languages. But as you said, they are a hard sell today not only because of performance but more because of static typing.