5 ms·
> But I just almost irrationally hate the language itself. That's the point. It's a rejection of the keyboard jockeys who become more concerned with the code i
by randomdata 2y ago
> But I just almost irrationally hate the language itself.
That's the point. It's a rejection of the keyboard jockeys who become more concerned with the code itself than the problem being solved.
- wyager 2y agoGolang was created specifically so that Google could mitigate the downsides from lower their hiring standards. It doesn't have any higher design aspirations. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike I suppose in a sense this is rejecting the "keyboard jockeys", but probably not in the way you mean. You cannot separate the tool used to solve a problem from the problem itself. The choice of tool is a critical and central consideration.
- grey-area 2y agoI think you're giving far too much weight to that off the cuff quote from one of the creators of Go. Really I think it's more useful to view it as a better C in the less is more tradition, compared to say C++ and Java, which at the time were pretty horrible. That's my understanding of its origin. It makes sense in that context; it doesn't have pretensions to be a super advanced state of the art language, but more of a workhorse, which as Pike pointed out here could be useful for onboarding junior programmers. Certain things about it I think have proven really quite useful and I wish other languages would adopt them: * It's easy to read precisely because the base language is so boring * Programs almost never break on upgrade - this is wonderful * Fewer dependencies, not more * Formatters for code Lots of little things (struct tags for example) I'm not so keen on but I think it's pretty successful in meeting its rather modest goals.
- wyager 2y ago> Really I think it's more useful to view it as a better C But Go is nothing at all like C, and it's completely unsuitable for most of the situations where C is used. I'm having trouble even imagining what you're getting at with this comparison. The largest areas of overlap I can think of are "vaguely similar syntax style" and "equally bad and outdated type system". Pretty much everything else of substance is different. Go is GC'd, Go has a runtime, etc.
- grey-area 2y agoClearly you see it differently from people who use go, have a nice day.
- wyager 2y agoI mean, if you have a coherent explanation for why you made that comparison, it should be pretty easy to communicate... Your response as it stands is not doing much to fight the "Go enthusiasts are Blub Paradox victims" perception
- School-Cotton 2y agoNo, the vast majority of people who use go are using it in situations where Java or Python would have been appropriate, not C.
- randomdata 2y ago> people who use go are using it in situations where [...] Python would have been appropriate I'm not so sure about that. Python is a DSL for connecting C functions together. Whereas the biggest criticism of Go (gc, at least, but fair to say it has become synonymous with Go) is around its poor C-interop. In fact, because of that limitation, Go has developed a bit of a "rewrite those C functions in Go" attitude. While that doesn't indicate that Go is a better C (that's subjective anyway), it does indicate that they are found on the same playground. You're probably not going to rewrite Linux in Go, which might be what you are grasping at, but that's not where C ends. Not even close. You may have a point about Java. Griesemer was a founding member, after all.
- randomdata 2y agoThat's saying the same thing. If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature. Shiny attracts us. Let's be honest, we all have way more fun diving deep into crafting the perfect type in Haskell. But Pike indicates that if you constrain developers to bounds that they already know, where they can't turn their attention to learning about what is brilliant, then they won't be compelled away from what actually matters – the engineering.
- alpaca128 2y agoIs there any evidence that the Go style of constraints increases productivity or code quality or other metrics compared to "shiny" languages? I've heard that point repeated many times, but people have done a decent amount of engineering in many other languages too, without the need to be limited like that.
- randomdata 2y agoI expect nobody outside of Google has ever truly taken the time to study it. When was the last time you saw a programmer actually research the effectiveness of their tools and not just land on "I like this. It feels right." I never have! But I'm not sure it matters. Go was created to test the theory, not because a theory was proven. It didn't have to be successful. It may be that the studies didn't happen even within Google, although that is our greatest chance. We do know Google actually cares about data, unlike programmers. That said, since Go was released it seems every other language has tried to copy it with their own twist, so while that may not come from a place of evidence, it would appear that the feeling of increased productivity[1] was felt. [1] Or something adjacent. Focusing on engineering isn't necessarily about productivity. You can't discount productivity, but it is not the top engineering concern, especially in a place like Google.
- wyager 2y ago> since Go was released it seems every other language has tried to copy it What are you referring to here? I would consider myself quite well-apprised of recent developments in PL theory (and practice) and I am struggling to come up with examples matching this description. Go's main selling point, at least as of 10 years ago, was its green threading system, and even at the time it was substantially inferior to the green threading systems available in BEAM (Erlang, Elixir) or GHC Haskell
- Mawr 2y agoThings are what they are, not what someone (yes, even their creator) says they are. Unless you take a good look at the language itself, you will remain ignorant.