We had a C++ framework for the 2 mobile+3 desktop platforms at my previous workplace with about 8 people working on it and on average 1 person per platform for the UI.
Based on that, I don't think it's a good idea to try to go cross-platform for the business logic if you only have 2 platforms with less than 4 devs each. It's also not a good idea to pay mobile dev salary for mobile dev quality business logic code, C++/Rust/etc. will get you better code per money spent. Not to mention the possible issues that could arise with using niche tooling, like the KMP compiler.
I don't really understand the point of kotlin. Why did google bother to introduce a new language that still relies on the java VM? Why didn't they just rewrite their standard libraries in C++, and build kotlin on top of that?
Do google even care about android or is it such an absurdly low revenue division that they try to spend as little as possible on it?
> Why did google bother to introduce a new language that still relies on the java VM?
Kotlin was not created by Google, but JetBrains. Also there are many other JVM languages (e.g. Scala). People write new languages for many reasons, and that's probably why we are not stuck with assembly (or even binary?).
> Why didn't they just rewrite their standard libraries in C++, and build kotlin on top of that?
Not sure I understand that. You mean that the Android SDK should be using C++ at the core, and expose a Kotlin API? The user would not see a difference, and I would guess that some parts at the lower level are written in C/C++ (or even Rust nowadays).
> Do google even care about android or is it such an absurdly low revenue division that they try to spend as little as possible on it?
What would you suggest as a better design? It seems to me that you just don't like the JVM (maybe because you read somewhere that the JVM is bad and accepted it like this?) and just complain about it. Or do you have real criticism about the JVM? And since you seem to be targeting Android, do you know that Android is not actually running the JVM?
I assumed google designed kotlin, my mistake I do not care about android. The decision however is even stupider given that is not the case. I was suggesting they could rewrite their libraries in a language that compiles directly to machine code (like C++) and design a language on top with a simple to use and memorizable syntax like swift which would transpile to C++ giving you no overhead. That is my proposal for a far better design that would have a substantial impact to developers, users, and OEM's.
Ignoring your snide remarks. Yes using dalvik (the same nonsense as JVM) is a stupid idea for a company that can afford to make development more efficient and performant. Why is there an intermediary layer introducing overhead when it doesn't improve the developer or user experience? If you don't think the user would notice you're myopic. Being able to use cheaper hardware to provide faster devices is a direct benefit to consumers. And perhaps you're too young or inexperienced but Android was designed to use Java for the ease of transitioning existing mobile phone developers to smartphones.
The patchwork of changes they have made between now and then do not provide anywhere near the benefits of what I suggested. It would behoove you to actually understand the overhead of interpreting bytecode before suggesting it offers no impact to compile directly to machine code. Perhaps you're blindly loyal to android because you've been in the environment too long. As someone who has done both android and iOS (primarily the latter) development the experience across the board is unparalled for developers and users.
Just accept android is trash and google don't care or are mismanaged by morons too disincentivized to fix it because of google's crabs in a bucket culture.
> I assumed google designed kotlin, my mistake I do not care about android.
That's exactly what I criticize: you assume stuff that is wrong, and then you say "it's stupid".
> with a simple to use and memorizable syntax like swift
Have you ever tried Kotlin, or do you assume it is bad?
> Yes using dalvik (the same nonsense as JVM) is a stupid idea
Too bad, it stopped being Dalvik years ago. But I guess you just assumed without checking anything, again.
> Being able to use cheaper hardware to provide faster devices is a direct benefit to consumers.
Sure. Feel free to design cheaper hardware and provide faster devices. If you take the Android market, you'll be rich.
> And perhaps you're too young or inexperienced
Just experienced enough to not "assume" wrong stuff and feel like I know best.
> The patchwork of changes they have made between now and then
Says the person who doesn't know that they have changed Dalvik.
> It would behoove you to actually understand the overhead of interpreting bytecode
Assuming again? Ever heard of AOT?
> Perhaps you're blindly loyal to android
Absolutely not. Android has its issues, so does iOS. I just do my best not to say stuff like "it's a piece of trash because <wrong fact> <wrong fact>".
That read to me like a veeeeery long complaint about... not sure what. The TL;DR is: "Kotlin Multiplatform will not replace everything everywhere, because nothing does". Apparently that counts as "not succeeding" to the author.
My hope is that JVM languages will come back for Desktop apps. And if some code/libraries can be shared between e.g. Android and Desktop, then that's a win.
>But … KMP will fail to reach mass adoption because of human nature. People resist change and anything that is unfamiliar to them.
Yeah, it's not that. That is just a big hand waving argument, which one could say for anything, including stuff that will get mass adoption.
"Humans will never use C/C++/Python/Java/C#/JS/... because something something human nature. People resist change and anything that is unfamiliar to them."
The reason is KMP is just one offering among many others in the multiplatform "shared code/UI" space.
Kotlin is already niche anyway (despite being a good language), if the bar is about it "gaining mass adoption" in any grand way (comparable to Java for example).
If we mean mass adoption in a less grandiose way, Kotlin is doing alright, as do other new languages (Rust and Go for example).
>You lost 90% of them right there. They nearly all want to run for the hills. Java and the JVM have a great reputation in JVM circles (Java, Kotlin, Groovy, Scala, etc) but outside of that world people run as far away as they can from Java. It’s sad, but true. I’ve seen it multiple times in the last 20+ years of software development and I still see it to this day.
Yeah, not everybody is going to use Java. Not because "human nature", but because there are other options out there, people have investments in code/skills/time/libraries and so on, or prefer other languages.
One could just say the same argument about you not using Haskell for example, or C#, or whatever.
>We’ve been down the multiplatform road a number of times and it’s never become the panacea of development that proponents of each technological revolution claim it will be. All for the same reason I explained above … human nature.
Nope, the reason is all multiplatform offerings are crap, and have issues. Java never had a good native UI story. QT had its licensing baggage. C# was mostly a Windows thing, and Mono wasn't that encouraging. Electron is bloated. Flutter had a lot of bugs, and the language is changing a lot with each release. And so on.
>Not once has one of these platforms has taken the software world by storm. The one that has gotten the most traction is JavaScript, but it still has not taken over the world.
Like what, everybody using that and only that?
This is not "human nature" preventing it, but Javascript being good for particular things and not others, plus huge costs of migration where it could perhaps be a match (including rewriting existing code that works just fine with some other language, retraining costs in time and money, recreating libs that exist and do particular things in the other language's ecosystem, and so on).
>I’ve been saying for a long time now that we need to use the right tool for the right job.
Strange, for the most part TFA has been lamenting how not everybody rushed to adopt one single language or another, and how "bad human nature" prevents this.
Based on that, I don't think it's a good idea to try to go cross-platform for the business logic if you only have 2 platforms with less than 4 devs each. It's also not a good idea to pay mobile dev salary for mobile dev quality business logic code, C++/Rust/etc. will get you better code per money spent. Not to mention the possible issues that could arise with using niche tooling, like the KMP compiler.