2 ms·

etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go. goBGP

by fl0ki 2mo ago

etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go. goBGP is arguably even worse. I don't have a third place in mind that's even worth mentioning relative to these two.

alfons_foobar 2mo ago
just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
- iscoelho 2mo ago
  Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/ https://elegantnetwork.github.io/posts/comparing-open-source...
  - preisschild 2mo ago
    Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
    - tsss 2mo ago
      No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
    - pjmlp 2mo ago
      Nope, it is a matter of skill as well. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- fl0ki 2mo ago
  Just look at the code. Anywhere you like. There's nothing I can say that will be a substitute for seeing it yourself. I've had to use it as a library sometimes, and it's also really poorly designed as a library. There's no consistent principle for what is exported and what remains internal, so almost anything non-trivial you do may require you to copy-paste parts of the library code because something happened to not be exported. So you must think, okay sure, but in return for that you get a minimal and stable API. Nope! It also has some of the most API churn of any Go module, already up to /v4 and that's only counting the semver-major breakage they bothered to acknowledge, not the many semver papercuts along the way.

by fl0ki 2mo ago

alfons_foobar 2mo ago

just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)

iscoelho 2mo ago
Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/ https://elegantnetwork.github.io/posts/comparing-open-source...
- preisschild 2mo ago
  Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
  - tsss 2mo ago
    No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
  - pjmlp 2mo ago
    Nope, it is a matter of skill as well. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
fl0ki 2mo ago
Just look at the code. Anywhere you like. There's nothing I can say that will be a substitute for seeing it yourself. I've had to use it as a library sometimes, and it's also really poorly designed as a library. There's no consistent principle for what is exported and what remains internal, so almost anything non-trivial you do may require you to copy-paste parts of the library code because something happened to not be exported. So you must think, okay sure, but in return for that you get a minimal and stable API. Nope! It also has some of the most API churn of any Go module, already up to /v4 and that's only counting the semver-major breakage they bothered to acknowledge, not the many semver papercuts along the way.