Re:I’m joining the Go team at Google
by eternalban on Friday September 23, 2016 @12:00PM
(#12565567)
I take no issue with your take on the language, but the OPs' opposing views on "revolutionizing how we write software" isn't really addressed by you.
Go is popular because it is accessible. The cognitize load of the language is in effect ammortized by being spread over the life cycle of the dev process (i.e. run vet to do x) instead at localized in cycle/space of code-time/source-code, so even professionals not bothered by complexity can see an incentive to using the language.
But I am not aware of the language enabling a class of software systems, etc., that have become more feasable because of the language.
As has been pointed out by many, at some point even the novice programmer has to get serious given the mix of pointers and channels and sync constructs which demands a degree of sophistication, so the accessibility aspect degrades over time.
And then -- and here is why I feel there is pushback regarding Go koolaid -- this somewhat on 'the fence' approach of the language towards concurrency (originally "communicate don't share memory") gives this impression of a glorious hack but a hack aspect to this "revolutionary mix" that you refer to. At some point, the ala cart type system of Go presents issues to people who have invested the time to get serious about these matters but find that their favorite light-weight language is not fully up to the task of keeping up with our conceptual models of thinking about our software.
Go is popular because it is accessible. The cognitize load of the language is in effect ammortized by being spread over the life cycle of the dev process (i.e. run vet to do x) instead at localized in cycle/space of code-time/source-code, so even professionals not bothered by complexity can see an incentive to using the language.
But I am not aware of the language enabling a class of software systems, etc., that have become more feasable because of the language.
As has been pointed out by many, at some point even the novice programmer has to get serious given the mix of pointers and channels and sync constructs which demands a degree of sophistication, so the accessibility aspect degrades over time.
And then -- and here is why I feel there is pushback regarding Go koolaid -- this somewhat on 'the fence' approach of the language towards concurrency (originally "communicate don't share memory") gives this impression of a glorious hack but a hack aspect to this "revolutionary mix" that you refer to. At some point, the ala cart type system of Go presents issues to people who have invested the time to get serious about these matters but find that their favorite light-weight language is not fully up to the task of keeping up with our conceptual models of thinking about our software.