Hacker News Reader

Comment by hoodoof | Hacker News Reader

Interesting that people feel the need to write posts justifying why they didn't implement in Kotlin.

Says a great deal about Kotlin.

The "interesting" part about the article is Scala vs Java more than Scala vs Kotlin, since Scala is generally accepted as a horrible match for Android from compilation times, to method counts, to binary sizes, to performance.

This post is essentially someone arguing how their choice with no benefit to anyone but the developers of the app and with drawbacks for all other stakeholders (since finding quality Android devs with quality Scala skills will be hard and product quality suffers for the reasons I mentioned above) made sense because they already wrote microservices in Scala, ignoring the fact that Android has a very specific set of challenges and development methods that make it's similarity to "normal Java" superficial at best, let alone Scala.

To top it off, the article is touting several things that even normal Java Android development can do:

TypedResource and TypedViewHolder = Databinding, But I prefer Butterknife anyways

Replacing AsyncTask = Really dozens of ways, there are Futures in Java, I'd go with RxJava (and Retrolambda) personally.

case classes = AutoValue (but I'll admit case classes are more concise)

It's also ignoring things like how much of the syntactical sugar shown increases method counts.

> compilation times, to method counts, to binary sizes, to performance

besides compile times (mitigated almost entirely by incremental compilation) none of these things hold up. Method counts are irrelevant with proguard and multi-dex (FWIW, most of our count comes from google support libraries anyway). Our binary is around ~5mb. I haven't ran benchmarks but I promise you that http requests, writing to disk, and WebView performance aren't slower because of Scala.

So you're saying the app is so small and extremely simple that even at full load jank isn't an issue, that multidex and size aren't an issue because you're not forced to focus on startup times and there are hardly any assets.

And I'm not saying that skeptically, I really believe it. Which is all the more reason that I don't see why you'd go with the using Scala. I don't know if you're referring to Lucidchart but I just look at that app and I can definitely see how it might not have to worry about jumping through hoops to shave startup time from a high method count or loading large data sets with tons of serialization and performant animations where built in immutable collections have unacceptable GC implications.

On the other hand you can apply that same reasoning and say it doesn't matter that Scala was used. But then you wonder why the "case study" should be considered by others, who probably don't have the luxury of having a small minimally animated app that can ignore stuff like method count effects on startup speed. To me the things that separate a top 50% app from a top 1% are things like high method counts affecting startup time on slower devices. It's not like Kotlin doesn't have issues that mirror those in Scala, but because it's essentially a "thin wrapper Java" with a slim standard library it's easy enough to identify when you're going to run up against parts with those performance implications

> no benefit to anyone but the developers of the app

So? Benefiting developers is very important.Development cost is the highest cost of software. Even if the only benefit of using scala is higher developer morale and productivity, it could very well be worth it.

> finding quality Android devs with quality Scala skills will be hard

We already use scala heavily at Lucid. We have to train Android developers in scala anyways. For us, using scala means the android developers only have to use one language, instead of two. It also makes it easier to leverage some common code in both the backend and the android app (for example serializing/deserializing objects over the network).

Using scala to write an android app isn't the right choice for everyone, and I don't think the OP is suggesting it is. But it was the right choice for us. And if you are already using scala in production, it is certainly something to consider when writing your android app.

I went the other way, Scala to Kotlin[1], and that's kind of the way I look at it. Scala's a really, really neat experimental language with some awesome ideas, but the amount of work it so frequently entails is disheartening to deal with and the developer experience with Kotlin is so, so much better in both tooling and expectations.

If your stuff is awesome, you don't really have to justify it like this.

[1] - though these days I mostly just write Node with ES6 or TypeScript, because consistency of ecosystem between browser, mobile with React Native, and the backend is just way easier.

My experience with Scala on Android was similar. As a language, it's very pleasant and powerful and would be ideal for Android programming if only you weren't constantly fighting against the fact that Android's tooling and technology were built around Java. It's a time suck. React Native is vastly easier, even though it means using Javascript.

To be honest, I was all-in on "screw JavaScript" until ES6 came around and Babel became stump-dumb-easy to deal with. I've found that just getting things done has gotten a lot easier in modern JS and TypeScript is a powerful tool (though working with React/Redux directly with it is kind of a pain in the ass; I tend to write React components in ES6 just so I don't have to what-the-hell-am-I-doing-with-my-life my way through react-redux).

FWIW, google adopting a second JVM languages means that Android tools will trend toward operating on bytecode and not source where applicable. They released some annotation processors for Room and their lifecycle stuff that operate entirely on bytecode so work well enough with Scala.

That aspect was already true when I was using Scala. Scala code compiles into .class files, and the Android toolchain takes over from there. Theoretically, no issue at all.

Would you say Kotlin is still experimental though? Scala appears to have a 10-year headstart, but time isn't everything.

I use F# and found Scala to be a breath of fresh air after getting sick of Enterprise-y Java, but haven't had the time to venture into Kotlin.

Scala has been around longer, sure--but it's also a bunch of stuff that doesn't really work well together and I'm still not sure that most (not all, by any stretch) Scala programmers really know how to write a program in Scala that's there to be maintained over the long haul. It can be done, but the pull of the super-broad feature set seems so strong that most of the developers I know personally, including me, write code that's awful to read two months down the line because it's dense and featureful and so very clever (note: very, very pejorative; the line about needing to be twice as smart to debug code as you need to be to write it applies here).

