False humility is a form of egotism; every stated upside of Go can be equally construed as a paternalistic concession to our general failure to produce capable programmers, let alone at a sufficient volume to fulfill Google’s commercial ambitions that require the production of Lots Of Code.
I’ve always associated Go as something that swooped in on Python, Ruby and Node.js to offer an alternative that is much faster out of the gate and far more approachable as C/C++/Java. This continues to be true from my experience and I think Go succeeds at this even with some of its well documented rough edges.
Didn't expect to get insulted for not using golang despite it not having a compelling use case for my needs. But here we are.
there’s two types of programmers:
- those who’ve worked with go fulltime for a few months
- those who haven’t
looking back at the go i wrote in my first weeks after dropping python, it is very different from the code i write now.
go is imperfect, but fantastic. hard to hold any other view without being in the latter category.
Previously: https://news.ycombinator.com/item?id=41641324
Every golang programmer I've worked with doesn't fit the bill of "small ego".
Have you met people who use Rust? They're the crossfitters of the programming profession :D
That's maybe a bit... thick. Fewer commercial ambitions?
The entire point of Go is to be the Java of Google, the language you don't need several weeks of training for to be productive in and start reading and writing code.
Java's problem is that it doesn't do this well for anything but heavy business logic applications, and the more clever the programmer, the more they can build up complex structures. Go counters this by not having complex structures and forcing you to consider every failure case (at least until writing "if err != nil" becomes second nature) while also having a better (but not perfect) API surface for writing the kinds of applications important at Google (network heavy, distributed systems, performance focused).
> The entire point of Go is to be the Java of Google, the language you don't need several weeks of training for to be productive in and start reading and writing code.
The point of Golang is Google’s answer to rapidly declining quality of its search results. Golang is the first and only language where faced with problems I would rather read source code of library then frantically search for solutions in Google…
> Java's problem is that it doesn't do this well for anything but heavy business logic applications, and the more clever the programmer, the more they can build up complex structures
Java has very simple OOP constructs (classes, interfaces, inheritance, simple generics) which everyone supposedly know already in industry. Golang from another hand implemented unorthodox solutions, which actually require some learning curve (e.g. how to model stuff without inheritance and generics).
Java encourages (partly through language design and partly through its community/ecosystem) [Enterprise Grade Programming](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...). The problem isn't the language per se, but that most code bases will require you to earn an architecture astronaut certification for that particular code base.
But also, the Go spec is a couple of pages and the Java spec is, uh, it's taking a while to load for me... ah yes, 876 pages. How's that learning curve?
> but that most code bases will require you to earn an architecture astronaut certification for that particular code base.
sure, if go would be popular in enterprise dev, we would see magnitude more error handling spagetti and genericless copy-paste code in go
> But also, the Go spec is a couple of pages
I think you undermeasured it by 20 times. Also it is very possible that golang spec is much more shallow. But anyway, I don't think one need to learn java spec to learn the language.
The go spec today is ~130 pages [0]. Like golang’s Stalin, its spec remarkably approachable. The latest Java spec is ~800 [1], also very accessible, but clearly there’s more complexity there.
You have to admit, there’s something appealing about being able to read the entire spec for a popular, performant, production language over a lunch break. You don’t need to read and/or master a language’s specification in order to use it. But at 130 pages, you can.
[0] https://go.dev/ref/spec [1] https://docs.oracle.com/javase/specs/jls/se23/jls23.pdf
> You have to admit, there’s something appealing about being able to read the entire spec for a popular, performant, production language over a lunch break. You don’t need to read and/or master a language’s specification in order to use it. But at 130 pages, you can.
you are probably programming language enthusiast, but I am not, I have long list of other things to read..
Java is too slow, and the language is not powerful.
Relying on composition rather than inheritance often feels much more natural in my experience. C, Basic, Pascal, etc. are all missing inheritance and generics, are they similarly unorthodox and difficult?
Java-style OO has a place, but it’s not always a perfect fit. Java, C#, and arguably C++ have taken a kitchen-sink and grafted any and all constructs found in other languages so long as they look remotely useful. The result often is useful, but it also results in a more complex language.
While Go isn’t a perfect language, nor is it a great language, I /have/ found it to be a productive language in ways that Java, python, ruby, etc. are not. I attribute this productivity boost to the simplicity of the language (if not the runtime) and to the conservative approach taken to add new features.
> C, Basic, Pascal, etc. are all missing inheritance and generics, are they similarly unorthodox and difficult?
yes, they are unorthodox for this specific niche: enterprise devs, most languages have OOP and most devs know it.
> Java, C#, and arguably C++ have taken a kitchen-sink and grafted any and all constructs found in other languages so long as they look remotely useful.
I disagree with you, Java approach was very conservative, and original goal was to have simplified OOP. If you have specific examples: we can discuss.