Hacker News new | ask | show | jobs
by butz 3706 days ago
And it is still slower than good old Eclipse.
10 comments

Hmm... no? I find Android Studio way faster in daily usage compared to Eclipse, and above all it's way more refined: I don't have to "clean" my project twice an hour, and dependencies management and writing is much easier.
Android Studio slows down my whole machine to a crawl even if it's just running in the background doing nothing. I throw piles of stuff at my machine without a slowdown (see my other post) and the only thing that manages to kill any and all performance is Android Studio. Eclipse runs like a dream in comparison.
I don't think it's the IDE, it's the build system. When Google pushed everyone over to Android Studio they also pushed everyone from Ant to Gradle. Gradle is supposed to be a better Maven but it's just dog slow. Just typing gradle --help takes over 3 seconds on my Macbook Pro.
Migrating to sbt-android has been a revelation coming from Gradle.

It's bizarre that a one-man-team beats the mighty Google in pretty much everything.

The build is so freaking fast that it runs ProGuard by default – and beats a Gradle build without ProGuard.

That dev implemented and shipped Instant Run way before Google "invented" it, and it's still faster compared to Google's implementation.

I really don't get their hype around Gradle, if it wasn't for it, most likely no one would care about Groovy any more.

Since my focus is the NDK, which keeps being half-done in Gradle, I keep using Ant + ndk-build and have migrated to Visual Studio 2015 for my Android hobby coding.

As far as I know, sbt-android just recently got even more support/features for NDK (on top of the existing support):

The plugin can now manage and auto-install SDKs, tools, support repos and NDKs, so no messing around with Google's `android` tool anymore!

Maybe this is of use to you.

https://github.com/scala-android/sbt-android/commit/7b32e55f... https://github.com/scala-android/sbt-android/commit/53b855de...

Thanks!
Was it ever popular in SV? No. That doesn't mean no one is using or cares about it.

For my day job, we use Groovy for our Spring Boot app. I love it.

I've also done a lot of Grails development, which I enjoyed also.

It was popular in Germany around 2007. All JUGs were doing presentations about Groovy and Grails.

It was even on JEE roadmap to be an alternative language for JSF applications, presented at JSF Days in Vienna.

Nowadays if it wasn't for Gradle, I wouldn't even notice it exists.

I remember those days. Not a lot came out of those presentations, though. It was a lot about Java guys having a bit of dynamic language envy, while having to code with Struts and 1.4 Swing all day. A way of getting that hype and with it some new tech to play with into the enterprise by a backdoor. Which is way too hard to do.

Mobile dev being new, even Java developers get to play with more shiny toys. For good or ill...

It's a stretch to say Gradle "uses Groovy". In practise, it more like uses a tiny non-Turing Complete subset of Groovy.
No, large parts of Gradle are actually implemented in Groovy. You're referring to the DSL, which can be used purely declaratively, but it's not limited to such use (you can use all Groovy language featured in Gradle scripts).
> large parts of Gradle are actually implemented in Groovy

I thought it was just the plugin and DSL handling code. That would explain why Gradle's so slow, then.

> the DSL, which can be used purely declaratively, but it's not limited to such use

Virtually no-one uses Groovy procedurally, only declaratively, in Gradle build scripts, so although that's true in theory, in practise only the non-Turing Complete portions of Groovy are used. Calling it a programming language there is like calling HTML one because you can embed Javascript in HTML.

Put

    org.gradle.daemon=true
in your .gradle/gradle.properties. Slow startup is an old JVM problem.
> Slow startup is an old JVM problem.

No it not, when people make use of Java code, it starts in ms.

It is only slow when running languages like Groovy or Clojure on top of it.

I know you're getting down voted, but I agree. In my experience, in both Windows VMs and on OS X, Intellij is just slow.

From the VM side, Eclipse compiled quick, Tomcat restarted great, JUnits flew. To be fair this was pretty straight forward Spring MVC/Services, no web plugins for HTML5 stuff. Intellij for Web Development (Gulp, and AngularJS support) was just terrible. The UI would be unresponsive. It could take multiple seconds for the File menus to pull up. Builds are slow. Hot deploy wasn't much better than in Eclipse.

On OS X, there's a typing lag. I could live with that. My big issue here is that Eclipse gets better battery life. There is a known bug in Intellij that forces OS X to keep the high performance graphics card on. Battery goes from 5 hrs to 2.5. This makes getting out of the house untenable. I use Android Studio because that's the guidance, but I prefer to not use Intellij if I can.

from my exp on Mac. Intellij is the fastest IDE. Sure beats the shit out of Xcode.
In theory, the new "instant run" feature addresses some of the "clean, build, deploy, run" pain.

http://tools.android.com/tech-docs/instant-run

In practice, what I've seen so far is that sometimes I'm not sure what is being "instantly run" -- my latest code change or something older. Still trying to gain confidence in that feature (or just not use it because I don't understand what it's deploying all the time).

Did you give https://github.com/scala-android/sbt-android-protify a try?

It exists longer than Google's "Instant Run", is faster and works without flaws (in my experience).

