3 ms·
They actually would have mitigated it by upgrading their Go version, because the latest release at the time had a fix in the runtime that would have basically s
by mountainriver 5y ago
They actually would have mitigated it by upgrading their Go version, because the latest release at the time had a fix in the runtime that would have basically solved this.
Turns out no one on the team actually looked into issues in the Go repo to see if it was being addressed. Looks like they just wanted to write Rust, which is fine Rust is cool, but let’s not deceive ourselves.
- steveklabnik 5y agoThat is not what happened, they did not publish the blog post immediately after the transition, and those changes to the GC did not happen until after the port happened. Some people made assumptions about timeline that were incorrect, and then repeated. The discussion at the time on Reddit [1] mentions this. The general discussion as well talked about if the improvements, which were big in many cases, would have even improved this particular case. We’ll never truly know. That said it is important to recognize that Go’s GC has received significant upgrades over the years, and remember that what’s true in the past may not be true today. 1: https://www.reddit.com/r/programming/comments/eyuebc/why_discord_is_switching_from_go_to_rust/fgjsjxd/?context=3 https://www.reddit.com/r/programming/comments/eyuebc/why_dis...
- mountainriver 5y agoThe point is that they could have found the issue and seen that it was about to be released. That would be good engineering, bad engineering is when you don't find the root cause of your problem and see if its being worked on
- steveklabnik 5y agoGood engineering is when you solve the problems you have. Sometimes there are multiple ways to solve a problem. Just because they did not choose the solution (which again, we're only speculating would actually solve the issue here, we don't have proof of that) you prefer does not make it poor engineering.