Hacker News Reader

Comment by jorgemf | Hacker News Reader

Using kotlin in web pages, client side and server side could be a big win. You could be able to use exactly the same language in all you stack. Although programming for the frontend will be different than programming for the backend, the fact that any of them can review the code of the others is great. You could also move resources in peak times to help a little.

View on HN

I still prefer TypeScript for web frontend code, because it fits a lot nicer into that ecosystem (React, MobX, webpack, etc.) and the structural typing also feels better suited for that environement.

Kotlin could however be awesome for cross-platform mobile dev, targeting both iOS and Android with a lot of shared code and truly native apps on both.

TypeSript is more mature and better option for frontEnd now, but I hope kotlin will catch up.

I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could share the business logic but that is something I think should be on the server not in the app. The app is only the frontend.

In my experience, there is a lot of opportunity for sharing code between mobile platforms that doesn't have any real downsides. Things like:

- data structures for your domain objects

- network code (just plug in an appropriate platform-specific driver)

- like you said, business logic - especially if the app has to work offline

- if you're using something like https://realm.io/, you could avoid a lot of duplication

Anything to do with the UI then has to be platform-specific of course.

> - data structures for your domain objects

not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar.

> - network code

In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this.

> - if you're using something like https://realm.io/

Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries.

Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.

For anyone not that familiar with Android, "must use okhttp" refers to the fact that it is the best solution, not that it's the only solution.

> use exactly the same language in all you stack

isn't this what people are doing with JavaScript?

It is, but the problem with that is that they're doing it in JavaScript.

Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.

Have you tried TypeScript?

Typescript is nice but its type system is not the strongest selling point.

For example this compiles without warnings:

   const foo: Promise<string|null> = Promise.resolve(null);
   const bar: Promise<string> = foo;

   bar.then((value) => value.toString()); // runtime null error

That's because null is an acceptable value for a string object.

Which is the same thing as in Java and plenty of other languages.

Not in Kotlin, though. You have to make it explicitly nullable if you want it to be null.

You can enable strict null checking.

You can replace string|null with string|number in this example.

A bit. It's an improvement, but if you're writing Kotlin on the backend then Kotlin/JS starts to look tempting on the basis that it's the same language everywhere.

Although using the same language in different environments obviously feels a bit different.

you don't have co-routines in JavaScript, you cannot use java libraries in JavaScript, the tooling support for java/kotlin is much better than for JavaScript, Javascript is weakly typed,... In general I think kotlin is much better language. JavaScript has a lot of issues

The problem with Javascript can't handle complex computation where Swift could run on both Android, iOS, embedded, cloud, Linux and web server and majority of C/C++ libraries. Soon they might found way to implement Rust memory model, concurrency and Coroutine like Go. It will be nearly perfect or as good without writing 4 different languages.

Kotlin could run on all supported platforms and reuse Java libraries.

You have coroutines in kotlin! and the support for native executables has started. Swift is also a very nice language, with a couple of issues: the tooling support and its instability in the first versions. But I also miss one thing from swift in kotlin: its memory model (maybe Rust one is better but I don't know it)

I know Microsoft contributed Coroutines to LLVM and now experimental in 4.0.0 and .Net core.

Which is even awesome for Microsoft to adopt LLVM.

Reply on news.ycombinator.com