3 ms·
I'm a little surprised it didn't seem that they considered a GC-less language like Rust. If your latency requirements are that strict & you're already consideri
by wfleming 10y ago
I'm a little surprised it didn't seem that they considered a GC-less language like Rust. If your latency requirements are that strict & you're already considering a total rewrite, I would personally have been looking into a solution that would avoid GC entirely.
- jakevn 10y agoRust has a semantic overhead and isn't quite as mature as Go. Their requirements don't necessitate a lack of GC pause.
- echelon 10y agoI disagree with your first point, at least from a personal perspective. I find Rust more expressive than Go, and slightly more productive. You're right about maturity though. Hopefully the Rust library ecosystem continues to make strides.
- wfleming 10y agoI agree: I personally find Rust more expressive than Go. I don't think it has any more "semantic overhead" than any other language with a highly featured type system. To tie it back to the article a bit, Rust also seems like a relatively natural choice for a team considering switching from Haskell if their reason for switching is performance. The niche Rust fills for me personally is that it has a very robust type system (putting it in a similar camp as Haskell) with an explicit focus on fast, performant code (which Haskell does not have).
- willsewell 10y agoThis is something we get asked a lot. The short version is that we had other requirements as well as a low latency. I described some of these here: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_practice_pusher/daowdag/ https://www.reddit.com/r/programming/comments/5fyhjb/golangs...