[grepexdev]

I don't think Go is particularly esoteric to where these "gotchas" are a big problem.

In fact, I would argue that the gotchas are an intentional part of Go's design philosophy. I think it is strange to work in Go when coming from another language because of this, which leads people to think Go sucks.

[9rx]

That may be part of why they think Go sucks, but it is mostly because Go doesn't have many features to paper over poor design decisions. "Advanced" languages let you throw any old gobbledygook at them, and when you finally realize you screwed up, you can just monkey patch (or whatever feature of the day the language has) your way out of it and call it a day. Go is far less forgiving. You have to get the design right or pain will ensue. And pain does ensue for those who try it after being accustomed to having leeway in haphazard design, and thus they conclude Go sucks instead of acknowledging that their design sucks.

I mean, Go does suck. Maybe a language should be accommodating to bad designs. But still, those shouting "Go sucks" from the rooftops never seem to be willing to bring introspection into where they might have failed. It's always someone else's fault. (Something not limited to the case of Go, of course)

[ninetyninenine]

Go sucks not because it's accomodating to poor designs. It sucks because it is in itself poorly designed and that leaks over to the design of entire applications.

Why have functions return err, nil? Why even allow for a runtime error here? It's a really simple fix. You don't even have to make the language complex to support this. Instead the entire program is littered with holes and if statements you have to check in order to prevent a actual crash

[9rx]

> Why even allow for a runtime error here?

Why not? It doesn't make any difference in practice. Without a complete type system you must write tests to ensure that error conditions (to stay with your example, although this also applies broadly) do what you need of them. If you somehow introduced a runtime error there, your tests would be unable to not notice. Whether your compiler cries or your test suite cries when you screw up is not a meaningful difference.

> You don't even have to make the language complex to support this.

A complete type system is insanely complex to implement and even harder to write against.

Without a complete type system, all you can have is silly half-measures. Maybe the error becomes an optional/result type with forced unwrapping, for example, but you still haven't asserted in the types what needs to happen with the error. So you still need to write the same tests that you had to write anyway. So, other than moving where you discover the problem – from your tests to the compiler – nothing has changed.

The half-measures are a cute party trick, I'll give you that, but makes no real difference when actual engineering is taking place. They might, however, give a false sense of security. They might even convince you that you don't need to write tests (you do). Maybe those make for desirable traits?

[ninetyninenine]

>Why not?

TO prevent a runtime error. You say it Doesn't make any difference in practice meaning you never had a runtime error while running go? Impossible.

>A complete type system is insanely complex to implement and even harder to write against.

Who says you need a complex type system? You just need exhaustive evaluation of sum types. That's one feature that's it.

Removing run times errors doesn't mean building the most complex type system in the world.

[9rx]

> Doesn't make any difference in practice meaning you never had a runtime error while running go?

I am not sure I have written enough Go to comment there, but I have worked extensively in other languages where runtime errors are possible, similar to Go in that regard. I have encountered runtime errors in said tests now and then, sure, but then you know about it and deal with it... So, in practice, no different than if the compiler told you that there is a possible runtime error.

> Who says you need a complex type system?

It is needed if you want to avoid the need for said tests. With a complete type system the type system can become your test suite, so to speak. But the languages people normally use, even those with "advanced" type systems, are nowhere near expressive enough for that. Meaning that you have to write the tests anyway. And then you'll know if there are any runtime errors as soon as you run your tests because how could the tests run without encountering the runtime error too? It is not like a CPU magically changes how it works if it detects that a test is being run. So, in practice, the type system doesn't change the outcome. But it is a cool party trick. I'll give you that.

That said, aside from these hand-wavy, make-believe stories, you are still very right that Go would benefit from sum types. For the reason that they map to the human model of the world very well, succinctly communicating structures that are often needed to be expressed. Languages are decidedly for humans. You can sort of work in the same basic idea in Go using interfaces, but it is far more confusing to read and understand than sum types would be. For a language that claims to value readability...

[ninetyninenine]

> So, in practice, no different than if the compiler told you that there is a possible runtime error.

If your program has runtime errors then that means you can deploy it to production and catch your errors in production.

If your compiler catches all possible runtime errors and refuses to compile. Then you will have no runtime errors in production guaranteed by proof. The program cannot even exist with runtime errors. It can only exist with no runtime errors.

So no difference catching errors in production vs. compile time? I beg to differ. Big fucking difference imho.

> It is needed if you want to avoid the need for said tests.

I’m referring to the fact that you don’t need a complex type system to design a language that will absolutely never have any runtime errors. You’re going off on a tangent here about how you need a type system to have less tests which is completely different from what I’m talking about. This entire paragraph you wrote here is like you’re responding to an irrelevant topic.

> I am not sure I have written enough Go to comment there

Honestly it seems that you haven’t just not written enough go. But basically any programming language . It seems that you’re not clear about runtime errors and you seem to have only encountered these types of errors during tests. So yes you don’t have much experience imho and rob pike deliberately targeted the language towards people like you.