21–30 of 91 posts
Earlier quoted context omitted.
Rust is a better choice
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.
Earlier quoted context omitted.
Care to elaborate?
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.
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
If anyone knows similar notes for Python & C#, please reply.
Earlier quoted context omitted.
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 st…
To be fair, that's a lot more empiricism than some teams use.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
what language do you suggest instead of go?
Earlier quoted context omitted.
99.99% of the boring $lang_is_superior "discussions" is by people without throwaway accounts. These people are also often more aggressive and indoctrinated.
There is no shortage of Go users, like myself, that can admit to the downsides of it. That's why there's always the same debates about things like sum types and generics and interface{} and null pointer errors in every Go thread. And even in the recent submission where Go implements provisional generics, we go on to point out the downsides of it, like how you're still stuck with null pointers to represent sum types (…
Thank you for demonstrating how regular users improve the level of discussion.
Earlier quoted context omitted.
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.
Also GC is a real no-no for real-time.
Edit Phone auto-correct from memory management to measurement.
I clicked one part (enums) and noticed a pretty glaring issue. The way you are doing enums is really _not_ conventional Go code and probably not something I would allow past a PR review. I’m saying this as someone who has built many production systems with Go and taught it to many devs coming from Java.
This guide is more in-line with how Go enums should be designed: https://blog.learngoprogramming.com/golang-const-type-enums-...
So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did.