Attention, Spoiled SWEs: Take a Lesson from Go
wired.comI had to switch to go at work recently. I'm having a difficult time with it. I keep listening for what it might teach me, but it has nothing to say, and since it has nothing to say, I can't anticipate its direction. All of its design decisions seem arbitrary because I can't figure out what its goals are.
Maybe I'll wake up tomorrow and the light will shine down on me and I'll understand. But from where I'm sitting right now, the lesson go has for us is:
> Look around, the hell you see... that's about as good as it gets. There's no point in trying to find a better way, so here's the best way to not bother trying.
The author seems to think that the aspirations of more interesting languages are vanities of some sort. Like they're saying "look at me I'm <buzzword>!". But if you study the way people from different language communities behave... it would seem that whatever the buzzword is, it's actually having a significant affect on how they think and how much they enjoy coding. I don't know why you'd withdraw from that.
Your first paragraph is a great description of what I am currently feeling as well. There just isn’t anything there. I’m familiar with Python, Rust, C# and other random languages. Go just has nothing to offer meanwhile. I am struggling with nil and zero values every day, the lack of enums, and the bizarre error handling (wrapping etc.).
I’m waiting for it to click but nothing yet. Channels in combination with effortless (uncolored) asynchrony are maybe it. I haven’t reached that point yet though as I’m still struggling with just expressing my domain, without having invalid and primitive values, constructed and passed around by design, all over. I suppose it is not possible. Every time I see “url string” in a function or struct I die a little inside.
I kind of like the error handling, just because it's a little bit of character from a language that otherwise seems afraid to express itself. It has succeeded in ensuring that I don't have the error case as an afterthought, even if it's ugly as sin.
But it puts me in this mode where I occasionally want to write a function which doesn't return an err, and I think it ought to be doable, because I've declared a type for this string and I happen to know it's only one of three values, but then the lack of enums means that the type checker doesn't know that it's one of those three values so I've got all this extra runtime code for checking against error cases which could've been caught at compile time.
I think you're right that the concurrency story is the key to making it feel real: go routines, channels, etc. I haven't had occasion to use those things yet though, so it's pretty bland so far. When I hear people talk about them though it seems like they'd be better served by Erlang and have just settled for Go because it's popular.
> A move only the reigning search engine king would dare.
It was a reskin of Limbo, which they had released at Bell Labs without a lot of traction.
> Most new languages never overcome basic performance issues.
Poor performance is a problem with an implementation. Poor expressiveness is a problem with the grammar and semantics of every implementation, especially when you don't let end users extend the language to their needs.