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."

https://news.ycombinator.com/newsguidelines.html

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.

Obviously the root comment was lame and should not have been fed, but please don't take the thread further off topic.

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

> so you wrote one micro-service and came to that conclusion?

To be fair, that's a lot more empiricism than some teams use.

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).

what language do you suggest instead of go?

Rust is a better choice

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.

What if you need to compile to native? Some places don't accept having to have a VM like .NET or Java installed to run.

.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.

.Net has CoreRT to compile to native and the JVM has Graal Native Image.

I've had success deploying native services using Quarkus [0] for Java.

Additionally in modern java you would use jlink [1] to produce a minimal jvm image that ships with your application. No need to install.

[0] https://quarkus.io/

[1] https://docs.oracle.com/en/java/javase/11/tools/jlink.html

Also GC is a real no-no for real-time.

Go has a GC. Specifying the need for manual memory-management might be moving the goal-posts a bit.

Edit Phone auto-correct from memory management to measurement.

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.

True. I've even had the "interesting" experience of writing low-allocation JavaScript (for 3D mostly).

Please expand more on why Rust "is a better choice"?

I'm still not convinced by this statement.

For what? Usually absolutes are not very useful...

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.