I like C but strongly dislike Go. They share nothing other than having a small(ish) feature set.
Realize a Go []int ("slice of int") is just a C struct like this, passed by value:
struct intSlice {
int* addr;
int len;
int cap;
};
This can be confusing if you're used to C++'s std::vector (which owns the memory) or Python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example:
void sort(int* addr, int len);
func sort(a []int)
This reminds me of Numpy's ndarrays, which act more like "owning containers" (which may sometimes share ownership and alias) than "non-owning references".
If I want to write flat/simple code I'll just C, Go doesn't really offer anything to me because I want to be relatively low-level and able to make the compiler save my time.
Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo.
I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names.
It's like the simplicity gets in the way of itself.
-
My take is, use Go for a bit, take the "less is more" mentality with you to a language more suited for real work.
ps: I'm not saying you can't use Go for real work before someone flies at me. I'm just saying that Go's strength is the mentality people have when using it, as a language it's not particularly enabling, and that's by design if anything...
I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages.
That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional effort it took to deal with what was missing
There's an implicit ymmv here of course, because I'm not saying no one can find Go useful, I can see how in certain worlds with certain teams with certain priorities it'd all work out.
It's just not for me.
In Node??? Have you actually written any Go code?
Imagine evaluating the time to market for an experimental back-end written in Rails, Laravel, Phoenix, etc vs Go! The difference is staggering.
Comparing frameworks and a language, really?
Different languages make writing the DSLs used in Rails-like frameworks easy, difficult or impossible. Much of my professional career was spent working on Node back-ends with a variety of frameworks and none of them were even close in terms of succinctness or productivity.
Not well or hastily written Go is easily like that. I can only guess why you point out the repetition but when you look at well written Go code like in the Go std library, there isn't much repetition happening and it looks rather elegant. At the same time it can be quite some effort to create such code and might take several iterations. Documentation-wise I like the official documentation, it gives a lot of pointers why Go is how it is.
Also obviously it's not for every use-case. Where it works really well IMHO is where error handling is a vital part of the application. (And of course anything concurrent is quite a breeze)
I recall a point where I had written a function that needed to return a channel, but of course had to forgo types due to the lack of generics.
The end result was having to wrap that channel in another channel that added typing at each call site.
I asked around in go circles if that made sense, and called out how bad the felt but the answer was "no that's great! channels are cheap! the repetition is good because it's simple!"
-
The error handling has some sore points to that end too, and the implicit shadowing with shorthand assignments on one hand makes it easier to deal with multiple errors, but on the other hand introduced subtle logic bugs on one than more occasion where "err" was silently shadowed, which I greatly disliked.
I'm actually suprised Go didn't forgo shadowing for the shorthand operator and force people to label their errors when dealing with multiple, it seems very "in brand", but I guess even Go draws the line somewhere lol
-
Then there's the whole stack trace situation. Which after plenty of reading still just wasn't making sense. I mean the idea of logging a stack of wrapped messages sounds very nice, but man proper stack traces not being the first class citizen of error handling just did not make sense to me in a language I hear referenced for systems work so much (and I realize they can be had)
I saw proposals to rework Go's error handling, I don't know if any progress has been made to that end, but it's another example where simplicity can get in the way of itself
-
And I'll balance this all out by saying it was still fun to write, I don't want to seem like I'm just shitting on Go for existing.
It's just these little warts that I kept getting over with just a little bit of "idiomatic Go" which I often found was just writing a little bit more code than you're used to, started to add up.
And eventually I realized I was creating something that, while very easy to reason about, had a lot more to reason about than it needed to. That's where I kind of petered out in my personal usage.
About generics, it depends on the problem at hand. When writing a generic Matrix multiplication type that for instance should work both on real and complex numbers (or more obscure types) generics are a thing. On the other hand, when working for instance with golang.org/x/net/html, I really appreciate the interface definitions and the possibility to do type switches on those.
The error handling problem can also be dealt with. I also prefer to not shadow variables, IMHO the ideal function has all its variables defined already in the signature.
I mean there are stack traces when a panic is called, or something that wraps it like a log.Fatalf. I guess the idea is the author is giving much more thought to how errors are dealt with and how they are printed in a both useful (=greppable) and beautiful way. As an end user that doesn't want to dive into the code I probably always prefer to see a nicely formatted error message (or even a gracefully handled error) instead of a 100 line stack trace. Probably Go is not just the language spec but also how to use it. Therefore saying "Learning Go in 5 minutes" is probably a bit far-fetched ;-) (Probably for any language that would be true...)
But I also think the stack trace message example is the perfect example of what I mean by "take the Go mentality with you"
In a language like Kotlin for example, Go got my in the habit of attaching more information to exceptions as they bubble up.
I was already generally in the habit of wrapping library exceptions, but I started religiously using a Result nomad implementation and wrapping errors with additional information so that my stack traces looked very "Go-like" in terms of human readability, but kept traditional stack trace information.
It's small things that I think using Go makes you "re-appreciate" in other languages
github.com/pkg/errors is a simple way to dump expensive stacktraces into each new/wrapped error. Or you can just panic and recover in your own app, it's possible though discouraged.
It's proponents are so quick to go defensive that no one is capable of reading any complaint in an even mildly charitable light.
I mean I shouldn't literally have to say "I'm not saying you can't use Go for real work before someone flies at me." When talking about a language as widely used as Go right? Like that's common sense!
And yet of course I'm getting replies that do exactly that because of how darn defensive people need to be about it.
Saying other languages are more suited to real work doesn't mean Go isn't suited at all, it literally means other languages are more angled towards the "end product" or the "real meat and potatoes" of just making a thing work than Go.
It's literally a strength of Go. Go doesn't want to include the kitchen sink or even confine you to having a kitchen at all and I respect that.
But I'm saying that other languages that include more in the way of affordances can help one be more productive, and I believe combining a language that includes more, with the mindset of not abusing the buffet is a winning combination.
Ymmv, I'm not an oracle, I just expect people to read things in a reasonably charitable way which usually works fine as long as they're not being defensive.
You can write any language any which way, but some languages just have a culture of boilerplate vs abstractions. The most popular Python and Java libraries seem to love endless layers of indirection, and when it doesn't fit exactly what you need, you bang your head against the wall monkeypatching it to make it work since your whole app is already written in X mega library.
Go culture seems to be quite a bit more boilerplate-y and uses smaller more composable libraries. It's just refreshing.
Really I just need to buckle down on Rust, but I think it's a fair bet that teams and shops that bring in a lot of young programmers and want to ramp them up fast may cringe a bit at the learning curve of Rust.
That's why for now in terms of a bet on employability, I am prioritizing experience with Go.
As I’ve mentioned recently though, I don’t think I’d ever want to use Go as a forever solution to a complex problem. I’m sure some people could do it and do a great job, but I’m not one of those people. I need the ability to abstract and ensure more safety, or I’ll never feel secure with what I’m building.