4 ms·

"programmers have spoken, and they"...'ve done quite a lot of work to get the benefits of generics without language support. You can pretty much look at any lar

by jdub 6y ago

"programmers have spoken, and they"...'ve done quite a lot of work to get the benefits of generics without language support. You can pretty much look at any large Go project (famously Kubernetes) and see a workaround of some shape or form.

smarterclayton 6y ago
Kubernetes has lots of workarounds - I’m not sure generics are the ones I’ve worried about the most. If I had to write a list of “tools I would have preferred to have”: 1. Perfect serialization libraries - Serde is the gold standard here, and IIRC the macro system from Rust is as important a part of it as the traits part. 2. Mutability of types in shared caches - to build efficient controller patterns you need fast and efficient caches - an immutable type that protects against mutation would have saved a lot of ugly mutation testing code 3. Client library definitions shared across types - we could have reduced a fair amount of boilerplate with generics, although most bugs are in the serialization part these days as types evolve But most of these are dwarfed by the need to scale reviewer time across hundreds of people submitting PRs that change fundamentals of the code. The simplicity of Go and ability to review stupid, obvious, absolutely critical code is the reason why I love it. Having a strong way to reduce cleverness has been a godsend. It doesn’t mean cleverness is bad, or I don’t want more tools in Go. But I appreciate that aspect of Go in a way that others may not. Edit: I have been watching kube-rs mature, but to get the same level of scale and performance we’d have to reproduce the shared index informers and that’s a lot of drudge work to get right. That’s one place where someone motivated could really help Rust become a first place way to extend Kubernetes, which would be exciting.
- entha_saava 6y ago
  Hacker News law: In every thread about Go someone will bring up rust. Don't mind.
  - uluyol 6y ago
    The comment you are replying to was written by one of Red Hat's lead kubernetes developers (https://github.com/kubernetes/kubernetes/graphs/contributors https://github.com/kubernetes/kubernetes/graphs/contributors).
saturn_vk 6y ago
While k8s's code is atrocious, I wonder if that isn't due to its legacy translation from Java (iirc, it was written in it initially)
- smarterclayton 6y ago
  Kubernetes had a non-public prototype in Java. None of the code in the main tree even resembles the code from that prototype (I was one of the first non-googlers to contribute). It’s just ugly because that’s how it evolved after a community formed and that’s what real evolved software looks like. :)

by jdub 6y ago

smarterclayton 6y ago

Kubernetes has lots of workarounds - I’m not sure generics are the ones I’ve worried about the most. If I had to write a list of “tools I would have preferred to have”: 1. Perfect serialization libraries - Serde is the gold standard here, and IIRC the macro system from Rust is as important a part of it as the traits part. 2. Mutability of types in shared caches - to build efficient controller patterns you need fast and efficient caches - an immutable type that protects against mutation would have saved a lot of ugly mutation testing code 3. Client library definitions shared across types - we could have reduced a fair amount of boilerplate with generics, although most bugs are in the serialization part these days as types evolve But most of these are dwarfed by the need to scale reviewer time across hundreds of people submitting PRs that change fundamentals of the code. The simplicity of Go and ability to review stupid, obvious, absolutely critical code is the reason why I love it. Having a strong way to reduce cleverness has been a godsend. It doesn’t mean cleverness is bad, or I don’t want more tools in Go. But I appreciate that aspect of Go in a way that others may not. Edit: I have been watching kube-rs mature, but to get the same level of scale and performance we’d have to reproduce the shared index informers and that’s a lot of drudge work to get right. That’s one place where someone motivated could really help Rust become a first place way to extend Kubernetes, which would be exciting.

entha_saava 6y ago
Hacker News law: In every thread about Go someone will bring up rust. Don't mind.
- uluyol 6y ago
  The comment you are replying to was written by one of Red Hat's lead kubernetes developers (https://github.com/kubernetes/kubernetes/graphs/contributors https://github.com/kubernetes/kubernetes/graphs/contributors).

saturn_vk 6y ago

While k8s's code is atrocious, I wonder if that isn't due to its legacy translation from Java (iirc, it was written in it initially)

smarterclayton 6y ago
Kubernetes had a non-public prototype in Java. None of the code in the main tree even resembles the code from that prototype (I was one of the first non-googlers to contribute). It’s just ugly because that’s how it evolved after a community formed and that’s what real evolved software looks like. :)