4 ms·

With all of the controversy around generics, this is one area where Go is really hurt. The language provides the building blocks for concurrency, but they stil

by rwj 7y ago

With all of the controversy around generics, this is one area where Go is really hurt. The language provides the building blocks for concurrency, but they still need to be assembled into something larger. There are examples of good concurrency patterns, but the language doesn't provide the tools to reuse them. Everyone is left to implement them over and over.

fjp 7y ago
> Everyone is left to implement them over and over. This is a good summary the state of developing anything Golang
zxcmx 7y ago
Oh jeez I’m reminded of ACE and TAO and all that stuff in C++, which in theory was a great idea and should have resulted in easy, efficient servers but always seemed to footgun any projects I saw that used it. Part of the problem was heavy use of inheritance and templates at a time of peak design pattern mania, part was just the nature of C++ and finally a dash of leaky abstractions because “low level async is hard”. I guess based on experiences with ACE/TAO in C++, Python twisted and a couple of other frameworks that tried to “bolt on” deep server stuff: I would take the language primitives not sucking over generics any day of the week.
- nicoburns 7y ago
  > I would take the language primitives not sucking over generics any day of the week. It's not an either-or situation though: Rust has generics (and is a bit lower level), which has allowed go-style channels to be implemented as a library: https://docs.rs/crossbeam-channel/0.3.8/crossbeam_channel/ https://docs.rs/crossbeam-channel/0.3.8/crossbeam_channel/ https://twitter.com/stjepang/status/1006202765499125760 https://twitter.com/stjepang/status/1006202765499125760
  - zxcmx 7y ago
    Yeah I think this is fair and also, maybe go is close enough to right that you could paper your way to something not awful without too much cognitive overhead.

4 ms·

With all of the controversy around generics, this is one area where Go is really hurt. The language provides the building blocks for concurrency, but they stil

by rwj 7y ago

fjp 7y ago
> Everyone is left to implement them over and over. This is a good summary the state of developing anything Golang
zxcmx 7y ago
Oh jeez I’m reminded of ACE and TAO and all that stuff in C++, which in theory was a great idea and should have resulted in easy, efficient servers but always seemed to footgun any projects I saw that used it. Part of the problem was heavy use of inheritance and templates at a time of peak design pattern mania, part was just the nature of C++ and finally a dash of leaky abstractions because “low level async is hard”. I guess based on experiences with ACE/TAO in C++, Python twisted and a couple of other frameworks that tried to “bolt on” deep server stuff: I would take the language primitives not sucking over generics any day of the week.
- nicoburns 7y ago
  > I would take the language primitives not sucking over generics any day of the week. It's not an either-or situation though: Rust has generics (and is a bit lower level), which has allowed go-style channels to be implemented as a library: https://docs.rs/crossbeam-channel/0.3.8/crossbeam_channel/ https://docs.rs/crossbeam-channel/0.3.8/crossbeam_channel/ https://twitter.com/stjepang/status/1006202765499125760 https://twitter.com/stjepang/status/1006202765499125760
  - zxcmx 7y ago
    Yeah I think this is fair and also, maybe go is close enough to right that you could paper your way to something not awful without too much cognitive overhead.