Live data from Hacker News

Server APIs Project

swift.org

171–180 of 181 posts

Re: Server APIs Project

#171

Earlier quoted context omitted.

How? Even the tooling seems to be vastly superior to the Gradle one. Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. Very slow compiles (contrary to what you claim). Language style encourages constructs that cause GC spikes, closures are not low overhead SDK dependencies automatically meaning what? The thing AS does for imports from AppCompat and co? Better instant run?

  Method count forces multidex insanely early into 
  development and for people who want the best UX that 
  alone is a show stopper.
That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-android.org/) and it doesn't grow much larger even after dragging in the collections API. Every single of Google's Android compat shims is way larger.

Here is a data point from a small example app written in multiple languages: https://github.com/SidneyXu/AndroidDemoIn4Languages

If you need multidex (you probably don't), it's a single setting away.

  Very slow compiles (contrary to what you claim).
After saving in my IDE, the plugin has incrementally compiled, ProGuarded, dexed and deployed the app to my phone before I can even grab it. That's pretty fast in my book.

testQuick is also amazing as it runs only the tests that have failed, haven't run before or depended on code you just changed: http://www.scala-sbt.org/0.12.4/docs/Detailed-Topics/Testing...

  Language style encourages constructs that cause GC 
  spikes, closures are not low overhead
Google has official recommendations on what to avoid in Java. You can follow the same rules and be fine. Closures have the same overhead as if they were written in Java.

  SDK dependencies automatically meaning what? The thing AS 
  does for imports from AppCompat and co?
No. SDKs (and NDKs) are treated like every other dependency, which means the plugin resolves, downloads, installs and manages them automatically (see https://github.com/scala-android/sbt-android#usage). This is especially useful if you work for multiple clients that have different SDK requirements. No need to write wrappers around Gradle scripts to run https://developer.android.com/studio/intro/update.html. No need for setup instructions if you hand the project to a colleague.

  Better instant run?
Protify existed before Google released Instant Run and is therefore more stable and mature: https://www.youtube.com/watch?v=LJLLyua0bYA It's so seamless that people use it for live-coding Android apps.

...

And then you have goodies like typed resources: http://scala-android.org/tips_and_tricks-typed_resources/

Or the automated Gradle config import which means you don't need to do configure anything except adding the plugin: https://github.com/scala-android/sbt-android/blob/master/GRA...

Re: Server APIs Project

#173
post #146

Earlier quoted context omitted.

Not anything major. It's just syntactic sugar for "\x -> x == 10".

How is it syntactic sugar? It's just applying "10" to the first parameter of "==".

Without parentheses, == is infix. (== 10) is an "operator section", and applies 10 to the second parameter of ==. (10 ==) would be the first parameter.

Re: Server APIs Project

#174

Earlier quoted context omitted.

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. Very slow compiles (contrary to what you claim). Language style encourages constructs that cause GC spikes, closures are not low overhead SDK dependencies automatically meaning what? The thing AS does for imports from AppCompat and co? Better instant run?

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-android.org/ ) and it doesn't grow much larger even after dragging in the collections API. Every single of Google's Android compat shims is way larger. Here is a data point from a small example app written in m…

Method count has nothing to do with size.

Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)

Proguard removes most of those methods, but you'll still need multidex for any non-proguard build like tests and debug builds.

And if you do grow an app past the point of being trivial as that example is Proguard gains will not be nearly as drastic

Multidex on pre-Lollipop ruins app start time, and only very specific types of apps can go to targeting minSdk 21

Predexing with Multidexing and Proguard are also slow for development for non-trivial apps. Your measure of "how long it takes to pick up a phone" is far from scientific", but to compare, not a single app non-trivial app I've worked on is so simple that installing a fully compiled APK over ADB would be less than a 5-10 second process.

That would leave 0-5 seconds for the entire app to build, proguard, and predex (with multidex). Not possible.

Gradle 2.2+ has the SDK download feature, and before that everyone I know was already using "sdk-manager-plugin", not even for convenience on dev machines (it's not that often that SDKs come out after all), but for CI builds.

Protify is not Scala exclusive if one really wants to use it, but JRebel also has a more mature Instant Run solution. Instant Run type features are useful for very specific types of changes that I don't find to be very common anyways. The layout editor + proper use of the edit mode flag and the tools namespace can already reliably replicate half of what I see instant run and co used for, with the added benefit of having even speedier development cycles.

Also: Typed resources are part of Google's databinding library, not that I know anyone who uses findViewById when we have libraries like Butterknife

To me using languages other than Java for Android dev is a risk about balancing mindshare, UX, and continued support for workflows in Android.

Kotlin has mind share, UX doesn't suffer, and it's gotten big enough that while Google has not come out officially and said it's supported, it's mindshare is large enough that Google knows that efforts like Jack and Jill cannot adversely affect workflows (The transformation API is great example, if projects like Realm, Dagger, and co didn't have so much mindshare I doubt it'd be much of a priority for the project).

Scala on Android has a much smaller mind share and is much less proven despite it's maturity, can kill UX a lot easier because of an insanely method-expensive core library which brings in thousands of methods once you use certain features, and is has not gained enough traction to to have to work around Google's plans than with them.

To me the proof is in the pudding, if there were real gains to be had with Scala it'd have more traction than it does.

Re: Server APIs Project

#175

Earlier quoted context omitted.

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. Very slow compiles (contrary to what you claim). Language style encourages constructs that cause GC spikes, closures are not low overhead SDK dependencies automatically meaning what? The thing AS does for imports from AppCompat and co? Better instant run?

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-android.org/ ) and it doesn't grow much larger even after dragging in the collections API. Every single of Google's Android compat shims is way larger. Here is a data point from a small example app written in m…

