7 ms·

- 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

- 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).

papaf 8y ago
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.
- steveklabnik 8y ago
  Co-signed. (Though I’m not totally sure I agree re:kubes, but that’s not really the important part.)
- ilovecaching 8y ago
  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.
  - skywhopper 8y ago
    You've not really indicated how a multi-value return signature is even _different_ than a tuple type.
    - ilovecaching 8y ago
      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.
- shaklee3 8y ago
  And docker, to possibly a lesser extent.
- grumpydba 8y ago
  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.
skywhopper 8y ago
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.
- erik_seaberg 8y ago
  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.
  - partiallattice 8y ago
    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.
kenshaw 8y ago
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. Please stop commenting on things that you know nothing about. Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages. Additionally, from real world experience (~6 years developing major systems with Go), I can attest that none of those features are necessary for a language, and actually their presence in a language would cause me to reevaluate said programming language. Go is a breath of fresh air that is badly needed. Please stop with un- or ill- informed FUD.
- ilovecaching 8y ago
  > 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.
PopsiclePete 8y ago
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.
- ilovecaching 8y ago
  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.
vesak 8y ago
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.
wahern 8y ago
> 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.

papaf 8y ago

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.

steveklabnik 8y ago
Co-signed. (Though I’m not totally sure I agree re:kubes, but that’s not really the important part.)
ilovecaching 8y ago
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.
- skywhopper 8y ago
  You've not really indicated how a multi-value return signature is even _different_ than a tuple type.
  - ilovecaching 8y ago
    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.
shaklee3 8y ago
And docker, to possibly a lesser extent.
grumpydba 8y ago
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.

skywhopper 8y ago

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.

erik_seaberg 8y ago
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.
- partiallattice 8y ago
  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.

kenshaw 8y ago

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. Please stop commenting on things that you know nothing about. Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages. Additionally, from real world experience (~6 years developing major systems with Go), I can attest that none of those features are necessary for a language, and actually their presence in a language would cause me to reevaluate said programming language. Go is a breath of fresh air that is badly needed. Please stop with un- or ill- informed FUD.

ilovecaching 8y ago
> 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.

PopsiclePete 8y ago

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.

ilovecaching 8y ago
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.

vesak 8y ago

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.

wahern 8y ago

> 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.