there we Go again.
why spend time writing about something you don't like? Is it a therapy for programmers with strong opinions?
Why Go Is Not Good (2014)
221–230 of 466 posts
Re: Why Go Is Not Good (2014)
#222The author list features, shows you can't solve them easily with go and then conclude that go is not good. With similar argument, I could list every feature of xml, show that they are not easily solvable with json and conclude that json is not good.
See the very end of the article :)
Re: Why Go Is Not Good (2014)
#223"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…
The way Haskell and rust solve this is that they constrain the types of the overload. If you want to overload +, you implement the Add trait, which has to be a certain type. The Add trait is googleable, and it provides a hint as to how the operator is to be used. In practice Rust and Haskell have much less of a problem than C++ in this respect. Additionally, having a strong culture helps (which Go obviously does). Python has no restrictions on overloading, but it's much less abused than in C++ because there's a cultural aversion to making operators do crazy stuff
Re: Why Go Is Not Good (2014)
#224I think this post neglects the fact that one of Go's biggest strengths has almost nothing to do with the language. A huge portion of every-day logic is implemented very well, and very consistently in the stdlib. Personally I don't want to go pick through half-baked third-party packages, mix and match concurrency models or GC. I have experienced enough of that in Node and it's not pretty. Having it all consistently im…
But... Python already exists? Sorry to go all old-school on you, but the quality of Python's stdlib has literally been a part of pop culture for more than half a decade: https://xkcd.com/353/
[deleted]
Re: Why Go Is Not Good (2014)
#225If anyone is looking for the article publishing date (no indication on the site), archive.org made the first snapshot on June 2014.
Yeah, I suspected it was old when the Rust version used was 0.11...
The most often encountered thing that I find Rust frustrating is how much the language changed over time--lots of random answers and posts that are outdated floating around somewhere that I have to throw out because the language changed.
Re: Why Go Is Not Good (2014)
#226While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…
I wouldn't call myself part of the Go community in any real way. There are people doing much more than I am. I personally like Go. We use Go at Creative Market (and do so increasingly). I will say the my impression of Rob Pike and some members of the community is that they just put on earmuffs and say, "no, you're doing it wrong, you don't need that" (generics). I think this article clearly demonstrates that working…
It's funny that you set Java aside based on something that it does which you do not need. I am not convinced that Go solves any problem that Java can't solve, other then it doesn't have a baggage of 20 years worth of bad open source libraries and a culture of writing 20 layers of abstraction where no layers are needed.
Re: Why Go Is Not Good (2014)
#227While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…
I wouldn't call myself part of the Go community in any real way. There are people doing much more than I am. I personally like Go. We use Go at Creative Market (and do so increasingly). I will say the my impression of Rob Pike and some members of the community is that they just put on earmuffs and say, "no, you're doing it wrong, you don't need that" (generics). I think this article clearly demonstrates that working…
[deleted]
Re: Why Go Is Not Good (2014)
#228Earlier quoted context omitted.
Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.
Then good that it stopped years ago: https://golang.org/doc/ >>> The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly…
"expressive"
"concise"
"novel type system"
"flexible type system"
Just a few things that need correcting. Really ... "novel type system" ...
Re: Why Go Is Not Good (2014)
#229After having been the primary author on a large go program, I'd personally never choose it again. It fails to help solve several major issues where other language like swift and rust seem to solve them wonderfully.
Just looking at the Option type in Rust alone makes you wonder just how many places have you really forgotten to check or write tests to verify you check for nil values. Probably too many. That one thing is enough of a win over most languages today that I'm sold on the concept entirely.
Can we all agree to raise our pitchforks and torches in the general direction of the terribleness that is null?
And how would someone implement Option if not for type generics. Because of the lack of type generics in Go your stuck writting run time tests for things like type conversions and nil value checks. A complete waste of precious developer time. Thats the real loss. Time.
Re: Why Go Is Not Good (2014)
#230Go is good enough when you're switching from Ruby to Go and all you do is build web-applications. * Its forced syntax stops syntax wars. * Compiling down to one binary makes deployment easy. * Its has concurrency out of the box. * Its insanely fast. * A strong community to hire developers easily enough. Does Haskel/Rust have the same criteria? Shurgs
> * Its forced syntax stops syntax wars.
Okay, but so does any in-company linter.
> * Compiling down to one binary makes deployment easy.
Rust and Haskell are both compiled to a single binary, typically, and both can be statically linked (with some work.. this is getting better)
> * Its has concurrency out of the box.
Rust is actually a systems language and does not have a decent semblance of concurrency (beyond OS threads, which it does very well) because it is very difficult to actually introduce/keep consistent at that level. (AKA: Why green threads were removed)
Haskell has one of the most advanced runtime systems of any modern language, and it does support Go-esque concurrency/parallelism (along with every other concurrency style you might want - as libraries).
As a bonus: in Haskell, you don't typically need to worry about the dangers of multiple concurrent or parallel routines manipulating state in unsafe ways, etc. STM is pretty great, too.
> * A strong community to hire developers easily enough.
If you want a "Go developer" - there are plenty of them. If you want a strong generalist who can learn the technologies you are working with (be it Rust, Haskell, whatever), there are plenty of those, too.
Go does seem like it reduces developers of all skill levels to some common denominator, allowing easy termination/hiring. Whether or not this is a good thing is debatable.