- cross-posted to:
- hackernews@lemmy.bestiver.se
- rust
Go is flawed but so are all the programming languages I’ve ever used. The author raises some valid criticisms imo but I’m not sure what the point is supposed to be. Go is good for some use-cases and not for others
Which use cases is it good for, and which use cases is it not good for?
Golang is good for quick prototyping of networked application. As the author says, the golang coroutine runtime is really cool to handle many coroutines/channels. In my experience, the rest of the language is in my view garbage (no offense meant):
- package management is horrible (or at least used to be): hard to pin down specific versions, hard to replace a dependency with a local path, and to this day i don’t understand why several files in a repo are part of the same module which makes reading through the code really hard
- the serialization/deserialization primitives are hard to deal with… every time i use serde in rust i find it a little strict, but every time i try to achieve similar results with golang i end up taking literally hours… and still getting edge cases due to default values slipping through
- a lot of implicit conventions: using uppercase first letter for public API sounds good, but it’s definitely not beginner-friendly… i find explicit better over implicit conventions (in rust:
pub fn...
) - the type system is funny… i don’t remember the specifics but i remember getting into weird edge cases when hacking on someone else’s code because some types were inheriting (not sure if proper word) from other types but not in all cases…
- special mention to the HTTP standard library which treats by default paths ending in ‘/’ differently… certainly took me a while to understand why some routes i was declaring failed in mysterious ways… i think that behavior should be supported but should not be a default, even less so in a high-level scripting language which advertises ease of everything as its main feature
- and of course if you need precise performance you’re not getting it out of golang: i personally don’t need that, but go was at one time advertised as a systems language to replace C while it’s a glorified python runtime (with some clever optimizations) with C-like syntax… it’s certainly a good choice if python/ruby is an acceptable language for your usecase, but does not replace the need for languages optimized for fined-grained memory management
If you need to quickly hack some software, i personally would say modern PHP or python is a better choice because it’s certainly easier to write/debug (especially with type annotations). If you need higher performance from your quick and dirty script, golang is an acceptable choice.
If you need a reliable piece of software that can be hacked on by other people, you can certainly do it in golang if you have a whole team that’s really knowledgeable about golang and can setup tooling/conventions around it to account for every missing piece of the ecosystem. Otherwise, i would personally recommend Rust for most projects nowadays.
Rust as a language is fantastic, but the ecosystem and tooling is even better. I’ve been programming on and off for the past two decades or so, but Rust is the only language for me that made it a pleasure to read code and write code because everything is explicit (even though sometimes a little cumbersome due to being correct, for example the difference between String/OsString in regards to system paths PathBuf). I’m happy to detail on the reasons why if you’re interested.
(Rust is not the only capable opinionated language: i would recommend to look at Erlang or OCaml for other examples of truly powerful/expressive languages)
I find Go to be a great language. I read a couple of books on Go as I started learning it, and I learned about some of the items that the author is complaining from those books ahead of time (rather than encountering them as some sort of surprise or bug).
None of the author’s complaints with the language gained traction with me. I understand the complaints, but my reaction certainly wasn’t “I’m lying to myself about this so I can enjoy this language.” Perhaps it’s because my exposure to Go has been more limited than the author’s, or maybe Go is a great language and these complaints are just language features or trade offs that are good to be made aware of. 🤷♂️
…one of my early uses of Go was making libraries to be consumed from in a different language’s runtime. This was something the author made sound horrific, but something I was doing as a relatively new person to Go. I had to learn “how” to do it, but it certainly didn’t leave me feeling like it was “extremely hard.”
I like Go because I’m too dumb for anything more fancy or complex. It’s simple enough to re-learn again and again and the code I produce is easy to read.
All of the mentioned pain points are non-issues to me as an incompetent programmer.
Fun! Because I once claimed that I am too dumb for anything else than Rust… I am definitively way to dumb for Go, because the compiler just won’t care when I mess up. Interesting that there’s these different perceptions…