Hacker News Reader

Comment by closeparen | Hacker News Reader

After four years using Go all day professionally, I agree with all of these pros, and yet, the code volume to impact ratio is just so bad. Everything is very straightforward and understandable, the next step is always clear, I can spend an afternoon grinding out those 500 lines without thinking too much. But then I look back at what was actually accomplished in that time and it feels pathetic.

Go is a language for teams. All the cogs in the machine will spin, they will almost never get jammed, but nobody's fingers are fast enough to be particularly more productive than anyone else. Maybe this is the gray reality of mature collaborative software development. But every day I work in Go I get this gnawing feeling that software development could be so much better, that we could have been done weeks ago.

View on HN

>Everything is very straightforward and understandable, the next step is always clear, I can spend an afternoon grinding out those 500 lines without thinking too much. But then I look back at what was actually accomplished in that time and it feels pathetic.

I sometimes feel that also, but strongly suspect it is a way of thinking that omits very important parts of the equation. When you build things, most of the time you're not spending writing code, but deciding what code to write. That is the work you want to optimize and Go makes that simpler, I think, as it is often obvious how something should be done in Go. With e.g. Python, there are too many options and that, I suspect, actually slows you down. For me, using Go feels like steady progress all the time, while e.g. JS development involves short bursts of productivity followed by long contemplation and sometimes backing out or refactoring a lot of stuff. Could of course also indicate my JS skills suck I guess ;)

Not to mention maintenance - consistent style consistent implementation makes digging into 4 year old code from some random contributor oh so much easier

In Go the time is spent trying to see the forest and not the trees.

There's so much plumbing that you wouldn't have to write AT ALL in a high-level language.

My read on Go versus other options, having used it for a year or so and then switching back to other old favorites(Python, Haxe, Lua), is that it really doesn't want you to redefine the language. Go code is Go everywhere and asks you to work with a largely homogenous set of concerns everywhere.

That is great if you are building the environment for your application, but it's not great if you are building the application, because a differentiated app will always possess a unique application "vocabulary" - it's a thing that gets thought about in terms of a medium that is not the host language. Go resists extension, so most teams opt for primitivism rather than developing proprietary compilation mechanisms to express their spec. Everyone gets worried about the risks of generating code and how to maintain that: it's a "known" to have a larger fungible uniform codebase. The result is that "slow and steady" feeling when working with Go to do relatively high-level things - it lets you do it, but you have to work hard.

I think this is exactly right. I have separately used Go for more system-level code that pretty much directly wires together the standard library. Exec, x509, tar, gzip, flag, os, io, various encodings... here there is no contest. Go is a killer language for networked UNIXy stuff.

These tools also compose really well, despite the absence of generics, because they speak the common language of byte arrays. Now that I think about it, Go is a language for processing byte arrays in the same way that LISP is a language for processing lists. Go is just more subtle about this specialization, and invites you to use it for other things it is less good at.

> 500 lines

But line counts are nearly meaningless. Something like a quarter or a third of those lines are going to be a single closing brace character. So mostly we’re saying that Go’s style involves a lot of beeline characters, but that doesn’t tell us much about even boilerplate much less complexity. And to be quite clear, Go does have more boilerplate than many other mainstream languages, but line counts are a particularly bad way of measuring it.

Citation needed. As far as I know, line count is the only thing that's ever been shown to be correlated with bug count. (And that aligns with my experience, because a line with just a brace increases the number of screens you need to page through to understand a given piece of code just as much as a line with many more characters on).

Correlation isn’t on trial, causation is. That said, I think there may be some merit to the hypothesis that more code on the screen at one time makes it easier to understand a program; however, I could also see that working in the inverse, i.e., more noise (as opposed to whitespace) to scan through between the bits you care about.

The thing is... that's all the major languages. Even the ones that aren't necessarily like that, the culture / style ends up like that. The Python I'll write and pass review at work is vastly different than the Python I would like to write, because I know the next person isn't going to understand my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it.

There's the famous line from GLS about Java:

> We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.

And probably there's some equivalent idea about Go not trying to win over the Clojure programmers, but rather dragging the enterprise Python/Ruby/JS/Java programmers halfway to C.

> my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it.

That's just Python and its endless edge cases, caused by everything being special-cased into the interpreter.

If you were using Lisp, the macro equivalent of your ________dunder________ method would likely have no edge cases, so the next guy who makes a change with only a partial understanding wouldn't end up introducing that performance degradation.

With Lisp, the performance comes pre-degraded!

Maybe compared to C++. Lisp outperforms Python.

>But then I look back at what was actually accomplished in that time and it feels pathetic.

Surely that must depend on the problem space you're working in.

My impression is exactly the opposite of yours, though I must confess it took me a bit of time to build up an armamentarium of patterns that I could apply to a problem. This seems like the flip-side of the "go is a simple language" coin.

> But every day I work in Go I get this gnawing feeling that software development could be so much better, that we could have been done weeks ago.

You should definitiely give Rust a try if you haven't. It has all the pros above without the boilerplate (and even better type safety)

Reply on news.ycombinator.com