5 ms·

This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics

This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal https://go.dev/blog/generics-proposal Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be useful only for certain very specific use cases (e.g. maybe proto deserialization, where you hang a million tiny objects off a single GC’ed one and can deterministically bound lifetimes).

p-e-w 4y ago
Yes, generics (and many other proposals, like improved error handling) have been discussed for a long time. But for an almost equally long time, nothing happened. Go was stagnating for years until very recently, and the consensus seemed to be that the well-known deficiencies of the language were simply "what Go is", and anyone who doesn't like it just doesn't get it. Now suddenly we have generics, and a bunch of other pretty significant changes, but no clear vision of where Go is going. Will "Go 2.0" with breaking changes happen or not? Will error handling be overhauled or not? Will radical changes proposed by core developers, like arbitrary-precision integers, be implemented? I'm not sure if there's really a lack of vision or just a lack of proper communication, but from the outside it's very confusing.
- mseepgood 4y ago
  > Will "Go 2.0" with breaking changes happen or not? It has been made clear that this will not happen. The changes of the last years ARE the "Go 2" initiative, but there won't be a major version bump.
- amscanne 4y ago
  It moves slowly for sure, but there are answers to your questions in plain sight. This might be a good place to start: https://go.dev/blog/toward-go2 https://go.dev/blog/toward-go2 (published five years ago, on the 10th anniversary Go).
- klodolph 4y ago
  As far as I can tell, the consensus for generics was "it will happen, but we really want to get this right, and it's taking time." I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously. > Will error handling be overhauled or not? Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people are slowly grinding through these proposals until one is found with the right balance to it. I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here: https://github.com/golang/proposal/blob/master/design/go2draft-error-handling.md https://github.com/golang/proposal/blob/master/design/go2dra... Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#. I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.
- downvotetruth 4y ago
  The near meaningless vision seems to be to see what sticks without using types in the lexer & parser https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2vrXxBQAJ https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2.... Take array declaration being prefixed to the type name to prevent ambiguity with int []a, b; vs int a[], b; & then Ian & the rest doubling the work back & reusing postfix [] for generics resulted in making inferable type identifiers turn into required infix operators & that reversed the position of array declaration that <go>es against the intuitive idea that what is independent comes first & to construct an array/pointer has a dependence on its elemental type that is a common pattern to programming languages with arrays. Along with the arbitrary predeclared identifier constraint requirement, using/burning one of the limited matching pairs was a complete waste as generics do not involve changing precedence - there is only a "(of) type (T)" operator - to accommodate nesting - D's "!" operator parses fine L to R w/o look ahead. The implementation taking years from some who have been programming for decades & resulting in a complete mess up is a grand ole time(r) fiasco.
  - philosopher1234 4y ago
    I can barely understand what you're saying.
    - downvotetruth 4y ago
      In entirety or a specific part?
      - philosopher1234 4y ago
        i Think I couldn’t quite get your specific criticism and the supporting reasons. I had a feeling of strain while I was trying to parse what you wrote
        downvotetruth 4y ago
        Specific criticism: the lack of direction or misdirection (bad goals) leads to changing (or even overriding previous decisions as in the example case of the use of [] postfix (after the type) placement) reasoning of how & why language is implemented in a certain way. A complex history is not certainly not limited to Go, but a more complicated process makes reading & writing the code an exercise in trying to understand & remember the relevant language history.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

p-e-w 4y ago

Yes, generics (and many other proposals, like improved error handling) have been discussed for a long time. But for an almost equally long time, nothing happened. Go was stagnating for years until very recently, and the consensus seemed to be that the well-known deficiencies of the language were simply "what Go is", and anyone who doesn't like it just doesn't get it. Now suddenly we have generics, and a bunch of other pretty significant changes, but no clear vision of where Go is going. Will "Go 2.0" with breaking changes happen or not? Will error handling be overhauled or not? Will radical changes proposed by core developers, like arbitrary-precision integers, be implemented? I'm not sure if there's really a lack of vision or just a lack of proper communication, but from the outside it's very confusing.

mseepgood 4y ago
> Will "Go 2.0" with breaking changes happen or not? It has been made clear that this will not happen. The changes of the last years ARE the "Go 2" initiative, but there won't be a major version bump.
amscanne 4y ago
It moves slowly for sure, but there are answers to your questions in plain sight. This might be a good place to start: https://go.dev/blog/toward-go2 https://go.dev/blog/toward-go2 (published five years ago, on the 10th anniversary Go).
klodolph 4y ago
As far as I can tell, the consensus for generics was "it will happen, but we really want to get this right, and it's taking time." I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously. > Will error handling be overhauled or not? Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people are slowly grinding through these proposals until one is found with the right balance to it. I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here: https://github.com/golang/proposal/blob/master/design/go2draft-error-handling.md https://github.com/golang/proposal/blob/master/design/go2dra... Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#. I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.
downvotetruth 4y ago
The near meaningless vision seems to be to see what sticks without using types in the lexer & parser https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2vrXxBQAJ https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2.... Take array declaration being prefixed to the type name to prevent ambiguity with int []a, b; vs int a[], b; & then Ian & the rest doubling the work back & reusing postfix [] for generics resulted in making inferable type identifiers turn into required infix operators & that reversed the position of array declaration that <go>es against the intuitive idea that what is independent comes first & to construct an array/pointer has a dependence on its elemental type that is a common pattern to programming languages with arrays. Along with the arbitrary predeclared identifier constraint requirement, using/burning one of the limited matching pairs was a complete waste as generics do not involve changing precedence - there is only a "(of) type (T)" operator - to accommodate nesting - D's "!" operator parses fine L to R w/o look ahead. The implementation taking years from some who have been programming for decades & resulting in a complete mess up is a grand ole time(r) fiasco.
- philosopher1234 4y ago
  I can barely understand what you're saying.
  - downvotetruth 4y ago
    In entirety or a specific part?
    - philosopher1234 4y ago
      i Think I couldn’t quite get your specific criticism and the supporting reasons. I had a feeling of strain while I was trying to parse what you wrote
      - downvotetruth 4y ago
        Specific criticism: the lack of direction or misdirection (bad goals) leads to changing (or even overriding previous decisions as in the example case of the use of [] postfix (after the type) placement) reasoning of how & why language is implemented in a certain way. A complex history is not certainly not limited to Go, but a more complicated process makes reading & writing the code an exercise in trying to understand & remember the relevant language history.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]