Go is a terrible language (2020)

https://debugged.it/blog/go-is-terrible/

51 64 5 years ago

follow-up post : https://debugged.it/blog/20000-lines-under-the-go-cean/

kvnhn• 5 years ago

Thanks for sharing this. It's very hard to lend credence to this series after reading this follow-up. Quoting from the link:

"There are certainly many reasons to hate Go, from the unusual syntax to the half-arsed way they decided to implement the programming model. On the other hand you can go all fanboy over how cool Go is because it makes it so simple to write microservices. (No, it doesn’t. It really, really doesn’t if you want to do it properly.)

If you jumped on either of these bandwagons, I would recommend getting off as soon as possible. Neither of these approaches are very professional and are telling signs of inexperience in software development."

There is an upsetting level of hypocrisy in patronizing your readers for consuming the clickbait-titled articles _you authored_.

jgrant272• 5 years ago

    Most applications I tend to see don’t even use concurrency because they are so small and simple that they don’t need it.

Sorry but I just can't take your opinion of any language seriously or that you have much practical experience at all because of statements like this.

mst• 5 years ago

Having once replaced a sixteen core go program with a single-process perl script that completed the same task 4x faster, I think remembering that a lot of the time we (as a profession) manage to overengineer things is worthwhile.

nassimsoftware3• 5 years ago

The thing with Go is that I find the syntax very ugly to look at however it is so convenient to install, run, deploy, make performant applications.

yannoninator• 5 years ago

why do you find it ugly?

joshxyz• 5 years ago

One for me is the "if err" everywhere lol, but i like how it has great ecosystem like nodejs

nassimsoftware3• 5 years ago

An example :

  for _, a := range albums {
        if a.ID == id {

            c.IndentedJSON(http.StatusOK, a)

            return

        }

  }

is ugly compared to a much more readable :

  for a in albums:

     if a.ID == id:

         // the rest of the code

  albums = append(albums, newAlbum)

is ugly compared to

  albums.append(newAlbum)

