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
That is not quite the right word. For Python, the headcount was moved from the Bay Area (the most expensive place in the world to hire software engineers) to Munich (the most expensive place in Germany to hire SWEs.), for cost saving reasons.
While most IDEs converged to a unified web solution, pockets of devoted users continued to volunteer improvements/integrations for their preferred editors.
During my time there, a relatively small, but fairly active Emacs group, would often share tips, tricks, and elisp integrating the latest internal tools.
"the advantages of having a single, extensible platform become even more obvious" -- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique! The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.
I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…
(current Googler)
For what it's worth we still use Android Studio as well internally, it is better and faster for doing specific UI stuff because of the tooling and visualization.
On the flip side the Google monorepo is a pretty cool thing and you get used to switching between projects and languages within the same commit chain pretty often. This is part of the reason the cloud IDE is so popular because it's one common editor across many languages compared to language specialized IDEs like Android Studio.
Regarding networking, it's not a big issue day to day. The infra team does a really great job building tools that do efficient caching and integrate well over the network.
Probably not in the way that you might mean it, but for me (Xoogler, 2010 - 2023) internalizing bazel means: "Hey, where's your tool's code in $MONOREPO?" " " Cool: g4d my-citc-client # moral equivalent to `cd ~/repos/stuff` blaze run path/to/stuff:target ... and you get a running version of whatever $stuff is, immediately built from head, quickly - no matter the set of dependencies, or which language they were built…
Probably it's just down to a different understanding of the word "internalize". I know how to _use_ bazel effectively to do my work. I'm comfortable with its well-designed surface but whenever I've tried to understand the inner machinery I've given up - especially when presented with a bunch of custom skylark rules code. It's like an anti-git in some regards - the surface of git (the CLI) is an abomination in many wa…
I've personally driven adoption of Bazel across two teams in our company over the last two years (we have an extremely fragmented set of repos that touches everything from hardware, to end-to-end simulation, to cloud software, to CDK stacks that deploy the software). There are still some aspects (ha) that confuse me like transitions, exec groups and constraints, but most of the time it's all about building a graph of actions (command executions) by executing code, and hooking up external dependencies into the graph inputs. Mind telling what confuses you in particular? Maybe I can be of help somehow.
> developers would never program in a web-based IDE That's why 80% of developers use a web based VS Code/Cursor
Is that right? They use the version running in a browser?
I think they just meant that an Electron app is still at least (half) browser-based, just you're shipping the user a particular browser alongside the app code.
I too have been following your talk on Tritium, so that for the past few years as I have been hand-crafting a new open document engine for the web I have had your use cases in mind as ones that I might be able to solve if things went very well. That engine is shipping today and I think things have gone quite well, so I would absolutely love to talk to you about how we could reshape the landscape if we put our heads together. I feel certain that what I've built could be made into a groundbreaking product in the law world, if only I knew anything about law (not from TV)!
I 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.
For most of my time here I used exclusively Chrome OS, and switched to it for personal use as well. My daily driver for years was a bright red Samsung Chromebook Galaxy (the first gen with the actual metal case). Literally none of my work is local, and it could run Secure Shell, Cider-V, and Docs as installed PWAs with their own taskbar items, etc. It was glorious. When it finally failed in the most annoying way poss…
Ive had that issue with touchscreens before and was able to disable the driver for it. Linux so not sure if possible or how on a chromebook but an option.
One important piece of context that might make all these stories less confusing for non-googlers: Code references are less important inside Google editors, because we have a code viewer tool inside the web browser. Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually t…
To make this more concrete, the Chromium source code browser has a subset of the functionality of the internal Code Search tool. For example, you can left click on symbols to go to reference and right click to find all references: https://source.chromium.org/chromium/chromium/src/+/main:ipc...
How is this so much faster than browsing my tiny little repo on Github? What is Github doing so wrong??
One important piece of context that might make all these stories less confusing for non-googlers: Code references are less important inside Google editors, because we have a code viewer tool inside the web browser. Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually t…
To make this more concrete, the Chromium source code browser has a subset of the functionality of the internal Code Search tool. For example, you can left click on symbols to go to reference and right click to find all references: https://source.chromium.org/chromium/chromium/src/+/main:ipc...