Comment by phreeza
20 hours ago
The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.
That is because the Cider team did an amazing job of managing it, and spent tons of time going bug report by bug report to find and fix the blockers stopping people from preferring Cider-V over Cider, instead of the typical Google deprecation approach of "monkey knife fight"
I came from storage, so the monkey knife fight there was between PARMs. Very entertaining. For storage engineering could basically say "Well, figure it out, because if you don't find XX capacity, Google will stop working. Like, all of it."
haha, that's a great way to put it! And I get the overall gist of it, but why monkeys? :)
Because it's international waters
2 replies →
code monkeys
1 reply →
fucking lol, that is how it usually goes with deprecation.
Initially I had thought so too. But later I realized that it’s quite easy to do so when you force-deprecate the old product. There was no real choice, the old IDE simply stopped working after a certain cutoff date. Adoption metrics felt forced and pushed, but were presented as if users were actively and willingly choosing the newer IDE.
I feel like core dev team learned a lot about actually enabling a web based ide for line 100k engineers across the globe for a gazillion line mono repo. ciderv is really just a skin for the amazing infra. Which is also why I think there was less resistance to the change
It would be nice if they extended their external services the same behavior…