4 ms·
> The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it beara
by hasenj 14y ago
> The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable
Really?
I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.
- jlouis 14y agoGo is not sequential, but concurrent. It has built-in primitives for handling concurrency, witness the `go` keyword. It also has special syntax for doing selective receive over channels, which in turn means that the concurrency of that language is definitely not "bolted on" in the sense I meant. Perhaps you are confusing my definition of "sequential" with yours. I tend to use "sequential" as the opposite of "concurrent" like I have another, orthogonal, axis for "serial"/"parallel". So you can be serial/concurrent (Node.js is close to this. So is a 4.4BSD OS without any SMP support). And you can be sequential/parallel (GPUs is my preferred example).