3 ms·
I happen to agree with the author here, but I think Go has cleverly inoculated itself against this kind of criticism by driving away the sort of people who care
by iainmerrick 5y ago
I happen to agree with the author here, but I think Go has cleverly inoculated itself against this kind of criticism by driving away the sort of people who care about this kind of thing.
People who use Go generally don't care about the tedious error handling or lack of generics or whatnot; people who do care about those things generally don't use Go.
- jesseduffield 5y agoI've thought about this too: different people have different values and I think I've found myself in a situation where Go simply doesn't align with my values. I'm not claiming that Go's values are therefore wrong, just that they're at odds with mine.
- iainmerrick 5y agoYes! I'm trying not to sound smug or divisive. Plenty of good software is written in Go so it obviously has something going for it. I'd love to hear from somebody who reluctantly tried Go despite initially caring about this stuff, and was won over.
- llimllib 5y agoI guess I would fit that bill, so I'll give it a shot. I still care about stuff like this, and there are definitely ergonomic improvements that could be made. I guess my feeling is that overall, for the programs I write (network services, broadly speaking), the benefits greatly outweigh the annoyances. on the positive site, in my experience, Go: - Is easy to learn - Has a relatively small surface area - Generates static binaries - Forces you to consider error handling - (I'm listing this as a benefit as well as it's a downside!) - Is pretty darn fast, both at build time and run time - Is mostly well documented (text/template documentation excluded) - Takes backwards compatibility seriously - Cross compiles easily - Has generally very good and fast tooling - Has superb network-related libraries - Has excellent support for concurrency on the negative side, it: - Is often not pretty or elegant - It does have an aesthetic of its own once you're used to it, but it's never as satisfying as nailing something exactly right in haskell or rust, or doing something highly dynamic and fancy in python or ruby - Sometimes resists nice algorithms and data structures - this is why I would never want to use it for data science, for example - Is very opinionated - if you want something it doesn't agree with, you just don't get that thing For much of the work I do, the positives outweigh the negatives. Maybe that helps?
- iainmerrick 5y agoSounds like you're that rare beast, a persuadable swing voter :)
- Macha 5y ago> - Forces you to consider error handling If you use the result. Its easy to overlook that some more procedural functions might return only an optional err value. See also stuff like append sometimes mutates and returns a reference to a slice with the same backing array, and sometimes returns a slice with a different backing array. Nothing going to remind you you forgot to copy before returning.
- llimllib 5y agofor sure, I've been bitten by that as well. I really wish it were required to handle the err value.
- hnjst 5y agoI love "smart" programming languages and gladly write in Rust when it makes sense. However Go wins the bulk of my language picks these days, marginally thanks to the efficient tooling and complete standard library but essentially because of how easy it is to read / review / integrate / patch external code without the need to rediscover authors' specific styles and ways of doing things.
- kardianos 5y agoI've always thought that Ruby and Go are on the opposite ends of the spectrum when it comes to design. Ruby barely has a spec; Go specs first. You learn Ruby by experiencing it; you learn Go by reading the spec (or similar) and package documentation. Ruby is interpreted; Go is compiled. Yes, there are quirks in the Go language but you have to make design decisions. Yes. People who write in Go value these things. I don't value what Ruby values. And that's okay. My Go programs will require fewer tests and run faster and still compile years later.
- zozbot234 5y agoThe Go language has a spec, but the "batteries included" standard library is full of wild, unexpected behavior: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... It's really not a more reliable platform than Ruby.
- Bomaz 5y agonot even go developers find the error handling adequate. Since if it was then slice acces would return an error rather than panic. a,err:=slice[i] ...
- gnubison 5y agoDo you also believe that the / operator should return two values, a “primary” result and an error value?
- Bomaz 5y agoif golang error handling is a good way of handling errors that should be the correct implementation
- philosopher1234 5y agoYour thinking is too black and white.
- iainmerrick 5y agoGo isn’t alone there. Swift arrays also raise fatalError on out-of-bounds access by default, which seems incredible in an otherwise “safe” language. It’s easy to write your own accessor that returns an optional, but why isn’t that the default??
- fierro 5y agolol this is a great point. Go's attitude is tribal towards these things -- "if you can't see why this is a good thing, the language is not for you". I say this as a huge Go fan and daily practitioner.
- vlunkr 5y agoI appreciate this attitude. Minimalism feels a core value in Go. Bowing to the whims of every blogger would ruin that.