4 ms·

I write golang, and am a big fan, however it lacked/lacks some features that i would expect in a modern language. - Lack of generics(coming very soon) was a hu

I write golang, and am a big fan, however it lacked/lacks some features that i would expect in a modern language. - Lack of generics(coming very soon) was a huge problem for a long time and resulted in masses of duplicated code, and shonky reimplememtations rather than battle tested reusable implementations. - Lack of sum types, which is particularly frustrating with go's error handling model (which I happen to be a fan of, mostly). The state of a return value depends on another return value in many cases. There is nothing in the language stopping me from using the value returned from a function that has returned an error. Even c++ has a (half baked) solution for this with optional. - go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. - repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. - cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. > that took into account & understood the practical tradeoffs Go is making. Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings.

philosopher1234 5y ago
>Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings. I never said it was immune to criticism. I think most of the criticism is misguided. >- go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. I recognize that this does not perfectly map to your mental model, but why is this a major issue? I think major issues are those that cause practical problems. I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. It's a bit like saying "that tire isn't perfect because it can pop, so lets use a metal tire instead". Sure, you fix one issue, but you create others. >- repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. This is too vague to evaluate. There is a point at which repetition becomes a problem, and there is a point at which repetition is cheaper than having an abstraction. I don't think it can be evaluated in general. > cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. I agree on the factual level that it would be nice if cgo didn't have so much gc overhead. If this is meant to be evidence that go is a bad language, I would disagree.
- nicoburns 5y ago
  > I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. That's the thing about Sum Types. They're not really an advanced feature at all: they map to an extremely intuitive human concept: "or". They reduce cognitive load. That's the advantage of having them. In fact, I suspect that a lot of the reason that dynamic languages are considered simpler is because every variable is essentially one big sum type. Trying to represent "or data types" without sum types requires you to use interfaces which are a much more advanced language feature, and are very awkward for the use case of a finite number of known cases. You could have a perfectly functional language with only logical AND (&&) and logical negation (!) and no logical OR (||). It wouldn't cause any practical issues. But you wouldn't: it would be incredibly awkward. Likewise there should be a datatype for OR (sum types) as well as AND (structs/classes).
  - 5e92cb50239222b 5y ago
    This comment pretty much sums up the idea of Go — it's a perfect language for those who haven't looked into anything else that's been available for the past fifty years. If you think that sum types is an "advanced feature" that puts additional "cognitive overhead", it may be perfect for you. I think iota puts much more overhead and adds a need to have oversight where there should be none. If your idea of less cognitive overhead if doing compiler's work for it, well, good for you. There are some exceptions among talented and well-educated developers who seem like it, I know, but those seem to be exceptions.
    - philosopher1234 5y ago
      I know Haskell, rust and lisp, so no, I have looked into and used these technologies in earnest. Taking the cost of complication for granted is naive.
      - nicoburns 5y ago
        I question the notion that sum types add complication. I would suggest that if teaching complete beginners it would be just as easy to teach them sum types as it is to teach them product types (structs/classes). A bunch of languages have classes with inheritance. Now that's complicated! But sum types? I just don't buy it.

philosopher1234 5y ago

>Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings. I never said it was immune to criticism. I think most of the criticism is misguided. >- go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. I recognize that this does not perfectly map to your mental model, but why is this a major issue? I think major issues are those that cause practical problems. I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. It's a bit like saying "that tire isn't perfect because it can pop, so lets use a metal tire instead". Sure, you fix one issue, but you create others. >- repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. This is too vague to evaluate. There is a point at which repetition becomes a problem, and there is a point at which repetition is cheaper than having an abstraction. I don't think it can be evaluated in general. > cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. I agree on the factual level that it would be nice if cgo didn't have so much gc overhead. If this is meant to be evidence that go is a bad language, I would disagree.

nicoburns 5y ago
> I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. That's the thing about Sum Types. They're not really an advanced feature at all: they map to an extremely intuitive human concept: "or". They reduce cognitive load. That's the advantage of having them. In fact, I suspect that a lot of the reason that dynamic languages are considered simpler is because every variable is essentially one big sum type. Trying to represent "or data types" without sum types requires you to use interfaces which are a much more advanced language feature, and are very awkward for the use case of a finite number of known cases. You could have a perfectly functional language with only logical AND (&&) and logical negation (!) and no logical OR (||). It wouldn't cause any practical issues. But you wouldn't: it would be incredibly awkward. Likewise there should be a datatype for OR (sum types) as well as AND (structs/classes).
- 5e92cb50239222b 5y ago
  This comment pretty much sums up the idea of Go — it's a perfect language for those who haven't looked into anything else that's been available for the past fifty years. If you think that sum types is an "advanced feature" that puts additional "cognitive overhead", it may be perfect for you. I think iota puts much more overhead and adds a need to have oversight where there should be none. If your idea of less cognitive overhead if doing compiler's work for it, well, good for you. There are some exceptions among talented and well-educated developers who seem like it, I know, but those seem to be exceptions.
  - philosopher1234 5y ago
    I know Haskell, rust and lisp, so no, I have looked into and used these technologies in earnest. Taking the cost of complication for granted is naive.
    - nicoburns 5y ago
      I question the notion that sum types add complication. I would suggest that if teaching complete beginners it would be just as easy to teach them sum types as it is to teach them product types (structs/classes). A bunch of languages have classes with inheritance. Now that's complicated! But sum types? I just don't buy it.