5 ms·

Generics Update: "We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of t

by mfrw 6y ago

Generics Update: "We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas."

Rochus 6y ago
By the end of the year 2021!
- mfrw 6y ago
  Yes... Updated my comment. It was misleading :(
qz2 6y ago
This is what I want to see: taking time to make large engineering decisions conservatively. A lot of vendors, the first thing you hear is it being dumped on you instantly followed by the realisation that it was designed by a closed team in isolation with no user feedback involved and subsequently it turned out to be crap or a complete impedance mismatch for the real world.
dgb23 6y ago
This carefulness and emphasis on stability and simplicity is one of the reasons I'm attracted to the language. Currently I personally don't really see a use-case that isn't covered by my tool-belt otherwise but every time I peek into a Go repository or read about Go I get a bit jealous.
- philosopher1234 6y ago
  I don't think Go does anything other languages cant do, it just does things better. It makes things simple. In some ways its like the Mac OS of programming languages. In certain ways its restricting, but 99% of the time its going to make your life much easier.
alquemist 6y ago
Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :) https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling https://github.com/golang/go/labels/error-handling
- jhoechtl 6y ago
  No, error handling is not the best. The lake of generics seems to get addressed with lots of pondering which is a good thing. But error handling is just awkward. I do not mean the retval, err := funccall(a,b) syntax but rather the absence of a standardized way to get stack traces.
  - alquemist 6y ago
    It's really a joke :) Fundamentally, the Go team made the correct choice between explicit and implicit error handling. Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. For a good overview of the issue: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf....
    - mseepgood 6y ago
      > Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. The Go team tried, but the community shot it down. Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-...
      - Groxx 6y ago
        As one who didn't like either proposal: I'm thrilled that they were shot down. Both worked fine (great, even) in simple cases, but fell apart when needing to add context / wrapping to multiple possible errors. Simple cases are already simple. It's the harder spots that need help.
valyala 6y ago
I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers. I wrote a ton of various code in Go [1] over the last 10 years and had never experienced the need in generics. The last my project in Go is VictoriaMetrics [2] - fast and cost-effective open source time series database and monitoring solution. Before Go I was writing some code in C++ and was constantly struggling with C++ templates in stl and boost libraries. This was absolute nightmare from debugging PoV. [1] https://github.com/valyala/ https://github.com/valyala/ [2] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/
- throw_m239339 6y ago
  > I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers. Well you don't have to use them and you won't have to use any of the libraries that use them. Just like C++ templates, some C++ shops forbid their use. But that's your problem, don't make everybody else suffer from what is considered a burden and a flaw in that language. People want compile time type safety, not having to resort to runtime reflection, which Go std lib itself does . There is nothing unfathomable about that thought process. Go has a poor type system at compile time while being way too permissive at runtime.
  - valyala 6y ago
    It would be great if you could provide practical examples where generics could significantly improve Go code.
    - throw_m239339 6y ago
      > It would be great if you could provide practical examples where generics could significantly improve Go code. It would be great if you stopped patronizing people who just provided you an explanation you just don't want to hear.

by mfrw 6y ago

Generics Update: "We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas."

Rochus 6y ago

By the end of the year 2021!

mfrw 6y ago
Yes... Updated my comment. It was misleading :(

qz2 6y ago

This is what I want to see: taking time to make large engineering decisions conservatively. A lot of vendors, the first thing you hear is it being dumped on you instantly followed by the realisation that it was designed by a closed team in isolation with no user feedback involved and subsequently it turned out to be crap or a complete impedance mismatch for the real world.

dgb23 6y ago

This carefulness and emphasis on stability and simplicity is one of the reasons I'm attracted to the language. Currently I personally don't really see a use-case that isn't covered by my tool-belt otherwise but every time I peek into a Go repository or read about Go I get a bit jealous.

philosopher1234 6y ago
I don't think Go does anything other languages cant do, it just does things better. It makes things simple. In some ways its like the Mac OS of programming languages. In certain ways its restricting, but 99% of the time its going to make your life much easier.

alquemist 6y ago

Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :) https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling https://github.com/golang/go/labels/error-handling

jhoechtl 6y ago
No, error handling is not the best. The lake of generics seems to get addressed with lots of pondering which is a good thing. But error handling is just awkward. I do not mean the retval, err := funccall(a,b) syntax but rather the absence of a standardized way to get stack traces.
- alquemist 6y ago
  It's really a joke :) Fundamentally, the Go team made the correct choice between explicit and implicit error handling. Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. For a good overview of the issue: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf....
  - mseepgood 6y ago
    > Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. The Go team tried, but the community shot it down. Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-...
    - Groxx 6y ago
      As one who didn't like either proposal: I'm thrilled that they were shot down. Both worked fine (great, even) in simple cases, but fell apart when needing to add context / wrapping to multiple possible errors. Simple cases are already simple. It's the harder spots that need help.

valyala 6y ago

I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers. I wrote a ton of various code in Go [1] over the last 10 years and had never experienced the need in generics. The last my project in Go is VictoriaMetrics [2] - fast and cost-effective open source time series database and monitoring solution. Before Go I was writing some code in C++ and was constantly struggling with C++ templates in stl and boost libraries. This was absolute nightmare from debugging PoV. [1] https://github.com/valyala/ https://github.com/valyala/ [2] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/

throw_m239339 6y ago
> I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers. Well you don't have to use them and you won't have to use any of the libraries that use them. Just like C++ templates, some C++ shops forbid their use. But that's your problem, don't make everybody else suffer from what is considered a burden and a flaw in that language. People want compile time type safety, not having to resort to runtime reflection, which Go std lib itself does . There is nothing unfathomable about that thought process. Go has a poor type system at compile time while being way too permissive at runtime.
- valyala 6y ago
  It would be great if you could provide practical examples where generics could significantly improve Go code.
  - throw_m239339 6y ago
    > It would be great if you could provide practical examples where generics could significantly improve Go code. It would be great if you stopped patronizing people who just provided you an explanation you just don't want to hear.