The horror of python dependencies, build and deploy (I currently am working on a 250k+ LOC python project) is part of what made me really love what is around the edges of Go.

There is a lot of "worse" in Go. It seems the "worse" choices were for 3 reasons: (1) make the language simpler, and (2) make the compiler / tooling simpler to build or (3) ship a production usable product in X time. I think all might yield benefits in the long term.

Getting angry about a "poor language" is pointless, there are hundreds. It seems people get more angry that it might get popular more than their favorite language. For a bit, I was a bit of a stick in the mud about Go because I was hoping Erlang (maybe with Elixir) would take off. After that I was worried it might get popular before Rust had a chance to get off the ground.

But, after having spent some time with it -- I have grown to like its odd, pragmatic mix of tooling and features.

I didn't say I was angry. I said a new language that repeats past mistakes again is sad.

The authors of Eiffel went ahead and paid a very dear price to fix their nullability-everywhere. The C# author says if he could go back in time and fix one design mistake in the language, it would be the nullability-everywhere mistake. That it is responsible for a huge percentage of field issues with C#.

Yet Go was designed after these, and still put in nullability everywhere.

Seeing society pour tonnes of resources into a bad language, when we could all have benefited from these resources being poured into a good one is sad. Having a new language with new approaches and ideas is great. But one that we already know will create poorer quality software, not so great.

What a huge waste of talent and resources we're seeing here.

P.S: Cabal is not really so bad anymore.

My experience when using "cabal install <pkgname>" is generally 90% success, and 9% failures that I can fix by a simple "cabal unpack" on some overly restrictive package to fix its version constraints and carry on.

Fixing the "null" issue isn't straight-forward. If you eliminate it completely, then you need to add sum types to the language. If you provide nullable pointers in addition to non-nullable pointers, then you're adding complexity to the language by having two different kinds of pointers. It's a trade off. The Go designers chose a different side of that trade off than you would have. That's perfectly reasonable.

I don't think you appreciate arguments for pragmatism. I write plenty of C and Go code. I rarely run into null pointer errors in Go, while I run into plenty of them in C. It's possible to mitigate the Billion Dollar Mistake without encoding it into the type system.

This null issue has come up plenty of times on the Go mailing list. Search for the billion dollar mistake, and you should find some responses from the Go devs.

> But one that we already know will create poorer quality software

We do? I think you meant, "I believe it will create ...".

Adding sum types to the language is not a bad thing. In fact, it's a great thing, even outside of nullability! It would also make error handling much neater--and not a special case--in Go. Sum types also have a natural symmetry with structs, and in language design (just like in physics), I figure symmetry means you're on the right track.

Of course, to make both of these reasonable, you would also have to add parametric polymorphism. And while you're at it, you may as well throw in full type inference. (I mean, why not?)

These aren't gigantic changes, and it's already well-understood how to implement all these efficiently--OCaml has it all, along with a fast compiler that outputs fast code.

But Go doesn't. I really wish Go had taken more (i.e. some) inspiration from OCaml.

Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made!

I know all about sum types. I love them. My central point was to show that removing nullability is a trade off rather than a freebie. I thought the context of the discussion made that clear. I feel that you did not address my point other than to say, "well yeah, but it's wrong."

> These aren't gigantic changes

Then we have a fundamental disagreement. Adding sum types and parametric polymorphism would drastically change the language. I am not claiming that the change would be for better or worse.

> Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made!

Could you point me to authoritative sources that state how languages should be designed?

Going by the character of your post, it seems like you don't care much for the cohesion of a language design. The Go devs care about this, a lot. So saying "we should add feature X, and while we're at it, Y too" without stating how those features will integrate with the rest of the language just isn't going to cut it for people who care about the totality of a language design.

>I didn't say I was angry. I said a new language that repeats past mistakes again is sad.

You do realize that these so-called language design mistakes seem to have no correlation on how successful a language will become?

>when we could all have benefited from these resources being poured into a good one is sad.

A language that nobody wants to learn is not a good language.

I pick on Cabal because when I started Haskell a few years ago, it cost me days and days... and almost made me hate Haskell. I learned to get past it and still <3 Haskell. But it isn't just Haskell, it is lots of less popular languages and toolkits, they have significant "offramps" via deploy problems, tooling problems, build problems (but not pure language problems, the core language might be gorgeous).

That said, the ability to build a static binary quickly and scp to a server is ... amazing. The convention (not forced) of localizing what you depend on in your /src and making hermetic commits is amazing in practice. It means that I simply git clone FOO && go build BAR and it builds and spits out a static binary I can ./bin/BAR