Why I Don’t Regret Moving Our Android App to Scala

Really? I haven't tried setting that up but here is an example from 3 years ago of some one successfully setting up this exact combination [1]. Have things gotten worse sense then?

[1] https://groups.google.com/forum/#!topic/scala-on-android/0y1...

This hasn't matched my experience.

> Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind.

I assume you meant calling Scala from Java here. With that in mind, writing an API that is easy to use from Java isn't that difficult. It is basically down to limiting the feature set you make use of in the interface and converting to Java collections. These are both pretty easy to do. Granted some Scala features are expressed in ways that are not easily used from Java. However, this just because Scala is significantly more expressive than Java. I'm not sure why you consider this to be a problem.

> In Scala almost everything from Java gets reinvented sooner or later.

I'm not sure what your point is with this. Scala wrappers for Java code are common but not because of issues with calling Java code. These are written because Scala can expose a much richer and much safer interface (again because Scala is much more expressive).

I've seen certain core systems being polished for years, removing the bulk of the local technical debt.

Having zero technical debt company-wide is unattainable and impractical, though.

No one is saying they're unreasonable, some people are disagreeing with them. But you're strongly implying disgreeing is "shitting on them".

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

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.

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).

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.

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.