Thanks. Will definitely look into it.
Not just slower , it does not fit to native look and feel, You are not going to believe me how much time I spent for fixing ridiculous font rendering for Android Studio, at the end I just gave up (in Ubuntu. I tried all kind of patches, TuxJdk, changing arguments for OpenJdk, OracleJdk , changing fontconfig, using infinality and anything you can imagine. nothing works). Right now I am switching to Xamarin,Perfect support from Microsoft (because it is important strategic product for Microsoft. I remember one year ago I predict Microsoft will buy xamarin and open source it).Bash is coming to Windows and lets be honest , none of java's IDEs can compete with Visual Studio.

and one of the worst thing about google is they don't deliverer feature they promise. I did a lot of NDK development. I use emacs for that , but eclipse was acceptable too. But I remember last year they promised full NDK support in android studio, but they haven't introduced it yet. This is what absolutely I will not tolerate from a company. If it is not ready , then don't introduce it in development conference , if it is ready why it took so long (1 year ??? and still no news).

another point about Google is they don't absolutely care about developers. Who are we kidding ? no one can deny for years developer begged google for new,faster,better Android emulator. But they did nothing. Right after Microsoft introduced their Hyper-V based android emulator which is fast as hell, They developed new virtual machine. (they use qt5 for its interface). Because they felt threatened by Microsoft.I promise if it wasn't for that the old emulator was still there.

> You are not going to believe me how much time I spent for fixing ridiculous font rendering for Android Studio, at the end I just gave up (in Ubuntu. I tried all kind of patches, TuxJdk, changing arguments for OpenJdk, OracleJdk , changing fontconfig, using infinality and anything you can imagine. nothing works).

I went through all that BS so I feel your pain, but thanks to the IDE gods the IntelliJ people fixed the Linux font rendering issue in their 2016.1 release. They now include a custom JRE that fixes it. This custom JRE can also be used in Android Studio (and surely any other Swing java programs) just create a symbolic link pointing to it inside Android Studio's root folder and you're done. Needless to say this is way more elegant and safe than the ridiculous TuxJdk "fix".

Yeah. There's something to be said for having a highly developed intelligence for building great IDEs and libraries at the _organization level_ rather than just at the individual programmer level. Despite its reputation for hiring the very best programmers in the world, Google's ability to create a really great developer toolchain for Android didn't measure up to what Microsoft has been doing for decades.

It seems like Google has tried to pursue a cheap shortcut to IDE greatness, at first by building a plugin for Eclipse, and then, by putting some money into a relationship with IntelliJ and Gradle (who truly are excellent at what they do).

But still, Google has not brought the excellence of organization and deep commitment fully in-house.

If I would be on the Android team, I would feel ashamed that Microsoft in less time that they have introduced C++ support in Android Studio, already has a better developer experience than Google will ever managed to do.

On the other hand, I guess if they had a choice, the NDK would probably not even exist.

Yeah, it just shows that Google clearly sees app developers as sharecroppers. "Don't like our terrible software quality and negligence? GTFO, there are hundred other desperate people writing the same app."
Much better to use though. Eclipse just feels like drowning, if you're not already into it.

Android studio lets you pull out what you need, when you need it and doesn't just throw everything in your face like eclipse (and there's a lot it it there!) either you need it or not.

I'm guessing there's a reason Google decided to obsolete their eclipse-based Android SDK tools.

Yeah I just started dabbling with it and I have an ultra fast windows 10 laptop with solid state drive and I'm amazed at how long it takes to go from changing a line of code to running it in the emulator.

I was originally planning to do dev work for android in a virtual machine like everything else I work on but I doubt it would be anywhere near performant enough.

If you wanna feel something rare, find a win98 box on a pentium 2/3 and run turbo pascal IDE. Enjoy the paradoxical bliss.

ps: TURBO.EXE amounts to a whopping 600KB.

LightSpeed C: modify-to-run in a couple of seconds (often).

I worked on an assembler/editor that had a change-to-run system on the order of a couple of seconds, too.

Something changes when you have near instant turnaround time. It's magic.

Some of the most miserable time I've spent has on projects with tooling where builds took hours, and often hours just to fail. I was even okay with 30 minute turnaround time, as long as it was clear that the bottleneck wasn't fucking lame tools: The need to burn a bunch of EPROMs for each build, for instance . . . though I fixed that as soon as I could.

Or if you're into something more modern, Delphi 7 will do. And it'll probably run on modern Windows.
I can't decide which I prefer, the charm of text mode(TP7.0 was really pretty and nice) or the look'n'feel of early windows GUIs (Windows 3 / OS2 warp beveled boxes and pale hues are so nice).
MS-DOS 3.3, Turbo Pascal 6.0 and TASM, all in a 1.44 floppy! :)
I have a weird fetish of making everything fit on a floppy. Acute Kaytosis I guess. If I had functionning floppies I'd prep a DOS3 one like yours :)
Speed is kind of a funny thing with IDEs. All of my typical workflows are faster in Intellij than they were in Eclipse. YMMV if you are hitting different features than I am.
Not my experience on OS X.
Android development was invented by Google to convert programmers who use Windows into programmers who use OS X.
Not only it is slower and takes piles of RAM, it still doesn't support the NDK properly, which keeps being experimental and lacks the majority of features that Eclipse CDT and ndk-build have.

Eclipse CDT with Ant + ndk-build finish a build before Gradle manages to parse all its configuration files.