Everything else requires rewriting everything, and they can only support a limited subset of C++ features, so if the goal is full compatibility with existing code they aren't going to achieve it anyway.
For full rewrites, we already have enough alternatives with more maturity years behind them.
I'm more interested in Val than the rest, but, Val isn't really a C++ replacement (in terms of syntax, at least), it's a language that offers C++ interop. To quote an old joke 'How do you get to Dublin? Well, firstly, I wouldn't start here'. I'm not sure whether any new language in 2023 should start with C++ interop as one of its main goals.
Since when? Last time I looked C++ had almost a hundred keywords. C++ 20 added a bunch including "requires" and "concept" - both ordinary English words which oops, too bad now your software is incompatible because it used the wrong identifier.
Until the likes of LLVM, GCC, CUDA, V8 and co get rewritten into something else, improving existing C++ codebases is still an issue.
It's the same strategy here. Carbon is (was?) also intended to compile to the C++ ABI and so does Circle, that's why it says it doesn't run on Windows (commercially a huge error. many of the biggest C++ codebases that could benefit are running on Windows like game engines, and Windows doesn't impose a specific C++ ABI anyway). But there's no way to take existing code files and switch them to the new language in Carbon, at least not yet. Kotlin was carefully designed at every step of the way such that every Java program can be expressed in Kotlin without change, even if that meant compromising on some things. Seems like the Carbon guys are being sucked up by the lure of safetyism and just want to make their own version of Rust that happens to compile to the Itanium C++ ABI.
Loom, value types, SIMD, Panama,... are all features that start to be an issue to expose as Kotlin features.
It is working on Android, because Google is pushing it as Java 8 => Kotlin, not as Java XYZ <=> Kotlin.
SIMD/Panama stuff is just new APIs. No problem there. Kotlin maybe even wins because Panama is super verbose.
JVM value types seems never to arrive. Stuck in dev hell for years maybe. If/when it ever does see the light of day, Kotlin has value types and so it can just be compiled to a JVM value type to get the benefits. You'd need to opt in to an ABI break but no big deal.
So the binary compatibility part hardly seems an issue even looking forward a long way into the future.
It's probably harder for C++ because the language there seems to evolve quicker than Java!
KMP taken to the extreme, is better for Kotlin just to do its own thing with Kotlin/Native, except it is so behind that JetBrains is using Rust instead for Fleet services.
Java is expected to have language level support for some of those features, will Kotlin catch up?
However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I believe would benefit immensely from a rewrite in a safer language, even if it's not as safe as Rust (or Scala, or F#, etc.)
Firefox and Chromium have already paid the entry price for piecewise refactoring into Rust, so they're probably not the best candidates. But there are many other examples that undoubtedly are, e.g. LLVM.
Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
Do you have any evidence to back up your claim?
Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo...
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr
Programming languages running on VM is not a safety guarantee.
The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the lang's own semantics.
But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language.
To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer.
The whole argument about "saftey" in the sense Rust addresses is between languages of "manual allocation". To imagine that any of these language is "safer", is to have misunderstood a great deal. Rust is about enabling an otherwise C-programmer to limit the impact of manual memory handling, it is *not* to prevent eg,. use-after-free errors in javascript. Since there are no such errors by construction.
But, Safe Rust also chooses to construct safety that those GC'd languages don't have.
The reason Javascript doesn't have data races for example is that it doesn't have concurrency - can't have a race with only one runner. Java does have data races (with limited but still unsettling consequences), Go's data races are really bad, like actual Undefined Behaviour bad in some cases. Whereas Safe Rust doesn't have data races - you can write concurrent Safe Rust but you can't write a data race.
The difference you're grappling for probably feels intuitively like it should exist, but I assure you it does not.
I will resolve this, simply, by saying whatever advertisement Rust makes for itself, is better made by any "dynamic" language.
And if we're inclined to trade PR against PR, Rust looses. Managed memory has better PR.
And so those repeating the Rust agitprop against managed languages are simply "NPCs for the wrong ideology".
Theoretically, memory-safety between Rust and managed languages is equivalent.
However, memory-safe languages (i.e. not Managed C++) running on a memory-safe VM have one more layer of defense in depth than Rust. This matters in case there is a bug in the compiler or any of the dependencies. Additional layers may include, for instance, Unix and containers.
"dynamic" languages, though? That's entirely orthogonal to memory-safety and not very good for general software safety.
Of course:
- this doesn't cross library boundaries;
- this assumes robust enough static analysis, which is not possible in the general case, since templates are non-decidable in the general case – so you need to restrict your new language to more reasonable semantics;
- let's not even get started on the interaction between templates and C-style macros – at some point, you need to throw the towel.
Successful piecemeal rewrites will result in gradual improvement, so if you don't see that gradual improvement over time, something is very wrong with the project.