Hacker News Reader

Comment by eropple | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com