This is a side note, but most members of the Android team at Google used to have 256 GB of RAM on their computers to compile Android (the entire build). When we used Android Studio, it was blazing fast so most devs that didn't work with users were not aware there was a problem.
I'm on the Android team and no, we don't. The current spec workstations are 128GB RAM, 1TB SSD, and 2x Xeon E5-2690 v4. But there's still a lot of the older 64GB & 96GB workstations in use as well.
The low clock speed of the Xeons (plus NUMA) means that for most things the machine isn't actually that fast, though, unless you can put the all the cores to use.
I don't think that really refutes the point, the median public user of Android Studio is probably closer to 16GB of ram right? With a nontrivial percentage of people with 8GB? So you're still talking about an order of magnitude more ram than those people.
Median 16GB? No way from my experience with dev agencies - most are on 8GB, some on 16GB, some on 4GB. I think I've only seen one Android dev with 32GB, ever.
I wasn't on the Android development team but rather I was in management, but my colleague was and that's the information I got when I tried using his workstation (he specifically works on Android framework). I actually never checked myself so that's my mistake, so I apologize if I am
spreading misinformation.
Funny you mention these stats, I work on Solvent IDE (codesolvent.com), I purposefully avoided beefing up my dev laptop to keep me honest...my dev box has crappy performance so that when I run the software on a more capable machine (like a medium ec2 instance) I get a nice performance boost :)
Always better to be more conservative to get a better sense of end user experience.
Not sure where you get this from, I'm not in an Android team, but from what I can see the top offered workstation one can get at Google has 64 GB of RAM.
I would assume that there was a special policy in place for people working on teams with a requirement for that amount of RAM.
I interned on Chrome in 2013, and at the time all Chrome engineers got a computer with an SSD (which I was told wasn't standard at the time), since they had to build Chrome on their desktops (whereas most other engineers could use Google's distributed build system).
64 seems a bit low, that's what I need for my hobbyist work. Granted, it doesn't take 64GiB of directly-allocated RAM to link Chrome (anymore), but there's almost no amount of page cache that would not be worthwhile if you have the whole AOSP on a box.
It runs very well on my 16GB RAM. I find a lot of the speed is in internet and hard drive speed. It opens up a full project in 3 seconds with a SSD, assuming there aren't too many dependencies.
I was also forced to buy an SSD to make my life easier, but lets be honest, SSDs are still quite expensive on price per GB on first world countries, let alone the rest of the globe.
Same regarding RAM, I know of companies that a standard developer machine is 8 GB, while everyone else gets 4 GB.
Getting something like 16 GB is unthinkable unless that is a business related change request.
So basically making the life miserable for those developers.
Mostly in context of text editing/auto completion hints. With e.g. intellij there's enough choppiness/delay in typing and completion to really put me off.
Have you tried the new versions with Zero Latency Typing? As the name implies, they managed to basically eliminate all latency on typing, even beating apps like notepad++ and emacs on latency. It's switched on by default in the current release.
Pretty primitive compared to what IntelliJ actually does, which for Java (and typed JS, Scala, Kotlin, etc) is full source code indexing and understanding of the type hierarchy.
That means "Find Usages", "Jump to Implementors/Overriders", "Show Substypes", etc all work correctly. When you ask for code completion, it's far above what IntelliSense does. IntelliJ will actually understand all of the variables and types that are reachable in scope, as well as those that are reachable by calling methods or accessing fields on those types two or three levels down. This is not the same as just examining what's reachable via 'this' or what's to the left of the '.' character.
The autocompletions are also ranked and sorted properly most of the time. Think of it as the difference between a shitty search engine and one that shows the most probable autocompletions first. Even Eclipse IMHO is pretty bad at this, and will often try to suggest meaningless classes somewhere on my classpath that I'm obviously not going to use, including internal sun.* implementations.
IntelliJ's refactoring and code analysis is also far above what XCode and VSC do. I've been using IntelliJ since the first version, and to me XCode and VSC aren't much of a step above Emacs as an IDE.
Syntax Highlighting, VCS integration, Debugger, and Jump to Symbol Definition are table stakes that even basic text editors have.
Erm, VSCode does all of that for Rust via RLS and the Language Server Protocol[1]. Heck, VSCode does even better than Android Studio because the pick common words in the source file as part of their auto completion. Things like comments, untyped parameters(ints, etc) all work much better in VSCode.
I'll agree that for Java VSCode isn't up to par yet but for many other languages it's easily at an equal level.
This is a matter of opinion, but language-specific navigation, searching, and refactoring is where I'd draw the line between an editor an an IDE. VS Code may not be there yet, but they're improving quickly and I think it's only a matter of time.
Better search ranking seems like a feature that could easily be added (though it has to be done for each language).
I'm happy to see competition in this space. The end user might not see it, but IntelliJ internals are pretty horrible from a plugin developer's point of view and haven't improved in many years. Moving language smarts to editor-independent servers (with VS Code's Language Server Protocol) seems like the right architectural move.
While I agree that IJ's internals are spaghetti, the VS LSP isn't quite the same, or at least, it appears to me, it does not offer the richness of IJ.
Consider that IntelliJ can syntax color and autocomplete multiple language grammars at once, e.g.
String aJavaString = "<someHtml onFoo='someJs.style=\"color: red\"; var regex = new Regex(\"someRegex\");'">
Does VS's language server protocol handle the ability to deal with nested language grammars each with nested contexts?
My issue is false negatives: IntelliJ usually just "works", especially with Java, it's near perfection and almost never gives a wrong completion. I've never encountered another IDE whose code understanding was as complete. Even a 2-3% false completion rate is super annoying.
Plus, the refactoring, structural search, and callstack analysis stuff is beyond reproach. Can VS tell me all possible reaching expressions to a given method? I've used that before to figure out what kinds of subtypes or nullability a given parameter has, but it requires global code understanding.
I feel like the kind of functionality that grok style code indexing provides is just the baseline, and what's important is what's built on top of it. VSC has a long way to go to reach IJ in that regard.
While agree that IntelliJ is pretty great the Android Studio implementation of it is nowhere near perfect. I've had false lints, incorrect flags and a whole class of issues where intellisense goes wrong.
