The HN guidelines include a version of please don't feed the trolls. It goes like this: "Don't feed egregious comments by replying; flag them instead."
Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection?
If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more.
Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these interjections where we need to prod them with twenty questions just to help them flesh out their own point of view. That's what's annoying about it.
It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.
Mh, so you wrote one micro-service and came to that conclusion? What did you do to learn the language beforehand?
For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than structs in _many_ instances. They don't work like pointers in C/C++).
By avoiding pointers you also avoid `nil` being a thing. but if not having nil is a strict requirement I'll pick another language like Haskell instead. Pick the right tool for the job yada yada
I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoever and that doesn't seem to bother people.
I think that it doesn't bother people when a non-type-safe language isn't type safe. If you reach for Python, you know what you're getting. But when a type-safe language is type-safe-except-for-X, that bothers people who wanted a type-safe language.
And it's one thing if the except-for-X is "except for conversions", like casts in C, C++, and Java. Non-type-safe generics aren't usually a place where you are deliberately bypassing the type safety; they're a place where you'd like to have the type safety you have everywhere else in the language.
I don’t buy this at all. No one finds out that Go lacks generics when they’re neck deep in a project, it’s widely known ahead of time. If you need something that is type-safe >95% of the time, Go isn’t the answer (yet, anyway) and you rule it out before the first line of code is written and move on to other languages (of course, lots of life-or-death applications are written in C which has a weaker type system than Go, so I would also be skeptical about applications that need >95% type safety).
It depends on _for what_. The most important part of these discussions often leaves out this important part.
I use go as a python replacement for the most part and it’s brilliant at it. Types, compiled, good collection of external libraries and easy to read. For most of my scripting or mini projects I’m not willing to use C++ and by the same thought, I’m not willing to use rust either.
While I am no fan of Go, Rust is not a better alternative for most use cases of the average Go program. A better alternative would more likely be Java/Kotlin/Scala/C#. All with proper generics, good standard libraries/ecosystems, and fast run times.
.Net Core compiles to native and can be packaged to not need common runtime installed. And targets linux. You can even have it create a single file executable though admittedly it unpacks to temp folder at runtime if you do this. Down side is everything is like 80 MB minimum if you do this.
To be fair, it's possible to write code that does no heap allocation in each of these languages. None of them guard against mistakes that create GC work, and Java would not be my choice for this.
Null is only a thing for pointers, in a lot of cases you can use value types where they use a sane "zero" value for everything by default.
But did you really create a new troll account to go and represent the Rust Evangelism Squad? I mean if you really want to discuss the merits of Rust vs Go, at least have the decency to do a writeup that doesn't repeat the same - known - issues with Go.
I am not evangelist. Go error handling and pointers could be type safe, that's my real disappointment with it. I like its simplicity, but having a sane zero value for "almost everything" doesn't solve the problem.
