Comment by giancarlostoro
Comment by giancarlostoro 2 days ago
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.
Comment by giancarlostoro 2 days ago
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.
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.
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.