Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Takeaways from KotlinConf 2017

vokal.io

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Takeaways from KotlinConf 2017

#11

Post by on_and_off »

crispinb wrote: post #10
blueprint wrote: post #8

Earlier quoted context omitted.

What exactly is wrong with view controllers..? That strikes me as rather like saying there's something wrong with 3GLs. Are you suggesting React solves the programming language problem completely? If not, I'd like to ask you again what is wrong with view controllers. I've had frankly endless success with them once I got over my lackings.

Well there's nothing absolutely 'wrong' with them. You can write good and bad apps with view controllers (I've done both). But they're an architectural blank slate, mainly offering access to UI objects & lifecycle callbacks. You need some architecture on top in anything but the most trivial app. The naive approach is to have 'no architecture', which actually is an architecture of just throwing masses of state, ad hoc…

> Simple unidirectional data flow & UI state being a simple function of app state make for a beautifully clean and unambiguous model for how everything fits together.

Not an iOS expert (I work on Android) but can't you have this in native in the first place ? Many Android apps are already using this kind of arch without React Native. I don't see why it can't be the same on iOS.

Re: Takeaways from KotlinConf 2017

#12

Post by crispinb »

on_and_off wrote: post #11
crispinb wrote: post #10

Earlier quoted context omitted.

Well there's nothing absolutely 'wrong' with them. You can write good and bad apps with view controllers (I've done both). But they're an architectural blank slate, mainly offering access to UI objects & lifecycle callbacks. You need some architecture on top in anything but the most trivial app. The naive approach is to have 'no architecture', which actually is an architecture of just throwing masses of state, ad hoc…

> Simple unidirectional data flow & UI state being a simple function of app state make for a beautifully clean and unambiguous model for how everything fits together. Not an iOS expert (I work on Android) but can't you have this in native in the first place ? Many Android apps are already using this kind of arch without React Native. I don't see why it can't be the same on iOS.

Yes, but it doesn't come for free. You have to adopt an architecture & write the relevant boilerplate, or use a library where relevant. In the RN case, the least trivial part is applying UI diffs representing the move from a previous to next app state.

Have a look at my parent post -- what I was expressing a wish for was a cross-platform Kotlin library implementing RN-like UI rendering. I'd love to get a combination of the benefits of the RN approach, but written natively in Kotlin.

Re: Takeaways from KotlinConf 2017

#13

Post by zastrowm »

TylerE wrote: post #6
gman83 wrote: post #5

Earlier quoted context omitted.

I think Kotlin/Native's approach of sharing business logic while keeping the UI stuff native is probably the right choice. Although something like Flutter which render's all their own widgets is interesting because it allows you to share even more code. The question there is whether they'll be able to truly match the native widgets and have all the accessibility stuff working. In any case it's good that different pro…

History says no. Any widget toolkit, on any platform ever, that has tried to provide it's own cross-platform widgets, has been completely terrible and ends up being native-nowhere instead of native-everywhere.

I'm curious if this will change now that webapps/electron-apps have become so popular. It may be that users have begun non-native apps as the new norm.

Re: Takeaways from KotlinConf 2017

#14

Post by mwcampbell »

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine (https://multi-os-engine.org/), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be.

Of course, there's a trade-off between Kotlin Native and Multi OS Engine. Kotlin Native is a lighter runtime. BUt with MOE, you can use arbitrary libraries that target the JVM (well, the JVM subset that works on Android). So MOE makes a lot more existing code available for iOS. For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

This space is going to be interesting to watch over the next little while.

Re: Takeaways from KotlinConf 2017

#15

Post by kodablah »

mwcampbell wrote: post #14

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine ( https://multi-os-engine.org/ ), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be. Of course, there's a trade-off between…

> For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

Or someone writes a bridge between native Kotlin code and AOT'd JVM code. Or someone writes a kind of reverse compiler from JVM bytecode to Kotlin. Not sure how practical either is due to sheer JRE stdlib size.

Re: Takeaways from KotlinConf 2017

#16

Post by hota_mazi »

mwcampbell wrote: post #14

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine ( https://multi-os-engine.org/ ), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be. Of course, there's a trade-off between…

The Multi-OS engine has a much narrower scope than you describe: really just write apps on Android and run them on iOS.

It's not a way to run a JVM language and certainly not a way to generate Kotlin code for native targets.

Kotlin Native is very exciting because it's a potential threat across the board: not just to run iOS apps written in Kotlin, but also to generate native code from Kotlin in back end system, a domain that's currently heavily contested by both Go and Rust, and also to write Kotlin and generate Web Assembly.

It's going to be a very interesting next lustrum.

Re: Takeaways from KotlinConf 2017

#17

Post by pjmlp »

zastrowm wrote: post #13
TylerE wrote: post #6

Earlier quoted context omitted.

History says no. Any widget toolkit, on any platform ever, that has tried to provide it's own cross-platform widgets, has been completely terrible and ends up being native-nowhere instead of native-everywhere.

I'm curious if this will change now that webapps/electron-apps have become so popular. It may be that users have begun non-native apps as the new norm.

In five years the Electron craziness will be gone.

Re: Takeaways from KotlinConf 2017

#18

Post by pjmlp »

gman83 wrote: post #5
blueprint wrote: post #2

Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.

I think Kotlin/Native's approach of sharing business logic while keeping the UI stuff native is probably the right choice. Although something like Flutter which render's all their own widgets is interesting because it allows you to share even more code. The question there is whether they'll be able to truly match the native widgets and have all the accessibility stuff working. In any case it's good that different pro…

That is what I do with C++ for sharing business logic.

Only need the SDK tooling, without being forced to debug extra layers of third party tools.

Using extra, non official language X usually overshadows the extra debugging and configuration efforts of adding yet another layer into the overall architecture.

Re: Takeaways from KotlinConf 2017

#19

Post by bonesss »

pjmlp wrote: post #17
zastrowm wrote: post #13

Earlier quoted context omitted.

I'm curious if this will change now that webapps/electron-apps have become so popular. It may be that users have begun non-native apps as the new norm.

In five years the Electron craziness will be gone.

And, judging from what was going on 5 years ago, whatever replaces it will be even crazier and trendier :)

Re: Takeaways from KotlinConf 2017

#20

Post by peoplewindow »

kodablah wrote: post #15
mwcampbell wrote: post #14

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine ( https://multi-os-engine.org/ ), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be. Of course, there's a trade-off between…

> For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop. Or someone writes a bridge between native Kotlin code and AOT'd JVM code. Or someone writes a kind of reverse compiler from JVM bytecode to Kotlin. Not sure how practical either is due to sheer JRE stdlib size.

Look at SubstrateVM. It's capable of making fully stripped AOT compiled binaries with a bundled JVM that only use the parts of the JRE library that are needed. Sort of like what Go can do.
Post reply on HN