That's the target audience from the very beginning. Observing that the majority of Google engineers are mediocre, Rob Pike slapped together a language that matches their level. That involved "no parameterized types" and "no closures". Josh Bloch was strongly insisting on "no closures" in Java, but they were still introduced. So there was a business need to invent a language dumber than Java.
This is a total puzzle to me. I rarely met the people that would pass the tests I did. More, most of the people I interviewed were very good. OTOH, I remember, one interviewee just refused to write any code during the interview. They still hired him. Later I found that he writes a pretty decent code (and there was no doubt about his IQ). But the majority...
The idea that you shouldn't use error messages to drive production logic is sane.
But enforcing that by being deliberately subversive?.. Language zealots impacting production code? No, thank you kindly.
They wasted 2 days of my time.
You see, I am very particular about testing. My negative test cases check that they are triggering an error condition in the right place (I've got impaled before, when the negative cases happened to all go through one branch of the code, so they didn't test the intended error handling properties of the code). The waste came from the fact that I couldn't understand why seemingly equal strings were not equal. Do I misunderstand how to compare strings?..
OK, it was a one off. Shit rays to those who wrote that code, and move on. But now let's consider that this was done everywhere, if this is such a revolutionary improvement in code writing practice. What then?
I'll tell you what. Then oncallers will be unable to diagnose issues, that's what. Because now you can't search for error strings anymore: you always find only a fraction of them.
I somehow thought that maybe this behavior was documented well enough and they wanted to enforce a particular workflow different from what you describe. I cannot tell you what this different workflow might be though.
So, yes, you are right and what they are doing does look both dumb and even a bit evil.
Guess, I was looking for a way to politely disagree with your comment.
AFAIU you introduced 2 examples of not-so-clever programming languages for not-so-clever programmers. You gave 2 specific reasons as to why you consider these languages dumb (away with politeness, lol).
These 2 specific reasons look incorrect to me. It doesn't necessarily negate the whole point. But it certainly makes it somewhat questionable...
Well, my judgment regarding Go was based on what I saw and heard 10 years ago. Now it's all just impressions and opinions of other people. Java... too little, too late. Still not there.
I am not qualified to compare Go to the "smart languages" (Scala, Haskel, etc.). This is b/c I don't really know any smart languages. My reference points are Go, Python, C/C++. And Java to a lesser degree.
Go has honest closures, duck typing ("old Python" style), interesting (and very useful for the right sort of problems) concurrency features built into the language.
Admittedly subjective: minimalistic, orthogonal features, thoughtful standard library.
Anecdotally, it eats much less memory than JVM based languages. This last thing is at least partially due to Go being "value based language", C/C++ style. This is compare to Java, Python (and JavaScript?) that are "reference based languages". Also I could talk about Go being more "cache friendly" here... It is somewhat more on the implementation side of things not 100% language design though.
BTW if memory serves, Python closures are not "honest".
Specifically, you can read anything from the outer/enclosing scope but you cannot write to it unless you "cast some magic spell" (local or global keyword, I forgot).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
That's the target audience from the very beginning. Observing that the majority of Google engineers are mediocre, Rob Pike slapped together a language that matches their level. That involved "no parameterized types" and "no closures". Josh Bloch was strongly insisting on "no closures" in Java, but they were still introduced. So there was a business need to invent a language dumber than Java.
no subject
no subject
no subject
This is a total puzzle to me. I rarely met the people that would pass the tests I did. More, most of the people I interviewed were very good. OTOH, I remember, one interviewee just refused to write any code during the interview. They still hired him. Later I found that he writes a pretty decent code (and there was no doubt about his IQ). But the majority...
no subject
https://github.com/protocolbuffers/protobuf-go/blob/master/internal/errors/errors.go#L26-L34
no subject
I can't immediately and confidently agree that it is bad though... Something to think about.
no subject
But enforcing that by being deliberately subversive?.. Language zealots impacting production code? No, thank you kindly.
They wasted 2 days of my time.
You see, I am very particular about testing. My negative test cases check that they are triggering an error condition in the right place (I've got impaled before, when the negative cases happened to all go through one branch of the code, so they didn't test the intended error handling properties of the code). The waste came from the fact that I couldn't understand why seemingly equal strings were not equal. Do I misunderstand how to compare strings?..
OK, it was a one off. Shit rays to those who wrote that code, and move on. But now let's consider that this was done everywhere, if this is such a revolutionary improvement in code writing practice. What then?
I'll tell you what. Then oncallers will be unable to diagnose issues, that's what. Because now you can't search for error strings anymore: you always find only a fraction of them.
no subject
I somehow thought that maybe this behavior was documented well enough and they wanted to enforce a particular workflow different from what you describe. I cannot tell you what this different workflow might be though.
So, yes, you are right and what they are doing does look both dumb and even a bit evil.
no subject
Both modern Java and modern Go have parameterized types.
What am I missing?
no subject
no subject
Yes, I heard about Go types having parameters now. The fight in Java was hilarious.
no subject
AFAIU you introduced 2 examples of not-so-clever programming languages for not-so-clever programmers. You gave 2 specific reasons as to why you consider these languages dumb (away with politeness, lol).
These 2 specific reasons look incorrect to me. It doesn't necessarily negate the whole point. But it certainly makes it somewhat questionable...
no subject
Well, my judgment regarding Go was based on what I saw and heard 10 years ago. Now it's all just impressions and opinions of other people. Java... too little, too late. Still not there.
But I'd rather listen to your specific arguments.
no subject
Go has honest closures, duck typing ("old Python" style), interesting (and very useful for the right sort of problems) concurrency features built into the language.
Admittedly subjective: minimalistic, orthogonal features, thoughtful standard library.
Anecdotally, it eats much less memory than JVM based languages. This last thing is at least partially due to Go being "value based language", C/C++ style. This is compare to Java, Python (and JavaScript?) that are "reference based languages". Also I could talk about Go being more "cache friendly" here... It is somewhat more on the implementation side of things not 100% language design though.
no subject
Oh, then yes, between Python and Go, for production I'd definitely choose Go.
no subject
Specifically, you can read anything from the outer/enclosing scope but you cannot write to it unless you "cast some magic spell" (local or global keyword, I forgot).
no subject
Because need it never.
(c)
:)