As someone who enjoys programming in both Go and Rust I find this sort of fanatical comment distressing.

Go makes different tradeoffs. Get over it.

Nobody has written anything as important as Kubernetes in Rust yet. I hope that someday somebody does write something worthwhile but please less of the fundamentalist attitude that had poisoned religion and politics.

Co-signed. (Though I’m not totally sure I agree re:kubes, but that’s not really the important part.)

There are also at least 10 different teams using Prometheus/grafana at the big bank I work for.

Those go softs are usually stable and easy to install. We have yet to use a rust developed program.

Usability matters, and the much much higher learning curve as played against rust.

If they’re trade offs, why is the Go team making proposals to add genetics and result types?

Trade offs are one thing, defecencies are another.

And if you can think of a reason why hard coding multivalue return signatures would be better than a tuple type, then I’d like to hear it.

You've not really indicated how a multi-value return signature is even _different_ than a tuple type.

A tuple is a type constructor. A multi value return is not a type. It’s a semantic hard coded into the language spec. If you have tuples, you don’t have to add that special case to the language. You can also type alias a tuple, store it as a value, and just generally treat it like any other type.

And docker, to possibly a lesser extent.

You totally forgot Go's worst feature:

- in spite of theoretical weaknesses, Go empowers developers to get shit done, causing dreadful cognitive dissonance for academic programming linguists

I feel you, though. I was you some time ago. You need to let go of the feeling that programming languages are the most important thing in the world. Until you do, that feeling will just pull you down to a place where nothing's good enough.

This is a strange list. The reasons for putting off generics have been made very clear. Fast compilation and simpler syntax are not unreasonable tradeoffs to make in exchange for waiting for a fast and simple generic syntax.

And your argument against multiple return values makes no sense. How is using a tuple type better (or even different, in practice)? And your pointing to the mathematical definition of a function is pointless. A function has a very different meaning in programming languages than it does in mathematics. Mapping a domain to a single co-domain is not what functions do in the vast majority of programs.

You can return (string, error), but then what? You can't send them over a chan (string, error) or append them to a [](string, error). You can work around this by defining a bunch of struct types, but that's exactly what multiple return values was trying to avoid, and making a human being read and write that boilerplate is far more expensive than having the compiler supply it.

So much this. Every time I want to make a function async, I have to write my 5010th `ErrorOr` struct to send over a channel. Even if they would only add the multiple return hack to channels, that would save me a bunch of pain.

> If you want to do multi-value return, the sane thing is to use a tuple, which is a core data structure we all learn about in CS undergrad, and use that as a return type and have functions return a single value

You could say the same about function argument lists--that functions should only take a tuple.

IME the reason some particular language only permits returning a single value is typically either (a) convention or (b) a reflection of implementation details.

It’s weird how I’ve managed to write so much reliable, production code at my work without “sum types” and “real generics”. Man, all those people who wrote OS kernels in C or mobile apps for iOS in Objective-C need to just throw away their work - it’s all garbage written in non-real programming languages.

So first of all, Apple invented a new language to replace Objective-C (they also added generics to Objective-C), you might have heard of it. Secondly, some kernels have already been written or partially written in C++ (the NT kernel for example). Of course, not many people are writing kernels, but those writing new kernels (fuschia, redox) are being written in either a mix of languages or a completely new language. Otherwise, older kernels like Linux were written decades ago in a very different landscape when other languages made little to no sense. Things have changed.

So your comment is kind of unsubstantiated. And as I said, things have changed, and things will change. We can either do as you imply and keep using C and languages without "sum types" and "real generics", and keep creating security vulnerabilities and broken software, moving at a snails pace because we have poor methods of reuse, or we can aspire to build better tools to build better software. I am squarely in the latter camp, I think we should aspire to keep evolving.

> You do not know what you are talking about. It is very clear (based on the above statements) that you have minimal, if zero real computer science education.

I don't know why you're attacking me personally. I went to a UC school with a great computer science program and have a masters degree... does that count?

> Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages.

Sure, and Go is merely a collection of semantic conveniences over Brainfuck, it's Turing Complete, so what do we need Go for?

The point is that Go heavily limits a programmers ability to create new abstractions and write reusable algorithms. For writing glue code, cli tools, or web services, that's probably fine. But there's a purpose behind those pesky data structure and algorithms they teach you in school, and when you run into what I consider to be the "real problems" Go is not a "real language" that can tackle those problems without the same pain as Brainfuck.

> actually their presence in a language would cause me to reevaluate said programming language

This is completely ridiculous. I hope you realize this statement is completely ridiculous. Just because a language has something you don't understand or don't find useful doesn't disqualify it from being a better language than Go. You have your own blinders on.

> Go is a breath of fresh air that is badly needed.

Go appeals to the lowest common denominator. In fact, one of the goals was to come up with a language that new grads coming in to Google could easily pick up. It's designed to appeal to new people. This is fine, Go is a great language for a lot of small tasks. But as you grow as a developer, you need to tackle larger problems. Go is not a language that facilitates tackling larger problems.

> Please stop with un- or ill- informed FUD.

You certainly need a dose of skepticism. Radically following one language or one technology isn't a good move for an engineer. Go has flaws, and if you can't discuss them then you're not separating the technology from an argument from emotion.