I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it.
To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.
There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.
I‘m in the process of migrating Kotlin code back to Java in our product. My experiment with Kotlin is over and I‘m sticking 100% with Java. I like writing Kotlin, but I dislike reading Kotlin code.
First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade".
The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Kotlin's native backend and GraalVM.
The widening gap is not at all moving Kotlin further away from Java developers, but is just increasing the reasons to migrate. It is crucially not making interoperability with existing, legacy Java harder, just giving you more toys. Stuff like suspend functions vs. virtual threads only affects decision making in new application code, and you can for all intents and purposes use either depending on whether you're writing new Kotlin libs for a legacy Java app or a Kotlin app using legacy Java libs.
The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
Plus, considering that Android apps were responsible for a very significant portion of actively developed Java (I would assume quite a loand has with Android having gone full Kotlin, a quite significant portion of Java developers will either already have migrated or soon be migrating to follow suit. This will over time affect a quite significant portion of the available skill pool for hiring, which will add additional pressure on enterprise.
There will always be Java, but I'd expect a significant portion of actively developed applications (as opposed to maintenance-mode only applications) to slowly migrate to either Kotlin or something else entirely.
I think you're widely mistaken if you don't think Java is a platform. The VM and language are intertwined. The VM explicitly knows about things like records, language constructs, and idioms from Java. Java sets the direction of the VM, not Kotlin.
JVM does not know about Java, it knows about an IR that Java, Kotlin, Scala, Closure, Groovy, etc. all target. Java as a language also doesn't know about JVM, as it commonly targets things that are not the JVM, whether that is Dalvik, Graal or something else entirely.
That the JVM and IR has features to help the Java compiler generate better output is obvious but not really relevant. Modern CPUs also have instructions to help C compiles generate better code, but that doesn't make them C platforms. It's just that implementation details.
So no, Java is not a platform. It is a language that sometimes runs on the JVM together with many other large and quite influential languages.
You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
> The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable (...)
Yes, in the sense that Java exists and Kotlin by design piggybacks on the JVM.
> The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
This analysis is very superficial and fails to identify any of the real world arguments to switch from C. For example, Microsoft outright strangled C by wasting many years refusing to support any standard beyond C89, in spite of being directly involved in it's drafts. This was a major contribution to address any of the pain points and DX shortcomings. Compare the evolution of C and C++ during that time period, and we see C++ going through the same path in the C++0x days to then recover spectacularly once C++11 got unstuck.
> You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
Java runs on several things that are not the JVM. Android does not use JVM to run Java, and even Oracle is pushing something that is not the JVM.
At the same time, JVM runs many things that are not Java.
If you are somehow implying along the lines of JVM only got initially authored because Java, then that is nothing but a historical fact of little relevance from the early days of the language. If not even Oracle considers Java and JVM one thing - and by virtue of Graal they don't - then it simply isn't as such.
> This analysis is very superficial and fails to identify any of the real world arguments to switch from C
You misread - what you quoted was not an analysis of why the migrations happen. It was a parallel, underlining that migrations do happen in spite of obvious feature differences (and sometimes, because of such differences).
Yeah, Kotlin is stuck in an uncomfortable position, like F# is in the .NET world. It has pioneered several important features, but now the big brother has implemented them slightly differently and people demand interop from you.
At least Kotlin can theoretically retreat to Android.
I did a decent amount of AoC this year in F#. I felt it was more verbose than I would have expected. There were a lot of things that helped brevity; I really liked type definitions, unless I was using OO features where it was extremely verbose to define members. I also really didn't like having to to Seq.map or List.filter for everything instead of just calling methods off of the seq or list.
From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.
> As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this)
does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language.
After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there was an absolute proven need to switch languages, I'd mandate only a single language for our (back end) stack. The cost of supporting different languages is just too high.
I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
> I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods.
This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level.
This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.
Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
> I think this is because of the gap in its target market
Surely that gap has been filled for at least a decade, even if only by Rust itself?
Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being different tools for different jobs.
> Go was originally pitched as a C or C++ replacement
It was originally imagined that it would replace C++ for network servers at Google. The servers part was made abundantly clear. In fact, the team behind it expressed quite a lot of surprise that it eventually found a home doing other things as well.
> you don't see Go ported to microcontrollers for instance.
> Surely that gap has been filled for at least a decade, even if only by Rust itself?
I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one.
> the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin
What, exactly, does distance mean here?
The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.
Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.
How I interpret his comment about the distance:
The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go (in the similar use-cases) or from Java to Kotlin.
Another argument offered for Rust is that it's high-level enough that you can also use it for the web (see how many web frameworks it has). So I think that Rust's proponents see it as this universal language that could be good for everything.
> The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go
Ten years ago the memory model was a compelling benefit, sure, but nowadays we have Fil-C, that C++ static analyzer posted here yesterday, etc. There is some remaining marginal benefit that C and C++ still haven't quite caught up with yet, but is that significantly smaller and continually shrinking gap sufficient to explain things as they stand today?
You are right that the aforementioned assumption did not play out in the end. It turns out that C++ developers did, in fact, choose C++ because of C++ and would have never selected Python even if Python was the fastest language out there. Although, funnily enough, a "faster Python" ended up being appealing to Python developers so Go does ultimately have the same story, except around Python (and Ruby) instead of C++.
> Another argument offered for Rust is that it's high-level enough that you can also use it for the web
It was able to do that ten years ago just as well. That doesn't really explain things either.
>To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust.
What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.
Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?
Kotlin's Niche was to replace LEGACY Java with something that builds for older versions of Java but also gives you features and ergonomics not available for those features. There's a ton of super legacy Java out there.
Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.
Good point. Many of these other languages claim to be "successors", but are really C++ alternatives, that can have very different programming philosophies, goals, and use cases.
> I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu
I spent five years working at a company (Materialize) whose main product is entirely in Rust. Since then I work at a company (Polar Signals) where sadly I have to use C and Go, but the main backend storage layer is in Rust. And several of our customers use Rust and it would be a show-stopping bug for them if our product stopped working on Rust codebases.
Besides all that, plenty of companies you’ve heard of are now writing large amounts of new code in Rust — most notably Meta and Amazon. Large parts of Firefox are in Rust and have been for years.
> I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues.
The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs.
The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.
Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
technically, Kotlin can use VirtualThreads like it can use any other Java Api
(when being compiled to JVM bytecode).[1]
If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads.
So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines).
What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions!
My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)
Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.