Hacker News Reader

Comment by destevil | Hacker News Reader

Go isn't a serious language for large systems. The language allows writing shitty code and the community has largely adopted that. Go fanatics will hate this, but you simply can't compare it with the ability to write and maintain in languages like Java.

View on HN

I'll bite. Why can't you compare it? Is it the class/function on struct thing? Generics? Go-routines not threads? Rob Pike did say once that the GC is deliberately not tunable because a JVM knob-twiddler should not be a job title.

Many reasons including:

* Poor modeling ability (lack of default interface methods, no records, pattern matching, exhaustiveness checks, etc.).

* Error handling is error prone. * Generics are half baked.

* No short hand syntax for passing functions as lambdas.

* No annotations.

* Implicit interfaces make it hard to navigate large code bases because it is very easy to accidentally implement another interface. There are better solutions for the problem they tried to address with structural interfaces. * No string templates.

* The GC not being tunable does not obviate the use cases where it needs to be. Furthermore, Java's ZGC only has a couple of knobs anyway, while giving you the option to use a more tunable GC when your use case calls for it. golang's GC is only tuned for latency at the expense of throughput.

* goroutines are half baked, see Java's virtual threads + structured concurrency for a more manageable approach.

* Observability way superior on the JVM.

* No proper enums.

* No const/final variable declarations.

* Visibility rule are crude. Only public or package private.

* Probably more things I didn't think of at this time.

decent list, to be fair

Can you give an example of 'shitty code'? We've got murmurs of Go being adopted by some teams so if you have first hand experience it'd be really useful

Single letter variables. A terrible pattern the go community picks up.

Single letter variables like `i`, `j`? How `index1`, `index2` is any better?

My guess is that he means, he would prefer variables to be more descriptive. Easier to read and follow.

Eh. Yes and no. I have not worked on a team that enforces that and I do agree with using them for short functions with 1 or 2 types. I do this in python as well

  with open(..) as f:

I have never seen this done in enterprise Go code, and I don't think it's been strongly recommended since the mid 2010's?

For small functions where you can see everything in a single page, this is fine. Though I think they should always be avoided except the most common cases (`i` for index) because keeping a codebase grep-able is a high priority. Using constant, verbose variable names can make tracing through a codebase much easier.

Is that really the best argument against Go lmao ?

I've heard that this is the result of snake-case refugees from C, Python etc. Single letter variables are camel and snake, everyone's happy.

As a counter anecdote, I've worked at two large companies with monsterous Go codebases and they are totally fine to maintain. There is no justification to the claim that Java repos are "easier to maintain" by the above commenter, as we have decade-old Go codebases that doing great.

I'm just as fast/productive in Go (8 years of experience) as I am in Python (13 years of experience), but the resulting code is:

    * more maintainable (enforced typing vs typehints+mypy)

    * faster (compiled vs interpreted)

    * consistently structured / opinionated (until recently we didn't have generics, which meant that engineers often had to do things the "boring and verbose way" instead of the "clever and concise way" which, though frustrating short-term, has proven to be much better for maintainability long-term.

There's no reason that your company can't support multiple languages. Uber has large Go monorepos, Java monorepos, Python monorepos, etc. and they all work in harmony and with different requirements.

OOP languages like Java are not considered to be good.

Considered by whom?

By people who don't like OOP languages.

It's an appeal to (pretend) authority by people who won't or can't make a real argument.

This isn't a serious argument, you can write 'shitty code' in Java too. In fact, I've seen more 'shitty' Java than 'shitty' Go, since I've seen far more Java projects than Go projects. It's possible that Go makes it particularly easy, but I somehow doubt that.

Java also has null and overall a weak type system. They're pretty close in that respect, actually.

From the point of view from Go folks, we need a PhD for mastering Java's type system.

It has slightly more expressive generics, but otherwise no more complex overall. And no more useful, except perhaps for typed errors.

The biggest cause of bugs in Go I find is the weak type system. Nulls, untyped (and overly verbose) errors and the lack of sum types are a big problem.

Proper enumerations, sum types, pattern matching, exceptions, default interface implementations, dynamic loading, class loaders, annotations, compiler plugins,...

Java sum types and pattern matching are almost impossible to use in practice, sadly. Exceptions aren't a good thing, it's only good that they're typed. Go has exceptions too, they're just used rarely.

The rest is not very interesting or particularly complex.

Word salad, hand waving that Java has indeed a much better type system.

It’s a little better, for sure. It’s nowhere near something sane like OCaml or Rust.

I don’t particularly like Go or Java.

I don’t see what salad has to do with anything I said. Go does have exceptions and unlike Java, they are untyped and rarely used. They’re not great in either language.

You’re loading your ideas of other languages into Go and with this current Go team that’s wishful features

Not at all, I rather use other languages instead of dealing with frustation.

I apreciate what Go offers as a better C alternative, similar to Limbo's role in Inferno, and that is the only thing I will advocate Go for.

Reply on news.ycombinator.com