[mjburgess]

> If you ran Go as a single thread, you would also run into similar issues.

Yes, if you hobbled yourself, you would be hobbled.

The inability to do concurrency properly is not a feature, it's a missing feature. The whole point of node was to be a node.

[Rapzid]

I'm also unsure about this comment. It reads to me as "The main advantage of Go is.. that it makes it really easy to not have this problem." The OP talks about single core being an issue. It is not for Go due to the cooperative goroutine scheduling and function call pre-empting. You can still shoot yourself in the foot, but it's really easy to create an escape hatch by just making a function call or occasionally yielding to the scheduler...

[wpietri]

> really easy to create an escape hatch by just making a function call or occasionally yielding to the scheduler...

Having dealt with cooperative multitasking back in the dark ages, I definitely don't believe it is easy. With proper threads, you just write your code in a straightforward manner. With cooperative multitasking, you now have to be continuously imagining performance and sprinkling in otherwise useless calls every time you think something might take a while. When you get that wrong, which will be a fair bit, you have to go back and re-sprinkle. And then when the character of your input changes, you get to re-sprinkle again.

I was ok with it in the dark ages; there wasn't an alternative given the hardware of the time. But now? Even watches are multi-core. I want to use languages that make parallelization easy.

[Rapzid]

Meh, it really doesn't come up that often. Every method call is an opportunity for the scheduler to run, not just specific ones. I find it is very rare indeed for a significant amount of work to be done without making method calls. Go also uses threads and makes parallel programming easy.. For me anyway.

[wpietri]

Ah, I didn't realize that it happened at every method call. That seems more manageable. Thanks.