Comment by avl999 | Hacker News Reader

Comment by avl999 | Hacker News Reader

Parent Full thread

It is a language for people who like to get things done and get reasonably performant code for free. Relative to folks grinding in some of these dynamic languages doing contortions to deal with basic things like concurrency, twisting themselves into unimaginative ways to get that code coverage bump from 90% to 100% (the hardest part) just because their language cannot provide a semblance of guarantee that code "works" or has no syntax errors unless it is ran, unable to refactor without confidence unless the entire team is willing to commit to 100% test coverage and even with the test coverage the refactorings taking orders of magnitude more time than Go as now you need to parse through your test results to see exactly what your simple refactoring of changing a method name or moving a method from one file to another broke and then fixing it as opposed to the superior tooling of Go (or some other similar statically typed language) just doing all that for you in the press of a few keystrokes. It is also a language for those who like seeing a lower memory foot print, a lower cpu foot print, a simpler distribution story (literally copying over a binary to the target system)

The verbosity of Go (and even Java for that matter) is 100% worth it for me for all those reasons. It allows me to iterate fast, make changes with confidence and not have to feel guilty that my test coverage is only 92% because I am not going through the trouble of covering some branches of code that returns an error message (that would otherwise require annoying effort to trigger in your tests) as the compiler guarantees that all those

`return errors.New("some error")`

will execute if the error condition is ever hit in production which was not the case when I was working in python unless I went through the effort of having my test cover that bit of code.

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.

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.

>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.

> 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.

> 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)

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.

>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.

> these dynamic languages doing contortions to deal with basic things like concurrency

I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines.

But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?

Yeah the compiler guarantees that a certain class of errors can never happen and thus you don't need to go through significant effort to cover things like error returns.

Additionally with a dynamic language where the codebase has less than a 100% test coverage I would find it very hard to refactor anything without sweating bullets. The compiler is giving you a free test suite.

Because Ruby and Python force you to unit test for typos.

I like and use both of them but if you're trying to argue that the testing problem in Python is the same as that of Go or Rust, that argument will fail.

> if you're trying to argue that the testing problem in Python is the same as that of Go or Rust

Wasn't trying to make that case, but I can see how my comment could be read that way.

I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.

Pyflakes should be the first "test" run, and it finds those kind of issues.

Sounds like you just want a statically typed language, because you've been scarred by Python. I'm sorry that you had to deal with what sounds like poorly maintained medium or large Python code base.

After you get some experience with Go, you might want to explore other modern statically typed programming languages (I suggest Kotlin and Rust).

When you know the strengths and weaknesses of each, you'll be able to pick the best one for the job. And the concepts learned often translate from one language to the other, which will make it easier to pick up new ones in the future.

Rust does not solve the problems that I deal with in the kind of work I do. I have no interest in picking up Kotlin. Java/Go/C# solve all the problems that Kotlin solves without the interop headaches and I pick between them for production code depending on the team and the platform we are targeting. For the projects that I am working on right now I specifically want Go because of its faster startup time than Java/C# and the ability to spin up 10s of thousands of threads without breaking up sweat which is needed for the sort of work I currently do.

The constraints of fast startup + "green threads" + easy deployment are actually a sound argument for using Go. The simplicity of the language isn't.

Kotlin and Rust also have the "green threads" [1] that Java lacks, both of them can also produce a native binary giving you fast startup. So the claim that "Java solves all the problems that Kotlin does" is not completely true.

Finally both Kotlin and Rust can let you write safer concurrent code, because their type systems actually can enforce constraints on what's shared between threads, and what's immutable and safe to accesss. Go gives you nothing in the type system, but there is a thread sanitizer.

[1] Here's a Kotlin program that spins up 100K coroutines: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kot...

Here's a Java program that spins up 1 million virtual threads: https://webtide.com/do-looms-claims-stack-up-part-1/

Yes, Loom is an exploratory project to enable this, as far as I know, it is not a part of the mainstream Java release yet.

> The simplicity of the language isn't.

There’s a pretty strong consensus among people who have used Go professionally (irrespective of whether or not they liked the language on balance) that the ability to look at any project and immediately understand it is a Good Thing, and this property follows directly from the language’s simplicity.

That doesn’t mean it outweighs all other criteria—we can say that there is a tradeoff between readability and expressability or something like that—but it absolutely follows that simplicity is a merit.

To boot, some other things that I would prioritize well above any particular type system feature set (at least features in excess of what Go provides) include: ecosystem, reproducible build tooling, general tooling, performance, a solid standard library, friendly community, static compilation by default, easy learning curve. Note that “tooling” must also be simple to be a boon—I don’t want to have to learn a DSL to script my dependencies, wire up test targets, build static artifacts, etc.

Why am I not surprised that such low level of passive-aggressive attacks on Go are coming from a Rust enthusiast. I don't understand this stance. It's as if they feel threatened by Go when in reality Go doesn't even try to compete in Rust's niche. They sit distant appart in many spectrums.

It's hardly constructive comparing these two languages due to their different objectives. Yet there's this constant belittling of Go as if it was a menace to Rust somehow.

In professional environments, this kind of emotionally loaded tribalistic judgement has not place. Much less in engineering.

This problem has even been acknowledged by a moderator on HN: https://news.ycombinator.com/item?id=26732757

> Here's a take: Go is a language for engineering managers who occasionally contribute a ten liner. You can learn just enough in between your many meetings to make a simple change. You can feel proud and happy with how easy it was for you to contribute. And you can dump the verbose, repetitive drudgery onto the people below you in the org chart, it's their job to deal with this after all. But in a language that you can easily understand, you'll make sure to push for that.

Reply on news.ycombinator.com