[deleted]

Re: Server APIs Project

#176

I wonder what happened to the rumors that Google was planning on supporting Swift on Android officially [0]. Also, are there any good tutorials/courses to get started with Swift & iOS development? (having programmed in other languages, I can pick up fast, and I've lost interest in tutorials that start out very slowly and take time to get to the point.) [0] http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi.…

It's in the works but it's no t officially supported by Google. https://github.com/apple/swift-corelibs-libdispatch/pull/162

Re: Server APIs Project

#177
post #169
post #165

Earlier quoted context omitted.

The linker part is described in these JavaONE 2016 talks https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g/sea...

Thanks for that. Are you aware of any numbers on the size savings you get for a typical app using jlink?

No, as I am yet to play with it.

So far I only seen the presentations.

But looking at Java 8 on this PC I would say:

jvm.dll (8 MB) + main.exe (200 KB) + trimmed down JRE

Also notice that from the presentations they have some experimental support for jlink plugins, which can further shrink down the size.

Re: Server APIs Project

#178

Earlier quoted context omitted.

How is it syntactic sugar? It's just applying "10" to the first parameter of "==".

Without parentheses, == is infix. (== 10) is an "operator section", and applies 10 to the second parameter of ==. (10 ==) would be the first parameter.

Ah yes, very true.

Re: Server APIs Project

#179

Earlier quoted context omitted.

Could you provide examples?

There are millions of lines of enterprise Java code running these days and a good chunk of these are using Java EE. The trend has started moving away from it these past years but it's pretty clear that even the worst and early versions of Java EE (looking at you, EJB 2) have been used to power massive web sites and applications that are still in use today. Erlang/OTP is nonexistent in comparison.

Now, please, try to think about to what degree (how many orders of magnitude) the Whatsapp ecosystem, which has been build on top of OTP, are more efficient in terms of data throughput, resource usage (both memory and CPU cycles wasted on thread scheduling and looking and busy waiting) and reliability (think of Facebook Messanger too), how many times less lines of code it has, to what degree the code is less verbose, less repetitive and hence more readable and maintainable.

I could give you a hint: the whole standard library of Erlang is (including optional type declarations for each function)

   schiptsov@Ideapad:~/Compile/otp/lib/stdlib/src$ du -sh .
   2.6M	.
I do not have Java sources.

Processed junk food is absolutely dominant form of human nutrition in the world. Does this fact makes junk food better than evolved (carefully selected) traditional dishes of rural communities, adapted to the local food sources and seasons?

Re: Server APIs Project

#180

Earlier quoted context omitted.

Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-android.org/ ) and it doesn't grow much larger even after dragging in the collections API. Every single of Google's Android compat shims is way larger. Here is a data point from a small example app written in m…

Method count has nothing to do with size. Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory) Proguard removes most of those methods, but you'll still need multidex for any non-proguard build like tests and debug builds. And if you do grow an app past the point of being trivial as that example is Proguard gains will not be nearly as drastic Multidex on pre-Lollipop ruins app start ti…

  Method count has nothing to do with size.
Nobody ever said that. It should still be obvious though that 30kB can't even remotely fit the method overhead you are claiming.

  Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)
I even read it! I suggest you do the same.

  And if you do grow an app past the point of being trivial as that example is Proguard 
  gains will not be nearly as drastic
They are. Been there, done that.

You pay for exactly the stuff you are using, just like with every other library.

  Your measure of "how long it takes to pick up a phone" is far from scientific", but 
  to compare, not a single app[sic] non-trivial app I've worked on is so simple that 
  installing a fully compiled APK over ADB would be less than a 5-10 second process.
Well, it works without issues here. How many apps did you develop with the SBT-Android plugin to be so damn sure about its capabilities?

  That would leave 0-5 seconds for the entire app to build, proguard, and predex (with 
  multidex). Not possible.
Perfectly possible. Used that for a while now.

  To me the proof is in the pudding, if there were real gains to be had with Scala it'd 
  have more traction than it does.
That only seems to be a proof that good marketing is more important than good technology.
Post reply on HN