Hacker News Reader

Comment by sethammons | Hacker News Reader

What is lacking to qualify Go as a "real" language?

- no generics. Without generics you can't build reusable data structures or algorithms that are type safe. The only ones that are available are hard coded into the language.

- lacking sum types (enums), which is why you have to explicitly check every return value with if err != nil. Sum types enable useful patterns like Maybe, Either, etc.

- general wackiness, from a computer science perspective Golang bakes a lot of special cases into its semantics that could be handled by including fundamental types. 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. This is how Python and Rust work. (Tuples are also useful in many other contexts). The Go way is to have a rule that a function can return multiple values from a function and receive them at a call site. It's not pattern matching, and its not tuples, it's just a special case that defies the mathematical model of a function (a mapping of a domain to a single codomain).

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.

Operator overloading?

Reply on news.ycombinator.com