With no context, this could be an honest attempt to learn about different tools, a thinly veiled set-up to promote a specific language, or an attempt to stir up drama. I can’t tell which.
It’s curious how such specific conditions are embedded into the question with no explanation of why, yet “memory safe” is included among them without specifying what kind of memory safety.
Yeah, arguably the only answer to this question is Rust.
Java/C#/etc. are not fully compiled (you do have a compilation step, but then also an interpretation step). And while Java/C#/etc. are memory-safe in a single-threaded context, they’re not in a multi-threaded context.
I don’t know much about C++, but how would that do memory safety in a multi-threaded context? In Rust, that’s one of the things resolved by ownership/borrowing…
Or are you saying arguably, as in you could argue the definition of the categories to be less strict, allowing C++ as well as Java/C#/etc. to match it?
Because you would be using std::shared_ptr<> rather than a raw pointer, which will automatically deallocate the memory when a shared point leaves the scope in the last place that it’s used in. Along with std::atmoic<shared_ptr> implements static functions that can let you acquire locks and behave like having a mutex.
Now this isn’t enforced at the compiler level, mostly due to backwards compatibility reasons, but if you’re writing modern c++ properly you wouldn’t run into memory safety issues. If you consider that stretching the definition then I guess I am.
Granted rust does a much better job of enforcing these things as it’s unburdened by decades of history and backwards compatibility.
Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases
Hmm, that sounds quite interesting. But because I’ve had to rebut that for everyone else that responded: Is it opt-in?
I guess, I would be fine with opt-in for the actor pattern, since you either do actors in your whole codebase or you don’t, but otherwise, opt-in often defeats the point of safety measures…
It’s opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.
Agree that opt-in sort of defeats the point, but in practice it’s a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)
compiler is extremely fast, faster even than tinycc
strongly statically typed: all values are ints. Since it’s all of them, you don’t even need to write it!
memory safe: the entire (virtual) address space is guaranteed to be accessible at all times so there’s no way to leak any of it (can’t release it anyway) or to segfault (it’s all accessible).
With no context, this could be an honest attempt to learn about different tools, a thinly veiled set-up to promote a specific language, or an attempt to stir up drama. I can’t tell which.
It’s curious how such specific conditions are embedded into the question with no explanation of why, yet “memory safe” is included among them without specifying what kind of memory safety.
Yeah, arguably the only answer to this question is Rust.
Java/C#/etc. are not fully compiled (you do have a compilation step, but then also an interpretation step). And while Java/C#/etc. are memory-safe in a single-threaded context, they’re not in a multi-threaded context.
Arguably modern c++ ( aka if you don’t use raw pointers), fits all categories.
I don’t know much about C++, but how would that do memory safety in a multi-threaded context? In Rust, that’s one of the things resolved by ownership/borrowing…
Or are you saying arguably, as in you could argue the definition of the categories to be less strict, allowing C++ as well as Java/C#/etc. to match it?
Because you would be using std::shared_ptr<> rather than a raw pointer, which will automatically deallocate the memory when a shared point leaves the scope in the last place that it’s used in. Along with std::atmoic<shared_ptr> implements static functions that can let you acquire locks and behave like having a mutex.
Now this isn’t enforced at the compiler level, mostly due to backwards compatibility reasons, but if you’re writing modern c++ properly you wouldn’t run into memory safety issues. If you consider that stretching the definition then I guess I am.
Granted rust does a much better job of enforcing these things as it’s unburdened by decades of history and backwards compatibility.
C# has native compilation capability, thanks to Native AOT
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
Swift fits the description too
Most people would consider it so, but it actually does not either fulfill the argument I posed there: https://forums.swift.org/t/what-language-is-more-memory-safe-swift-or-rust/31987
Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases
Hmm, that sounds quite interesting. But because I’ve had to rebut that for everyone else that responded: Is it opt-in?
I guess, I would be fine with opt-in for the actor pattern, since you either do actors in your whole codebase or you don’t, but otherwise, opt-in often defeats the point of safety measures…
It’s opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.
Agree that opt-in sort of defeats the point, but in practice it’s a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)
Yeah, I like subleq.
tinyccints. Since it’s all of them, you don’t even need to write it!Subleq is the obvious winner in my mind.