41–50 of 80 posts
Earlier quoted context omitted.
With the small difference that Circle can use the complete language at compile time, constexpr is still far from it, and also gave birth to constinit and consteval.
Jai gets to use the entire language. constexpr in C++ 11 is indeed very limited, arguably even more than Rust's const functions today.
Earlier quoted context omitted.
Scala and F# are safer than Rust since they're on a VM.
>> Scala and F# are safer than Rust since they're on a VM. 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.
>simpler by disabling features that contribute to complexity, like multiple inheritance and function overloading. Seeing function overloading show up surprises me. The only thing I can think of is having different semantics between different overloads, but removing overloads doesn't remove the issue. You just now have a poorly named function that isn't an overload.
I think the contrast between string contains in Rust and C++ is illustrative. Overloading means you only get whatever parameter types the stdlib provides in C++.
Earlier quoted context omitted.
Jai gets to use the entire language. constexpr in C++ 11 is indeed very limited, arguably even more than Rust's const functions today.
Except that almost no one has access to Jai.
Earlier quoted context omitted.
Yes, but so? When they can implement a feature in a forwards compatible way they do, when they can't, they don't and it's caveated as such. That's why nullable types and other Kotlin specific type stuff are encoded using annotations. 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…
It is only forward compatible, is stuck in decisions when Java 8 was current, there is no roadmap to keep the language in sync wiht the underlying progress of the platform as Kotlin tries to be everywhere. 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!
Earlier quoted context omitted.
>> Scala and F# are safer than Rust since they're on a VM. 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.
In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages . 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…
From all possible wannabe be replacements for C++ that poped up in 2022, Circle is definitely the one that has the most going for it. 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 beh…
This lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?
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.
Earlier quoted context omitted.
In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages . 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…
It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.
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.
Earlier quoted context omitted.
It is only forward compatible, is stuck in decisions when Java 8 was current, there is no roadmap to keep the language in sync wiht the underlying progress of the platform as Kotlin tries to be everywhere. 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.
Loom doesn't need to pose any issues for Kotlin. If you target only the JVM, you just use virtual threads directly and ignore the coroutines stuff. If you target other runtimes you use them. If you use a KMP library, just surround stuff marked async with runBlocking {}. 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.…
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?