I migrated some code from Javascript to Typescript and then from Java to Kotlin. What helped in both cases was that I was able to go file by file. I didn't have to rewrite all my software all at once. That's something that is very disruptive and impractical in software that is actively used (i.e. all useful software).
With Typescript, all you have to do is rename your .js file to a .ts file and then you can start addressing the warnings. With Kotlin, there's a convenient but imperfect Java to Kotlin converter that ships with Intellij. It will get you 95% there but expect to fix a few things. Basically you modify your build to add the Kotlin compiler and then you start converting files. In my case I started with some simple tests that weren't on the critical path to anything. When that worked really well, I quickly got in a mode where any Java file I worked on was converted to Kotlin. Same with Typescript. Both code bases rapidly shifted to being mostly Kotlin/Typescript but with lots of remaining Java and Javascript.
A big advantage of incremental approaches like this is that you get to focus your attention on the most critical parts of the software without really interrupting your development process. The critical parts of your software are those parts that you are actually working on regularly to fix bugs or add features. Another advantage is that you slowly get used to the new language. This takes time. In my case I had to unlearn about 20 years of using Java. Optional is not a thing in Kotlin for example. It's 100% redundant Java clutter. And finally, you organically convert most code that matters in a relatively short amount of time. So, you make rapid progress and make a big impact. Which is always a good thing when learning a new thing.
So, I can see the value of Carbon here. Start dropping it into existing C++ code bases. Upgrade files as you work on the code anyway. Put some focus on the typical hotspots where you were fixing lots of bugs anyway. This way, things improve rapidly and the last 20% of the code is the least important part of the code generally. You get diminishing returns from upgrading it. It will be nice to see what happens when this is ready for production usage.
Like with Kotlin and Typescript, expect this to stay controversial with some people. Stuff like this never fully converts the target audience. I know lots of people that prefer Java and Javascript. Mostly for irrational reasons IMHO. But they do. It all boils down to people just being a bit change resistant. And the C++ crowd is very conservative.
I will consider Kotlin outside Android, when it becomes relevant for JVM design, being taken into account by all major JVM implementations and JEP proposals, instead of something imposed by an OS vendor, stiffing Java support on purpose.
Guest languages always end up eventually going down their own path.
Not even C++ developed alongside C and UNIX, managed to take over UNIX clones, or industry standards for OS and graphics APIs.
Typescript relevance might wither away when JavaScript gains type annotations, it is after all only a nice linting tool.
Despite all WebAssembly craziness, JavaScript still rules the browser and edge gateways.
It is and you are being very defensive here. Which suggests to me that this isn't the first time you've been challenged on this front.
Dismissing things as "guest" languages maybe steps over the advantages these languages bring. If you had some rational reasons I'd take you more seriously. But you clearly don't. Using big words like "industry standards" doesn't really add to the argument.
> I will consider Kotlin outside Android
Funnily enough the only place I don't use Kotlin is Android. I never did much Android development. I've been using it since 2017 for server side development and the last five years also for browser development (via kotlin-js). It's actually replaced typescript for me. I do a lot of Kotlin multiplatform at this point. I don't recommend this to everyone. But it does work quite well for me as a better Typescript. It still cross compiles to Javascript of course. And lately to WASM if you want to. But the point is, Kotlin is not just a JVM language anymore. People do IOS native development with Kotlin now. With bi-directional swift integration, native libraries, and all the rest.
What things are for and aren't is mostly a mental block on your side. C++ and Typescript are widely used at this point.
> might wither away when JavaScript gains type annotations
If that's so beneficial, you could have been using Typescript for the last ten years.
Big words matter, because there is a whole list of megacorps that rather keep using Java alongside C and C++ to implement their JVMs.
If Kotlin is so great where is the KVM taking over the world, outside ART, when no one is forcing its adoption like on Android?
Actually, is Kotlin Native finally good enough for JetBrains to implement a KVM, without having to rely in something writen in Java with all the related flaws?
I use Typescript where it is imposed upon myself, like Angular and Next.js, when I can have my way of Web development, it is plain Spring MVC or ASP.NET MVC with vanilajs.
My day to day JVM guest language is two decades old at this point and it is remarkably similar to Java and yet none of the latest Java releases have done anything remotely interesting enough that they would make me go back to Java ever.
With Typescript, all you have to do is rename your .js file to a .ts file and then you can start addressing the warnings. With Kotlin, there's a convenient but imperfect Java to Kotlin converter that ships with Intellij. It will get you 95% there but expect to fix a few things. Basically you modify your build to add the Kotlin compiler and then you start converting files. In my case I started with some simple tests that weren't on the critical path to anything. When that worked really well, I quickly got in a mode where any Java file I worked on was converted to Kotlin. Same with Typescript. Both code bases rapidly shifted to being mostly Kotlin/Typescript but with lots of remaining Java and Javascript.
A big advantage of incremental approaches like this is that you get to focus your attention on the most critical parts of the software without really interrupting your development process. The critical parts of your software are those parts that you are actually working on regularly to fix bugs or add features. Another advantage is that you slowly get used to the new language. This takes time. In my case I had to unlearn about 20 years of using Java. Optional is not a thing in Kotlin for example. It's 100% redundant Java clutter. And finally, you organically convert most code that matters in a relatively short amount of time. So, you make rapid progress and make a big impact. Which is always a good thing when learning a new thing.
So, I can see the value of Carbon here. Start dropping it into existing C++ code bases. Upgrade files as you work on the code anyway. Put some focus on the typical hotspots where you were fixing lots of bugs anyway. This way, things improve rapidly and the last 20% of the code is the least important part of the code generally. You get diminishing returns from upgrading it. It will be nice to see what happens when this is ready for production usage.
Like with Kotlin and Typescript, expect this to stay controversial with some people. Stuff like this never fully converts the target audience. I know lots of people that prefer Java and Javascript. Mostly for irrational reasons IMHO. But they do. It all boils down to people just being a bit change resistant. And the C++ crowd is very conservative.