5 ms·

I find AS to be much faster, more solid and stable than Eclipse in every aspect. I've been using AS for a couple of years, and was on Eclipse for about 4 years

I find AS to be much faster, more solid and stable than Eclipse in every aspect. I've been using AS for a couple of years, and was on Eclipse for about 4 years before that. With that said, your mileage may vary: Android Studio is one of those applications that seem to misbehave under certain specific conditions. Namely, if your main OS drive is not a SSD, things seem to slow down to a crawl.

usrusr 11y ago
Eclipse defaults to keeping all your tabs open, while AS defaults to aggressive LRU pruning? Eclipse always working hard to keep a live updated and as complete as possible bytecode model of your latest ctrl+s version available for instant (or close to instant) whole workspace error reporting, where AS only uses the compiler as a better linter, deferring non-local effects of code changes to the next gradle run, where errors are not even clickable in the console? The output of the IDE-internal "lint"-compiler run not even being available for a simple, local unit test rerun? Compared to the ambitious, smalltalk-derived vision of eclipse, AS sometimes feels like a glorified text editor that is only faster because it does not even try to do things eclipse does without much of a sweat. Now for some perspective, i know i have a rather biased view in this: i came to AS from eclipse when switching from backend to android (still do my backend stuff in eclipse), so i am not tainted by the supposedly terrible quality of eclipse-based android tooling that came before AS. Also, i am highly suspect of subconsciously blaming the IDE for certain annoyances that actually are just extra stuff that any tooling would have to do for android dev. I never used full IntelliJ, so i am only talking about AS in the strictest sense and do assume that regular IntelliJ can be closer to eclipse in terms of direct compiler integration and even build tool builds will not only be much more flexible than the gradle guiderails in AS but also less heavyweight (i guess i'm only talking about the gradle android plugin in this part). Now as AS2 claims to turn things upside down, i'd be glad to forget all this.

usrusr 11y ago

Eclipse defaults to keeping all your tabs open, while AS defaults to aggressive LRU pruning? Eclipse always working hard to keep a live updated and as complete as possible bytecode model of your latest ctrl+s version available for instant (or close to instant) whole workspace error reporting, where AS only uses the compiler as a better linter, deferring non-local effects of code changes to the next gradle run, where errors are not even clickable in the console? The output of the IDE-internal "lint"-compiler run not even being available for a simple, local unit test rerun? Compared to the ambitious, smalltalk-derived vision of eclipse, AS sometimes feels like a glorified text editor that is only faster because it does not even try to do things eclipse does without much of a sweat. Now for some perspective, i know i have a rather biased view in this: i came to AS from eclipse when switching from backend to android (still do my backend stuff in eclipse), so i am not tainted by the supposedly terrible quality of eclipse-based android tooling that came before AS. Also, i am highly suspect of subconsciously blaming the IDE for certain annoyances that actually are just extra stuff that any tooling would have to do for android dev. I never used full IntelliJ, so i am only talking about AS in the strictest sense and do assume that regular IntelliJ can be closer to eclipse in terms of direct compiler integration and even build tool builds will not only be much more flexible than the gradle guiderails in AS but also less heavyweight (i guess i'm only talking about the gradle android plugin in this part). Now as AS2 claims to turn things upside down, i'd be glad to forget all this.