Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
> I didn't get that desire for purity that you gleaned from it.
'Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions.'
This mutability argument is present throughout the article. Seems like nothing sans Rust or niche functional languages is enough.
> Nil pointer exceptions, for example, don't have to exist anymore..
The language most notorious for those is Java due to almost everything being passed via a nullable reference. When everything can be nullable, how can you know where to check for it? Go addresses this to an extent by explicitly separating pointers from values. Values are the default and cannot be nil, so the opportunity for null dereferences is greatly diminished. It's not a perfect solution, but it's not nothing either.
> and yet they do in Go because they couldn't be bothered to add sum types.
Damn those lazy Go devs!
> Its type system is barely a step above a dynamic language.
Turns out even a basic type system is a huge improvement over none. Just being able to restrict values to concrete types goes a long way.
> You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter).
There are arguments to be made either way, but I definitely agree generics (along with iterators) should have been there since day 1.
> Every function that does meaningful work is littered with if err != nil { return err }.
One big positive of this that I don't see in other languages is every `return` in a function must be on the start of a line. That is, every single exit path of a function is easily findable by visually scanning
I use Go heavily cross-platform developing DataStation [0] and dsq [1]. I am not an expert. And I don't have proof for it but on some rudimentary benchmarks the Linux-specific file idioms in the Go standard library definitely don't seem to translate well to even macOS let alone Windows. For example some good streaming techniques for reading large files on Linux that work really well there seemed to be pretty bad on macOS.
I think Amos has presented more proof than I can on the topic of just how Linux-influenced Go is. And I think it is fine for the majority of Go users because the majority users of Go are building server apps or Linux CLIs.
Amos has spent some time building cross-platform desktop systems with Go for itch.io and I think I'm seeing some of the same things they are in that scenario.
I think this is a reasonable article. If Amos gets flame-y at any point I think it's worth ignoring because there does seem to be something up with Go in cross-platform applications.
I like Go a lot and for most things I'd keep using it still. Just sharing some observations.
[0] https://github.com/multiprocessio/datastation
[1] https://github.com/multiprocessio/dsq
I use Go heavily cross-platform developing DataStation [0] and dsq [1]. I am not an expert. And I don't have proof for it but on some rudimentary benchmarks the Linux-specific file idioms in the Go standard library definitely don't seem to translate well to even macOS let alone Windows. For example some good streaming techniques for reading large files on Linux that work really well there seemed to be pretty bad on macOS.
I think Amos has presented more proof than I can on the topic of just how Linux-influenced Go is. And I think it is fine for the majority of Go users because the majority users of Go are building server apps or Linux CLIs.
Amos has spent some time building cross-platform desktop systems with Go for itch.io and I think I'm seeing some of the same things they are in that scenario.
I think this is a reasonable article. If Amos gets flame-y at any point I think it's worth ignoring because there does seem to be something up with Go in cross-platform applications.
I like Go a lot and for most things I'd keep using it still. Just sharing some observations.
[0] https://github.com/multiprocessio/datastation
[1] https://github.com/multiprocessio/dsq
The author of the blog post literally covered it in the article he wrote two years prior that's linked in the first sentence.
It's not "TCP issues in Go" it's "Go leaves you to figure these things out for yourself and write bad code that doesn't work if you don't thoroughly understand its gotchas."
Also, if you've been following Go over the years, you'll know that there's basically _always_ open issues (https://github.com/golang/go/issues/39063) in net & net/http about how Timeouts get mishandled and connections end up not being closed.
Cloudflare even had to write a whole article explaining how to "do it properly" https://blog.cloudflare.com/the-complete-guide-to-golang-net... so that you don't footgun yourself.
Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc.
A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, reference counted) and not worry about any of the low level memory management details.
See things like https://ggez.rs/ for games and https://www.arewewebyet.org/ for web stuff.
Although honestly I think if you're looking for a "hot" backend web language I'd say Elixir is the more well designed one than Go.