The absolute lack of context takes a lot of wind out of what might have been an interesting rant. It just feels hollow and pointless – I guess it might be solely targeted to people who know him as he mentions. Those people might have a clue what he is working on, why he picked Go, why he stuck with it for a year, and why after a year fairly basic things like pointers are eluding him…
It seems like a bad sign for the Go language that he understands C pointers but not Go pointers.
I disagree, I see it more as a reflection on him, but opinions will vary. Pointer rules in Go are profoundly simple (like everything in Go) and the only gotcha is in the FAQ.
I disagree. My time with Go has felt the same about pointers. They seem to often be used just for the sake of it, no real reasoning behind it.
For what it’s worth, I wrote about when you do and don’t use pointers in Go on StackOverflow.
Speculating, but maybe part of what’s different is that many languages use pointers implictly. In lots of dynamic languages and Java and C#, when you pass an object to a function/method that changes, it changes in the caller too. (C# value types are an exception.) Even in C++, the this pointer is always a pointer without you explicitly choosing for it to be, and you have references and reference parameters so you can make some &s and *s implicit. With Go, if you’re modifying something in the caller’s scope, you’re quite often (though not absolutely always) going to have a * in your function declaration.
The idea in Go is that often enough to matter, you can avoid a pointer or it’s provided implicitly by a built-in type (maps, slices, strings, chans, and function and interface values contain pointers). But you need them when what’s passed in is huge or if you’re going to modify it. Using values where you can can keep stuff off the heap, reducing memory pressure and GC time, and can reduce the chance that something modifies your struct by surprise. Not unlike why C# has value types, probably.
You do have to grok what Go is doing behind the scenes to see the reasoning behind some choices, but the reasoning is there.
My thoughts on Go from a year ago http://blog.erlware.org/some-thoughts-on-go-and-erlang/
I am a huge fan of Erlang (shipped a major production system in it) – and I will never do it again. Hiring for Erlang was an unholy nightmare. It is nice for my bill rate when doing Erlang consulting, but bad for building a business, so my startup does not use it.
Additionally, a lot of your points are fixed in Go 1.5
I will continue to cheer for Elixir and hope it hits critical mass.
Maybe his confusion was pass by value vs. reference? The one part that I think confuses newbies is pointer receivers for method definitions.
Maybe, but after a year? If you can’t nail down that concept in a year, I feel no pity for you.
“Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart.”
Either the author misunderstands the purpose of mutexes or simply failed to adequately explain what they hell they were being used for here that could be replaced by letting the service crash/restart via daemontools.
Anyway, if all Go does is provide a much better replacement for both Java and Python, it’ll be an enormous success.
Ya. It’s pretty easy to speed things up by throwing out the requirement for correctness.
The things he’s complaining about seemed like the things that you should care about when trying to work with a systems languages. It was interesting that he didn’t complain about the garbage collector–perhaps because Go makes it easy enough to make relatively memory-efficient programs, so the garbage collector doesn’t become a big source of pain.
Garbage collector is a serious source of pain in any latency dependent large app as of 1.4.2. The trick is – most Go apps are web-service type things where random latency hits can generally be accepted. Sure, you can work around the GC without too much effort, and tools like https://github.com/coocood/freecache help a good deal – but it still feels ugly.
That all said, 1.5 uses a new GC model (a mix of STW and CGC) and so far seems like a vast improvement. They are pushing the “worst case” to 10ms of pause per 50ms window… still would likely drop a frame at 60fps, but that is the worst case – common case should be much better.
I complain about every programming language I use. I just find myself complaining about Go the most.
If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell.
This sentence undermines the entire post for me. It’s nonsense. What if you want a concurrent systems language?
It’s unclear to me what “systems language” means these days, and what a “concurrent systems language” would me. In the way Go has decided to use the word, I don’t really see any large distinction between Go and Erlang or Haskell or Java for delivering something that could be called a “systems language”.
In what way would Go deliver something called a “concurrent systems language” where something like Erlang or Haskell would not fill the requirements equally? And to be clear, I’m not talking about language simplicity because that has, so far, not been a requirement of a systems language.