3 ms·

> This is not at all about having threads as a library. Threads are already a part of many languages anyway. Yes, I agree. But I think it is useful to try to a

> This is not at all about having threads as a library. Threads are already a part of many languages anyway. Yes, I agree. But I think it is useful to try to apply the lesson of that paper further: capabilities that we want to give programmers that change the semantics of their code in a fundamental way maybe should be part of the language. I think it's a sliding scale. Your position seems to be "if we can do it in a library, we don't need a language." I'm proposing that there is a spectrum.

CyberDildonics 6y ago
What specifically do you think should change and what problem would it solve? > change the semantics of their code in a fundamental way What is this semantic change you are talking about? Threads run what you give them, they don't change the semantics. Synchronization primitives are already in languages. Using the synchronization primitives to get something fast yet simple to use is the tricky part, and that is something that can be done with simple pieces and relatively small data structures.