Kotlin is literally Java plus sugar. That's all it is. It encourages doing the right thing through stuff you could totally do in Java but nobody does because it's awful to write in Java. And, TBH, for the 90% case that's pretty great. There's no Shapeless in Kotlin--but that's a good thing, because Shapeless encourages developers with skill but no taste to do awful things and inflict them on, say, me. ;)

So, no, Kotlin's not experimental. Because experimental is a mindset, not an alpha/beta release stage.

Seems like you could make the same argument about modern C++ or other kitchen sink languages - lots of features, lots of ways to write unreadable code.

I've worked in Scala for the last 3 years and I've found implicits to be the biggest issue. They're hard to debug, it's not easy to tell which implicits are in scope. Things like that.

Being clever is a problem with the developer and not the language. Scala code is dense, sure, but that's not inherently a bad thing.

I would also say that most people should not write C++. To be clear, I like (Modern) C++ a great deal. I also like Scala a great deal. I don't think most programmers should write it.

I also like C++ a lot, but in what concerns the current OS trends from Apple, Google and Microsoft, even Qt Company, it appears its use is being shifted down the OS layers to pushing pixels, audio frames and driver data around.

With everything else built on top of it with safer languages.

This is quite clear with the set of APIs that are being made available to C++ on those OSes.

Yea, implicits were definitely confusing at first. That and picking a thread pool required a lot of reading. There seemed to be some other outset issues like "avoid this seemingly innocuous operation since it actually has a huge perf hit", but those usually manifest quickly and get eliminated with any sort of application tuning.

This is so very true. I find Scala tends toward the classic "read-only" joke. You can write very powerful code, but it's often hard to debug and it tends to be quite difficult to read down the line. We have a Scala application that is being slowly replaced, but which I maintain in the meantime, and it is by far my least favorite job duty, despite that I theoretically like Scala more than, say, Java.

Probably my biggest disappointment with Scala is really the type system. It's incredibly powerful, but it's unwieldy to use, and it's still full of footguns. "object" is great and useful until someone accidentally turns it into a giant race condition (true story). Traits can easily turn into a maintenance nightmare (ever seen an 8-way multiple inheritance scheme that fans out into 23 separate ancestor classes? I have!) Exceptions end up in a strange territory. There's ways to handle all of this (much of it involves "don't do that!"), but the point is that for all the type system's powers, it's not actually buying you that much except in comparison to Java 6/7. If I want powerful type magic, I can use Rust or Haskell or similar and get stronger guarantees from my compiler. If you're writing "better Java", which is traditionally one of the more common Scala uses, it's harder to justify over Java 8 or Kotlin these days.

All of which is to say, Scala is a really cool language, but I wouldn't write new projects in it if I didn't have to.

Bonus round: We had a Scala iOS app via RoboVM before RoboVM support was yanked. It still gives me nightmares.

Yeah, all that pretty much tracks for me. I think the best way I've heard it described is thus: you can write Perl in any language, but it's really hard to write Scala in anything else.

I wrote an Android Scala app once. I regret the experience.

So is React Native a truly viable way to build a complete mobile application?

Any downsides, weak areas, problems?

Well..."truly viable" means different things to different people. I'm a devops jock (so build systems never really scare me, and that's probably the nastiest part of React Native) but my background is in application development and I got up to speed with React earlier this year. I built in five days a well-scoped but nontrivial app I'm releasing as soon as I get my LLC and EIN situation figured out (I might Show HN it) and I'm extremely happy with the result. The app works as-promised on Android and iOS; I have some additional stuff to do before I launch the iOS version because theming isn't 100% between iOS and Android, but it was recognizable and usable from the jump and it by-and-large worked as intended.

The downsides are mostly what you'd expect. You're welding together a JS bundle with Java (Android) and Obj-C (iOS) generated projects to create a deployable and that's a little fragile, though it's not really a problem. `react-native link` exists to try to help with that by automating the insertion of dependencies that require going outside of JS (stuff like Firebase or other native-API integrations); on one hand, I've never gotten it to work, but on the other, I know both Android and iOS development separate from React Native so it's totally not something I even think about. That probably also encapsulates most bugs I might run into with packaging, etc. to the degree that it's really hard for me to answer your question. I already know both of those environments and most of how they get wacky; stacking a little on top of that's not really a big deal.

The hardest single thing to do was integrating Firebase because I got some wacky Gradle error, but I figured it out. The second-hardest thing was parsing every JS package (460 packages, yeeesh) in my app so I could make sure I included their licenses in the deployable to be compliant with the licenses (and I am certain some of the licenses I included are actually from the build tools, but whatever). There are 500kB of licenses in my app, hidden in an 'about' dialog box that I expect nobody will ever open, but if that's as hard as it gets...meh.

Debugging is worse than it could be, but it's React/Redux in a very constrained environment, I'm not worried by it. And there are often no platform-agnostic wrappers for stuff (I needed in-app billing as my app is time-limited demoware, and I have two separate codepaths), but let's be real--that's not much of a thing.

I like it. React and Redux are comfortable ways to handle state management and I don't spend much time thinking about it. It means not writing Java or dealing with Android directly and iOS development is certainly no worse, and probably a good bit better, than it was before. It's faster to make something that looks and feels good. Also, and it's a little thing, but the react-native project creation tools are awesome and they make getting off the ground really easy.

Reply on news.ycombinator.com