4 ms·

> Do you know if that was the case when the decision to switch was made? It’s a good question. The timing is a bit confusing because the blog was apparently p

> Do you know if that was the case when the decision to switch was made? It’s a good question. The timing is a bit confusing because the blog was apparently published a bit after the fact, but I think I saw that they said they made the decision mid 2019. Go 1.12 seemed to address their latency issue, which was available as GA in Feb 2019. That’s based on some retroactive benchmarks on a set of old Go versions starting with 1.9 and targeting what they described as the problem and symptoms. Things seemed to line up, but I can’t be sure. I don’t know if Go 1.11 would have addressed their issue. (In general, Go GC tail latencies including for large heaps have improved a bunch since the last version they said they tried, which I think was Go 1.10). In any event, they saw a problem, and made a rationale decision for multiple rationale reasons.

aw1621107 6y ago
After digging a bit more, I found a comment from a Discord engineer that seems to clear things up [0]: > Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect. So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon. That being said, I have no idea if work to fix this issue was visible on Go's Github, so maybe the Discord engineers were unaware of said work or were unhappy with the pace of progress. Kind of miffed at myself for missing that comment, since it directly addresses my question, but at least it's answered now. [0]: https://old.reddit.com/r/programming/comments/eyuebc/why_discord_is_switching_from_go_to_rust/fgk56y4/ https://old.reddit.com/r/programming/comments/eyuebc/why_dis...
- typical182 6y ago
  Based on reading through various posts from Discord people after that blog was posted, my understanding was there was a material gap in time between the last time they tried in earnest to solve the latency issue with Go (with Go 1.10, as in your quote) vs. when they later did the re-write in Rust. It seems during that gap in time, the Go runtime team happened to solve their problem, which was GA in Go 1.12 in Feb 2019, which was prior to them doing the re-write in Rust, at least as far as I was able to follow. One imprecise quote on timing of the re-write: [1] This blog post perhaps is a bit "after the fact" we had made the switch over mid 2019 It's not crazy for someone to put aside a problem for a while, and then upon returning to the problem some time later decide to go a different route without re-exploring prior solutions, if that is what happened. All that said, I might have misunderstood the timing, and I'm trying to avoid going back over all the various forums they commented in to find a better quote on timing ;-) [1] https://news.ycombinator.com/item?id=22239707 https://news.ycombinator.com/item?id=22239707
  - aw1621107 6y ago
    I think it comes down to what "we had made the switch over mid 2019" is supposed to mean. I had interpreted that as being the time the Rust implementation was put into production and the Go implementation retired, with the rewrite starting some time before then, but I don't really have any strong evidence to support that interpretation (and that interpretation doesn't say anything about the actual point at which the rewrite decision was made). The situation you describe is certainly plausible, though. Shame that the chances of finding out what actually happened are quite low at this point.

aw1621107 6y ago

After digging a bit more, I found a comment from a Discord engineer that seems to clear things up [0]: > Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect. So I guess that means that there's a reasonable chance that they didn't see a fix on the horizon. That being said, I have no idea if work to fix this issue was visible on Go's Github, so maybe the Discord engineers were unaware of said work or were unhappy with the pace of progress. Kind of miffed at myself for missing that comment, since it directly addresses my question, but at least it's answered now. [0]: https://old.reddit.com/r/programming/comments/eyuebc/why_discord_is_switching_from_go_to_rust/fgk56y4/ https://old.reddit.com/r/programming/comments/eyuebc/why_dis...

typical182 6y ago
Based on reading through various posts from Discord people after that blog was posted, my understanding was there was a material gap in time between the last time they tried in earnest to solve the latency issue with Go (with Go 1.10, as in your quote) vs. when they later did the re-write in Rust. It seems during that gap in time, the Go runtime team happened to solve their problem, which was GA in Go 1.12 in Feb 2019, which was prior to them doing the re-write in Rust, at least as far as I was able to follow. One imprecise quote on timing of the re-write: [1] This blog post perhaps is a bit "after the fact" we had made the switch over mid 2019 It's not crazy for someone to put aside a problem for a while, and then upon returning to the problem some time later decide to go a different route without re-exploring prior solutions, if that is what happened. All that said, I might have misunderstood the timing, and I'm trying to avoid going back over all the various forums they commented in to find a better quote on timing ;-) [1] https://news.ycombinator.com/item?id=22239707 https://news.ycombinator.com/item?id=22239707
- aw1621107 6y ago
  I think it comes down to what "we had made the switch over mid 2019" is supposed to mean. I had interpreted that as being the time the Rust implementation was put into production and the Go implementation retired, with the rewrite starting some time before then, but I don't really have any strong evidence to support that interpretation (and that interpretation doesn't say anything about the actual point at which the rewrite decision was made). The situation you describe is certainly plausible, though. Shame that the chances of finding out what actually happened are quite low at this point.