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)
21–30 of 76 posts
Re: Why Go Is Not Good (2014)
#22> · Go doesn't really do anything new.
· Go isn't well-designed from the ground up.
· Go is a regression from other modern programming languages.
I don't really like how the author just chooses some features which Go doesn't have, and based on that says "Go doesn't bring anything new".
Yes, Go lacks some features, for better or worse, but that's not really the right conclusion.
One feature Go does really well and imo more ergonomic than any other widely used language is asynchronicity. There's no function coloring and all functions are asynchronous.
It's really freeing to be able to spawn almost free asynchronous tasks anywhere, and having no sync-async divide in the ecosystem.
I really miss this in other languages, even if I understand why some (Rust) didn't choose that approach.
Re: Why Go Is Not Good (2014)
#23Go 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?
> 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 http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...>
Re: Why Go Is Not Good (2014)
#24Go 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.
If that was the goal then why not just use Java? It fits this goal description even better and offer superior tooling, infrastructure and mindshare.
Re: Why Go Is Not Good (2014)
#25Go 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?
From [1] via [2]:
> 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
[1] https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
[2] http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...
Re: Why Go Is Not Good (2014)
#26This seems odd for an article that got 30 upvotes in 15 minutes (probably not really enough time to read it all, mind you.) The complaints are a rehash of what’s been said already, only worse. Which is completely fair considering it is at least as old as 2014!
It says Go’s solution to generics is interface{}. Not really; Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one, that would answer to the basic asks in this article.
As for operator overloading and language extensibility, I think most people would agree these are never really clear cut wins as they can add inordinate complexity in exchange for sometimes dubious value. It certainly makes some things look nicer (matrix and vector types for sure) but you can always use functions to get the same utility with less sugar.
You can go on. A lot of concerns raised about Go don’t end up reflecting the day to day problems with writing Go code though, which imo is a sign that there is a gap between what people think is a problem by comparing it to other languages like C++ and Rust, and what is actually a problem by experiencing the language first hand for an extended period. I’d argue the generics problem is overblown; a solution to it will probably be welcomed, but it wasn’t like Go codebases were suffering from this. It was just making certain things (like working with slices) slightly more awkward and error prone.
For an article from 2014 these would’ve been valid concerns though in practice nobody writes Go code the way that they write C++, Rust, etc. code making some of the complaints feel like they are missing the point.
Re: Why Go Is Not Good (2014)
#27Go 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 think of Go as a lovechild of C and Scheme, mainly; I wonder if there's a citation for the claim made about design for preventing damaging programmers.
Re: Why Go Is Not Good (2014)
#28There are two types of languages: Those that people complain about and those that nobody uses.
In the last few years I've seen so many blog post complaining about go, like this one (from 2014, btw) and this [0] one; both discussed quite often on HN. And yet, I only find more and more projects using Go. The language surely has drawbacks and I personally don't like it, but it clearly has fans and is quite useful to some people.
[0] https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
Re: Why Go Is Not Good (2014)
#29The point of `auto` and `:=` is not to "shave off a few seconds of effort manually looking up the return type of bar(), and a few characters typing out the type in foo's declaration.", but to help with refactoring.
Yup.
This is often a pointed missed by people that don't like type inference.
Very often, you care very little about the actual type information that comes back. What you care about is "does this have field xyz" or "Does this contain a iterable of data with field xyz". You don't care if that's some specific type of list or what package that data is contained within.
By heavily using type inference, you make it so future changes to where the code lives or even the implementation of that code requires fewer ritual changes throughout a codebase. I don't have to go to a bunch of import locations and change foo.xyz to bar.xyz.
It reduces the friction caused by static typing that dynamic type people like to harp on.
In general, the only potential downside is a loss of readability. That, IMO, isn't a terribly strong argument. Usually you'll have an IDE that will tell you the types and the people that don't like type inference are usually pretty silent on chained operations (foo().bar().baz()) which technically have the same theoretical downside.
Re: Why Go Is Not Good (2014)
#30Go 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…
>I haven't experienced any other language that does this.
Lazarus/Pascal does all of that. There are many others, Go isn't unique.