I don't think the author was trying to say that unbounded threads should literally never be used, in the same way that they acknowledge the fact that everything compiles down to goto in the end....
The title is clickbait, because the author is choosing to ignore that Go is explicitly intended to be a low-level systems programming language. This design goal requires that a primitive like go func() exist, so that higher-level concurrency concepts can be built upon unbounded threads. Go [...] even has that goto statement the author uses as an example of vanquished evil.
I don't think the author was trying to say that unbounded threads should literally never be used, in the same way that they acknowledge the fact that everything compiles down to goto in the end. (I would also like to mention that Rust is also intended to be a systems programming language, yet it has no goto.)
Yeah, that is kind of an incriminating quote. My personal interpretation is that the author is being a bit hyperbolic and is mainly talking about a specific Python use case.
In this post, I want to convince you that [...] thread spawning and callback registration – should be removed entirely and replaced with nurseries.
Yeah, that is kind of an incriminating quote. My personal interpretation is that the author is being a bit hyperbolic and is mainly talking about a specific Python use case.
As @joelthelion said, they're not really in the same category. I'd say Go's niche is definitely writing network stuff like backend services (and it's pretty badly suited to most other things),...
As @joelthelion said, they're not really in the same category. I'd say Go's niche is definitely writing network stuff like backend services (and it's pretty badly suited to most other things), whereas Rust is systems programming with modern concepts.
Of course, you can use either language for very different purposes - I know of GUI apps written in both.
No, it's not a joke. I didn't comment on the syntax of the go language, but of that particular primitive. You mentioned that it's a low-level construct that should be used to build higher-level...
No, it's not a joke. I didn't comment on the syntax of the go language, but of that particular primitive. You mentioned that it's a low-level construct that should be used to build higher-level concurrency concepts. In my mind, that means go func() should be used mainly in concurrency libraries. That would suggest it doesn't need prime syntax "real-estate", which could be used for concepts that are actually used often in practice.
Note that I'm exclusively talking about syntax. In point #2, you seem to be confusing syntax and semantics.
If you can get past the clickbaity title, this is an interesting read. And the author does make a parallel with goto, so it isn't that clickbaity anyways.
If you can get past the clickbaity title, this is an interesting read. And the author does make a parallel with goto, so it isn't that clickbaity anyways.
I agree, I found this a really interesting article which talks about issues I have definitely experienced when writing concurrent code. I've actually been writing a go project for the last few...
I agree, I found this a really interesting article which talks about issues I have definitely experienced when writing concurrent code. I've actually been writing a go project for the last few months, and have been afraid to use the go primitive as I'm not wanting to have to deal with synchronisation and resource-cleanup.
This blog has some other posts on async API design that are worth reading as well. In particular, "Some thoughts on asynchronous API design in a post-async/await world" and "Timeouts and...
The title is a reference to the original "Go To Statement Considered Harmful" essay and its follow-ups that copied the phrase, as mentioned down in the details of the post itself.
The title is a reference to the original "Go To Statement Considered Harmful" essay and its follow-ups that copied the phrase, as mentioned down in the details of the post itself.
Don't channels in go do this exact same thing? You can open channels, close or merge them. So just like the black-box paradigm diagram shows, the control flow sort of 'fans out' and then 'fans in'...
Don't channels in go do this exact same thing? You can open channels, close or merge them.
So just like the black-box paradigm diagram shows, the control flow sort of 'fans out' and then 'fans in' again once everything is complete.
This is trivially done with channels. Wait-groups should also address this issue.
The author of course has a point. I still find concurrent programs harder to work with than single-threaded non-concurrent ones. At the same time I feel the 'go' statement is only dangerous if used for the sake of it and without considerations for what happens before and after you split off a function.
I don't think the author was trying to say that unbounded threads should literally never be used, in the same way that they acknowledge the fact that everything compiles down to
gotoin the end. (I would also like to mention that Rust is also intended to be a systems programming language, yet it has nogoto.)Yeah, that is kind of an incriminating quote. My personal interpretation is that the author is being a bit hyperbolic and is mainly talking about a specific Python use case.
Is there anything that Go does better than Rust?
Compilation speed would be one. Also it has a GC, so it's not really comparable. Writing Rust requires more effort.
As @joelthelion said, they're not really in the same category. I'd say Go's niche is definitely writing network stuff like backend services (and it's pretty badly suited to most other things), whereas Rust is systems programming with modern concepts.
Of course, you can use either language for very different purposes - I know of GUI apps written in both.
If
go func()is supposed to be a low-level primitive, why does it have such nice syntax?No, it's not a joke. I didn't comment on the syntax of the go language, but of that particular primitive. You mentioned that it's a low-level construct that should be used to build higher-level concurrency concepts. In my mind, that means
go func()should be used mainly in concurrency libraries. That would suggest it doesn't need prime syntax "real-estate", which could be used for concepts that are actually used often in practice.Note that I'm exclusively talking about syntax. In point #2, you seem to be confusing syntax and semantics.
If you can get past the clickbaity title, this is an interesting read. And the author does make a parallel with
goto, so it isn't that clickbaity anyways.I agree, I found this a really interesting article which talks about issues I have definitely experienced when writing concurrent code. I've actually been writing a go project for the last few months, and have been afraid to use the
goprimitive as I'm not wanting to have to deal with synchronisation and resource-cleanup.This blog has some other posts on async API design that are worth reading as well. In particular, "Some thoughts on asynchronous API design in a post-async/await world" and "Timeouts and cancellation for humans" make a convincing case for this kind of structured concurrency model.
Yeah, I really love Trio's blog posts. They've actually convinced me to give it a try next time I want to write something small in async python.
The title is a reference to the original "Go To Statement Considered Harmful" essay and its follow-ups that copied the phrase, as mentioned down in the details of the post itself.
Don't channels in go do this exact same thing? You can open channels, close or merge them.
So just like the black-box paradigm diagram shows, the control flow sort of 'fans out' and then 'fans in' again once everything is complete.
This is trivially done with channels. Wait-groups should also address this issue.
The author of course has a point. I still find concurrent programs harder to work with than single-threaded non-concurrent ones. At the same time I feel the 'go' statement is only dangerous if used for the sake of it and without considerations for what happens before and after you split off a function.