Go was designed to not cause widespread damage in the hands of a mediocre programmer. It prevents people from being too clever at the expense of more boilerplate and general busywork. This is the exact tradeoff that google wanted to make.
[deleted]
Why Go Is Not Good (2014)
11–20 of 76 posts
Re: Why Go Is Not Good (2014)
#12Is there something here that hasn't been said before? From skimming it just looks like the usual list of complaints we've seen a thousand times
I appreciate that they've done a good job of describing why things like a lack of generics hurts and alternatives, but ... yeah, this is the beaten horse.
Re: Why Go Is Not Good (2014)
#13> "I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good." The problem I have seen with many other programming languages is that as they try really hard to become a "good language" they eventually always become a "bad language" because of all the changes which they implemented in order to beco…
A.k.a, "the road to hell is paved with good intentions."
Re: Why Go Is Not Good (2014)
#14Go was designed to not cause widespread damage in the hands of a mediocre programmer. It prevents people from being too clever at the expense of more boilerplate and general busywork. This is the exact tradeoff that google wanted to make.
I've heard this repeated several times. Is there a source for this claim from any of the people who designed the language?
Re: Why Go Is Not Good (2014)
#15Is there something here that hasn't been said before? From skimming it just looks like the usual list of complaints we've seen a thousand times
Just another field for battle in the Go vs Rust HN comments war
Re: Why Go Is Not Good (2014)
#16> You might be expecting a linked list of integers, but at some point, some tired, coffee-fueled programmer with a deadline to meet accidentally put a string in there somewhere
How often does this really happen in practice? You know the software doesn't work when you try a wrong type, because it blows up on startup or on a request. In my experience my bugs aren't because of problems with types but with logic errors. It compiles but is not correct because you're doing the wrong thing. You know pretty quickly in Python or Javascript when you make a mistake because you pass in the wrong arguments and the right thing _doesn't_ happen.
Types don't save you from typing the wrong code or simply doing the wrong thing in a type safe way.
Re: Why Go Is Not Good (2014)
#17What's it with the perpetual reposting of meaningless rants like that? https://news.ycombinator.com/from?site=yager.io
Why is it meaningless? It sounds like you disagree with it, so maybe you would like to discredit it's face value.
The "perpetual reposting" seems like a signal that it resonates with some people? Once again proving that it likely isn't meaningless (at least to everybody).
Re: Why Go Is Not Good (2014)
#18Re: Why Go Is Not Good (2014)
#19Go is like a superior version of Java. Rust is like a superior version of C++. I wouldn't use Java or C++ any more for a new project, barring some very specific reason. But I might use either Go or Rust depending on the project's priorities.
These criticisms of Go are basically correct, but it does have some advantages over Rust, like in some situations absolute performance is not so important, copying strings around a lot is okay, and dealing with the borrow checker is extra needless work.
Re: Why Go Is Not Good (2014)
#20Go may not be the best as a language, but it's the best in terms of toolchain.
- Reasonable fast compiler with helpful error messages
- Out of the box cross compilation
- Produces self-contained executable files by default (statically linked binaries)
- Forward compatibility: code written today will (almost) always compile with the latest compiler version from the future.
I haven't experienced any other language that does this.
(Maybe zig will get there soon, but it hasn't reached version 1.0 yet)
Also as a language, it provides a set of really important features:
- Value semantics for structs
- Distinction between values and pointers
- Raw access to byte buffers (most other languages try to conceal them)
While the mandatory GC means you can never be 100% in control of performance, the above mentioned points get you ~60-80% of the way there.