Edit : I have trouble formatting the code. How do you do this on HN ?` doesn't seem to work.

Edit 2 : Fixed the formatting issue.

rtoway• 5 years ago

I'm not a Go fan but the language to me looks very readable and clean. However in my opinion syntax is usually not that important, you can and will get used to anything

ronnier• 5 years ago

The thing that gets me is how time is handled, enums, no sets, no way to make variables final, the "make" syntax, could probably go on

teeray• 5 years ago

However, the larger problem is that functions don’t declare what kinds of errors they return.

They don’t need to. Static analysis (guru) can answer the question “what kinds of error can this error be?” There’s no need to go source diving as the author suggests.

lokar2• 5 years ago

IMO this is a common failure in discussions about programming languages today. You really must consider the capabilities of "external" language tools (linters, static analysis, etc).

Not having all that in the core language can be a reasonable design choice.

ashtonkem• 5 years ago

It does depend somewhat on the quality and unanimity of those tools. Back when I did python there really wasn’t a consensus, well developed set of static analysis tools in order to answer these questions. This made programming python harder than it should’ve been, and the process of building those consensus tools was unnecessarily messy, and probably cost python more devs than need be

Not having it in the core language can be a reasonable choice, but you still need to do community work to ensure that those needs are met somehow

animex• 5 years ago

@dang will HN ever support code blocks in comments? pls.

eyelidlessness5• 5 years ago

Indent 4 spaces, you’ll get monospace. Not syntax highlighted but I doubt you’ll ever see that here.

gus_massa• 5 years ago

Nitpicking: 2 spaces for HN, and 4 spaces for GitHub.

bfung• 5 years ago

You can get fixed formatting by newline + indenting 2 spaces, similar to non-GitHub markdown

  # Like this
  y = mx + b

The “help” link could be added to more places while authoring, as it only shows up on the “edit” post screen atm.

https://news.ycombinator.com/formatdoc

jgrant272• 5 years ago

    Have you debugged.it ?

Debugging seems to be the author's coding philosophy which says it all.

    While I had over a decade of experience in other languages, such as Python, PHP, Java, etc. 
    I found it extremely difficult to wrap my head around Go.

This could be because the author's introduction to programming and most of their experience has been with some very problematic languages.

Maybe it's not Go that is a terrible language but just that the author is not a systems programmer who has worked with large code bases ?

ClumsyPilot• 5 years ago

I think this criticism is very unfair, if there is one thing java is (in)famous for, its large codebases. Kafka is written in it. I myself don't use it, but you need to substantiate your argument.

Is there any reason you believe python and java are 'very problematic"? Isnt every language promlematic in its own way? Are they more problematic than C, which breeds foodguns, or what are we comparing to?

tgsovlerkhgsel• 5 years ago

No, it doesn't get any better when the codebase is bigger. The way to figure out WTF went wrong in a large code base written in Go is:

1. Take the line number where the error was logged, likely somewhere very close to e.g. the main event handling loop, and completely disconnected from the place where the error was initially thrown. There is no stack trace.

2. Try to figure out which parts of the error string are constant (i.e. searchable), and pray for the developer to have been familiar with the issue so that the string is globally unique (corollary: When writing Go, make sure your error strings are unique, introduce some form of variation if you're throwing similar errors, even if it's just punctuation or synonyms, to make sure the throw site is identifiable).

3. Try to guess what the flow between those two sites could have been.

The lack of proper stack traces (or even the line number where the error was thrown) on errors is one of the most insane effects of this error handling approach. (The other is hard to read code because the actual logic is hidden in 3x as much error handling boilerplate).

systemvoltage2• 5 years ago

I’m not sure if I buy that. Did you read the article? The author is expressing explicitly what’s wrong in many areas and why they’re useful. I don’t like rebuttals like this because it then becomes a self-fulfilling prophecy of Go-lovers avoiding criticism from outside because “They won’t get it due to their background”. Great, now we’ve just created an echo-chamber. It’s good to get outside perspective and debate. I’m sure many Go experts would like to understand where they could improve - without losing Go’s core minimalism.

Author’s tone could be better but they’re just being straightforward that they don’t like Go and specifically why. Totally ok in my view.

deltasixeight2• 5 years ago

Go is an ugly language. Practical but ugly.

didip• 5 years ago

No way, Go is beautiful based on this 1 metric: It always looked the same regardless who wrote it.

It makes PR review job so much easier, and to me, that's beautiful.

ohCh6zos3• 5 years ago

It always looked the same regardless who wrote it.

This is Go's biggest anti-feature to me. I can't stand that all code in Go is so similar.

erik_seaberg2• 5 years ago

You're wasting your experts' time if they cannot write (or reread) clearer, more concise code than your beginners.

deltasixeight2• 5 years ago

Ease of reading is a practical feature not a beautiful one. If you think practicality is beautiful well great.

eyelidlessness5• 5 years ago

I’ve never written a line of Go, though I’ve read a fair bit. I was expecting to object to the criticism of its error handling but I ultimately agree. If you can return and ignore an error, that’s another way of saying throw/raise. If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”. I had thought, not paying much attention to Go in particular, it must deal with this with something like an Either type. Even some language facilities to automatically unwrap Either and rewrap for callers if unhandled would be a great answer to the checked exceptions debate. But what I take away from this is errors in Go are just as amorphous as in JS but harder to find. That’s quite a feat!

bigdict• 5 years ago

It's just an improvement on error handling in C without introducing heavyweight exceptions.

erik_seaberg2• 5 years ago

They did introduce panic, they just discourage anyone outside the language design team from taking advantage of it. I find "better than C" to be a pretty disappointing target.

klodolph3• 5 years ago

I write both Go and JavaScript.

If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”.

Errors aren't untyped. It's an interface type. Not everything returns errors anyway, they definitely can't be returned from anywhere in the stack.

Errors in Go are definitely nowhere near as amorphous as those in JS. In JS, you can take an Error object and stick additional properties on it, and then throw that. In fact, Node does that, and by extension, thousands of JS libraries generate exceptions like that.

With Go, you use errors.As(), or errors.Is(), or a little bit of dynamic casting. The type of error which a function returns may not be part of its type signature, but decent libraries usually have only one or two error types they return. Yes, I hit F12 to see the library's source to see what errors it returns... but that's just because the IDE experience with Go is so fast and nice to use.

eyelidlessness5• 5 years ago

The article talks about returning strings as errors, which I read as equivalent to (JS):

    throw 'wat'

Which doesn’t seem like a very useful interface to me. Everything can be stringly typed. But again I’m looking at this from the outside.

And by not typed, I specifically meant in the function signature. If tooling helps with that, that’s awesome.

ed_elliott_asc• 5 years ago

So the general complaints of the article is that go isn’t Java?

aranchelk• 5 years ago

Seems a little more thoughtful and extensive than that, e.g. the Nullability section. AFAIK that’s not properly solved in Java either.

Also I’m guessing the section on immutability isn’t referencing something special in Java, dunno.

deepsun3• 5 years ago

More like Kotlin, as nil problem exists in Java, but not in Kotlin.

NelsonMinar• 5 years ago

I don't love that Go doesn't have exceptions. But it was a choice made thoughtfully:

https://golang.org/doc/faq#exceptions https://go.dev/blog/errors-are-values

vasilia• 5 years ago

There is one more reason. When you write something that works in a loop, e.g. web server, exceptions are a huge potential issue. I was working on a C++ project with a very complex state machine. One day our service started using all 128 CPU cores just for stack unwinding. It was an ordinary exception in 3thrd party library raised on every request in the loop. We have tried to make a lot of optimisations in different unwind libraries. But it was far away from the performance of a simple Optional-like errors container as a return value. Exceptions are really Zero-cost if they occur only once when application should be terminated.

ohCh6zos3• 5 years ago

The last two companies I have been at switches from other languages to Go. At this point I don't see what people like about Go. This article touches on problems, but it is only the tip of the iceberg.

bedobi• 5 years ago

The worst problem with almost all popular programming languages are null and shitty error handling, such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception/hidden error response, but most compilers happily let you treat it as if it only ever returns a String. (What!!!?)

I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default. (BTW, there's really nothing "Functional Programming" about them, they're just objects like any other in "Object Oriented" languages)

angelzen2• 5 years ago

Not top 5 languages, but Scala & Rust fit the bill.

phil294• 5 years ago

Even JavaScript does, with strictest TypeScript settings (not on Exceptions though). When I returned to a Java project recently, the lack of null safety was seriously off-putting. It does indeed feel like the "billion-dollar mistake" of programming.

deepsun3• 5 years ago

Kotlin as well. The result type is "String?".

klodolph3• 5 years ago

...functions don't declare what kind of errors they return.

We've gone down this route with Java and my conclusion is that declaring the kind of errors a function returns is, for most users, just a pain.

https://www.artima.com/articles/the-trouble-with-checked-exc...

My experience with Go is that decent libraries only have a small number of error return types, and then forward or wrap errors from libraries that they use. You can use errors.Is(), errors.As(), errors.Unwrap() to figure things out as necessary.

hota_mazi• 5 years ago

It's a pain because it forces users to consider and code against error paths.

Just like putting on a seat belt is a pain.

Both are pains that are worth having because they help you create robust software.

The ways in which a function can fail should absolutely be part of its signature, and if these are recoverable, the compiler should refuse to build until you either handle these errors or pass them on to the caller.

bsder• 5 years ago

The ways in which a function can fail should absolutely be part of its signature

The problem with that is that a downstream library gets welded to the specific errors it can throw and can't evolve.

So, what everybody will do is generate the most generic "Error" possible so that the signature never needs to change. That is NOT an improvement.

nobody0• 5 years ago

Is there possibility that go adds algebraic datatype and pattern matching? error handling will be nicer that way generally.

mftb• 5 years ago

This article is a poor choice for submission. He did a companion article that is the exact opposite, and a follow-up article a year later. The follow-up would be a much better choice. It gives links to both prior articles and his thoughts after a year of reflection - https://debugged.it/blog/20000-lines-under-the-go-cean/ .

mixmastamyk• 5 years ago

The language is rough but the performance, tools, and deployment is top notch. That dichotomy was quite surprising to me.

If someone could write a "coffeescript" for it, perhaps a python+pascal love-child, while keeping the fantastic lower-level parts of go, I'd be all over it.

systemvoltage2• 5 years ago

This post should not have been flagged. It is a completely valid criticism of Go. Author's tone could have been better but I'd rather hear straightforward opinions and not polished speech to offend those that cannot defend Go. Personally, I am a huge fan of Go but these are some valid points.

Anyone supporting such flagging behavior is completely against the spirit of what made this place great. Please reconsider your actions and what flagging does on HN.

nunez• 5 years ago

Make sure you read the OP's follow-up before cargo-culting on the "Golang bad" ship: https://debugged.it/blog/20000-lines-under-the-go-cean

(I actually quite like Go, despite it being more difficult to write tests for than other languages, and error messages usually being very cryptic.)

BrandoElFollito• 5 years ago

I am an amateur dev (for 25 years), using mostly Python. I was blackmailed by a friend to try Go.

Boilerplate, no exceptions, slices, ... all felt terrible.

And then I started to appreciate the typing and the fact that I had to give some thought about where to actually handle errors.

I know kinda like Go, except for the weird way maps are handled, and the lack of types in errors (compared to Python where it is fantastic).

There are certainly pros and cons (I am not a good enough developer to have advanced thoughts on that) but the cross compilation makes a lot of things easier when deploying self-contained executables.

Go is a terrible language (2020)

Related Stories