5 ms·

Go is my main language but it keeps disappointing me in it's lack of implementation tuning detail. Generics are just a code generator that, given it's poor perf

Go is my main language but it keeps disappointing me in it's lack of implementation tuning detail. Generics are just a code generator that, given it's poor performance for things like functional programming, makes it surprisingly of little use. Go is a kitchen full of dull knives. It is good for layers of communication where you call other microservices to perform the heavy lifting, but not much else.

Thaxll 4y ago
Go is on part with Java and C# and sometime as fast as C++, it's plenty fast for most usecases.
- deeptote 4y ago
  Again, just one engineer's opinion, but that's because most use cases for engineers are CRUD. If you don't have a CRUD problem, which is probably less than 10% of modern software engineering, Go falls on it's face.
  - Thaxll 4y ago
    Uber, Dropbox etc... rely heavily on Go and have much more complicated use case that your CRUD hello world.
  - throwaway894345 4y ago
    You have it exactly backwards. Go is a particularly poor language for CRUD use cases (CRUD doesn’t care much about performance but it is very generic). Go shines for most non-CRUD applications.
fsdjkflsjfsoij 4y ago
> given it's poor performance for things like functional programming, makes it surprisingly of little use. In most cases it doesn't have "poor" performance and if you're going for optimal performance you are almost never going to be using generic data structures anyways because there's almost always type specific optimizations that can be done. The intended use case is, and always has been, decently performing type safe data structures and Go generics are sufficient in most cases for that. Go is never going to be a functional programming language.
- Gadiguibou 4y ago
  Monomorphization is one of the ways generics are implemented in other languages and it definitely allows for type-specific optimizations. I imagine there's a rationale for not implementing generics this way, like keeping binaries small, but it seems like a weird tradeoff considering it increases overall memory consumption and decreases performance quite a lot...
  - cube2222 4y ago
    If I understood the implementation correctly, as long as you use value types instead of pointer/interface types for your generic type parameters, you'll basically get monomorphization.
    - throwaway894345 4y ago
      I don’t think this is true. If your value types use methods in the generic code, I think you get dictionaries regardless (maybe Go doesn’t emit dictionaries if there is exactly one implementation for a gcshape?). Value types just make it more likely that you’ll have distinct gcshapes, but I’m pretty sure you’ll still get dictionaries. The only way you don’t is if you have a pure container (no calling methods on type parameters). That said, I believe there’s an undocumented flag to force full monomorphization, but it’s probably not stable.
  - fsdjkflsjfsoij 4y ago
    If it was up to me I would have gone with full monomorphization because I don't care about binary size or compilation time quite as much as the current Go developers. However, the decrease in performance of the current implementation is being vastly overstated because people read a single article. It's not going to be even close to a bottleneck in all but the most extreme performance demanding applications and those applications probably shouldn't be using a garbage collected language to begin with.
  - mseepgood 4y ago
    There are two possible extremes for the implementation of generics: full monomorphization on one side, and dictionaries on the other side. Both have serious drawbacks: monomorphization is faster, but produces bloat, and dictionaries are slower but don't produce bloat. Go chose to combine the two for a middle ground. It's a bit more complicated to implement than just monomorphization or just dictionaries, but it provides a nice balance.
deleted 4y ago
[deleted]

Thaxll 4y ago

Go is on part with Java and C# and sometime as fast as C++, it's plenty fast for most usecases.

deeptote 4y ago
Again, just one engineer's opinion, but that's because most use cases for engineers are CRUD. If you don't have a CRUD problem, which is probably less than 10% of modern software engineering, Go falls on it's face.
- Thaxll 4y ago
  Uber, Dropbox etc... rely heavily on Go and have much more complicated use case that your CRUD hello world.
- throwaway894345 4y ago
  You have it exactly backwards. Go is a particularly poor language for CRUD use cases (CRUD doesn’t care much about performance but it is very generic). Go shines for most non-CRUD applications.

fsdjkflsjfsoij 4y ago

> given it's poor performance for things like functional programming, makes it surprisingly of little use. In most cases it doesn't have "poor" performance and if you're going for optimal performance you are almost never going to be using generic data structures anyways because there's almost always type specific optimizations that can be done. The intended use case is, and always has been, decently performing type safe data structures and Go generics are sufficient in most cases for that. Go is never going to be a functional programming language.

Gadiguibou 4y ago
Monomorphization is one of the ways generics are implemented in other languages and it definitely allows for type-specific optimizations. I imagine there's a rationale for not implementing generics this way, like keeping binaries small, but it seems like a weird tradeoff considering it increases overall memory consumption and decreases performance quite a lot...
- cube2222 4y ago
  If I understood the implementation correctly, as long as you use value types instead of pointer/interface types for your generic type parameters, you'll basically get monomorphization.
  - throwaway894345 4y ago
    I don’t think this is true. If your value types use methods in the generic code, I think you get dictionaries regardless (maybe Go doesn’t emit dictionaries if there is exactly one implementation for a gcshape?). Value types just make it more likely that you’ll have distinct gcshapes, but I’m pretty sure you’ll still get dictionaries. The only way you don’t is if you have a pure container (no calling methods on type parameters). That said, I believe there’s an undocumented flag to force full monomorphization, but it’s probably not stable.
- fsdjkflsjfsoij 4y ago
  If it was up to me I would have gone with full monomorphization because I don't care about binary size or compilation time quite as much as the current Go developers. However, the decrease in performance of the current implementation is being vastly overstated because people read a single article. It's not going to be even close to a bottleneck in all but the most extreme performance demanding applications and those applications probably shouldn't be using a garbage collected language to begin with.
- mseepgood 4y ago
  There are two possible extremes for the implementation of generics: full monomorphization on one side, and dictionaries on the other side. Both have serious drawbacks: monomorphization is faster, but produces bloat, and dictionaries are slower but don't produce bloat. Go chose to combine the two for a middle ground. It's a bit more complicated to implement than just monomorphization or just dictionaries, but it provides a nice balance.

deleted 4y ago

[deleted]