I am very opinionated, but I really don't like Cider V. I have been using neovim at Google since 2017 and it's been great.
same! how do you deal with cloudtop latency though? sometimes my neovim is very slow and laggy because of the remote connection / network file system
A History of IDEs at Google
251–260 of 333 posts
Re: A History of IDEs at Google
#252The 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.
Re: A History of IDEs at Google
#253Re: A History of IDEs at Google
#254Earlier quoted context omitted.
You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.
Maybe, but I feel like an article I’ve read many, many times is “we hired one or more Xooglers for our startup and this turned out to be a catastrophe because they insisted on trying to bring blaze/bazel with them and it nearly destroyed the company.” It’s always bazel specifically in these articles, never any of the other internal Google stuff like Spanner.
Re: A History of IDEs at Google
#255Earlier quoted context omitted.
Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.
You don't really need it anymore - CitC let you do views (mapping just part of the monorepo into your filesystem via FUSE) since about 2013, and then that functionality just got built into Piper. When I returned in 2020 you'd have a file at the top of your source tree that included all the relevant file mappings as well as any Blaze flags needed to build the project, and you could just point your IDE at that and it'd…
Re: A History of IDEs at Google
#256Earlier quoted context omitted.
Because it's international waters
This is a very confusing but enlightened response. Will have to ponder on its true wisdom:)
Re: A History of IDEs at Google
#257It was long series of incredible and impressive feats of truly singular engineering talent continuously wasted solving problems of our own making that shouldn’t have existed in the first place.
Re: A History of IDEs at Google
#258I must say the debugging experience at Meta has been spectacular.
I liked the way CitC exposed Snapshots and easy to make projects.
(+ A bunch of other dozen opinions)
I was also at Amazon circa 2011 and it's funny to think about the experience back then. I remember i toiled to get Eclipse CDT to work whereas everyone else worked without any language intellisense. The work paid off though and I was able to drop P95 of the real time service I was on by 50% with the aided code intelligence + hooking it into callgrind.
Re: A History of IDEs at Google
#259I was surprised to read that Chromebook use at Google was common for engineers. Even if developing remotely I had assumed they'd opt for the most powerful machine possible.
Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.) You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on…
Re: A History of IDEs at Google
#260Earlier quoted context omitted.
Cider (and p4/g4c etc) was amazing when I left back in 2020, I loved it so much, and truly miss it. I rejoined Google last year, and they'd replaced it with a VSCode clone that truly was just a glorified text editor and most were all-in on mercurial as a piper/citc shim -- I was only there for 5 months before I decided not to stay, and I never managed to get Go type definition hints working.
Google has also been systematically destaffing various language infra teams. https://www.linkedin.com/pulse/google-fires-entire-python-te... https://www.airs.com/blog/archives/670 https://en.wikipedia.org/wiki/Google_Kythe etc