Comment by figmert
Comment by figmert 2 days ago
Has Go become the new PHP? Every now and then I see an article complaining about Go's shortcomings.
Comment by figmert 2 days ago
Has Go become the new PHP? Every now and then I see an article complaining about Go's shortcomings.
I think with C or C++ devs, those who live in glass houses shouldn’t throw stones.
I would criticize Go from the point of view of more modern languages that have powerful type systems like the ML family, Erlang/Elixir or even the up and coming Gleam. These languages succeed in providing powerful primitives and models for creating good, encapsulating abstractions. ML languages can help one entirely avoid certain errors and understand exactly where a change to code affects other parts of the code — while languages like Erlang provided interesting patterns for handling runtime errors without extensive boilerplate like Go.
It’s a language that hobbles developers under the aegis of “simplicity.” Certainly, there are languages like Python which give too much freedom — and those that are too complex like Rust IMO, but Go is at best a step sideways from such languages. If people have fun or get mileage out of it, that’s fine, but we cannot pretend that it’s really this great tool.
My biggest nitpick against Go was, is and still is the package management. Rust did it so nice and NuGet (C#/.NET) got it so right that Microsoft added it as a built-in thing for Visual Studio, it was originally a plugin and not from Microsoft whatsoever, now they fully own it which is fine, and it just works.
Cargo is amazing, and you can do amazing things with it, I wish Go would invest in this area more.
Also funny you mention Python, a LOT of Go devs are former Python devs, especially in the early days.
You forgot: CLU 1977.
". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
And still there are more modern idioms and language features that ML had in the 70s but are missing from Go. But, these have the fatal flaw of Not being Invented Here.
Not really, no one at other other than the original authors though of that, the authors had an issue with C++ compile times and were sponsored by their manager to work on this Go side project of theirs.
Google's networking services keep being writen in Java/Kotlin, C++, and nowadays Rust.
Go was written with the experience of a bunch of C people who weren't particularly fond of C++ while writing network services/systems at Google and have written Go as a 'C for the 21st century' with the sort of use case they used C++ for previously at Google.
People like Rob Pike and Ken Thompson certainly knew that you can't put in a GC and cover all systems programming use cases, but they knew that Go could cover their use cases.
Or are you suggesting that they were frustrated with C++ so they decided to write a language they couldn't use instead of C++ for their use case?
> Google's networking services keep being writen in Java/Kotlin, C++, and nowadays Rust.
And? Google is a massive company that uses many languages across many teams. That doesn't mean that some people at Google, incl Go's original creators, would not use Go nowdays to write what they would previously use C++ for.
> Has Go become the new PHP? Every now and then I see an article complaining about Go's shortcomings.
These sorts of articles have been commonplace even before Go released 1.0 in 2013. In fact, most (if not all) of these complaints could have been written identically back then. The only thing missing from this post that could make me believe it truly was written in 2013 would be a complaint about Go not having generics, which were added a few years ago.
People on HN have been complaining about Go since Go was a weird side-project tucked away at Google that even Google itself didn't care about and didn't bother to dedicate any resources to. Meanwhile, people still keep using it and finding it useful.
The last 20% is also deliberately never done. It's the way they like to run their language. I find it frustrating, but it seems to work for some people.
Go is a pretty good example of how mediocre technology that would never have taken off on its own merits benefits from the rose tinted spectacles that get applied when FAANG starts a project.
I don’t buy this at all. I picked up Go because it has fast compilation speed, produces static binaries, can build useful things without a ton of dependencies, is relatively easy to maintain, and has good tooling baked in. I think this is why it gained adoption vs Dart or whatever other corporate-backed languages I’m forgetting.
80% of what programmers write is API glue.
Go _excels_ at API glue. Get JSON as string, marshal it to a struct, apply business logic, send JSON to a different API.
Everything for that is built in to the standard library and by default performant up to levels where you really don't need to worry about it before your API glue SaaS is making actual money.
I tried out one project because of these attributes and then scrapped it fairly quickly in favor of rust. Not enough type safety, too much verbosity. Too much fucking "if err != nil".
The language sits in an awkward space between rust and python where one of them would almost always be a better choice.
But, google rose colored specs...
> Not enough type safety
Sure? Depends on use case.
> too much verbosity
Doesn't meaningfully affect anything.
> Too much fucking "if err != nil".
A surface level concern.
> The language sits in an awkward space between rust and python where one of them would almost always be a better choice.
Rust doesn't have a GC so it's stuck to its systems programming niche. If you want the ergonomics of a GC, Rust is out.
Python? Good, but slow, packaging is a joke, dynamic typing (didn't you mention type safety?), async instead of green threads, etc., etc.
>packaging is a joke
You should see what package management was like for golang in the beginning "just pin a link to github". That was probably one of the most embarrassing technical faux pass ive ever seen.
>dynamic typing
Type hinting works very well in python and the option to not use it when prototyping is useful.
>Rust doesn't have a GC so it's stuck to its systems programming niche.
The lack of GC makes it faster than golang. It has a better type system also.
If speed is really a concern, using golang doesnt make much sense.
I’m almost with you. If there was a language with a fast compiler, excellent tooling, a robust standard library, static binaries, and an F#-like type system, I’d never use anything else.
Rust simply doesn’t cut it for me. I’m hoping Roc might become this, but I’m not holding my breath.
Exactly.
The other jarring example of this kind of deferring logical thinking to big corps was people defending Apple's soldering of memory and ssd, specially so on this site, until some Chinese lad proved that all the imagined issues for why Apple had to do such and such was bs post hoc rationalisation.
The same goes with Go, but if you spend enough time, every little while you see the disillusionment of some hardcore fans, even from the Go's core team, and they start asking questions but always start with things like "I know this is Go and holy reasons exists and I am doing a sin to question but why X or Y". It is comedy.
No, this has been the case as long as Go has been around, then you look and its some C or C++ developer with specific needs, thats okay, its not for everyone.