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 mean, yeah, valid point. JVM languages also have GraalVM for that purpose.
But I’m playing devil’s advocate here. 🙃
Arguably these don’t count, because they’re not the normal way of using these languages. Reflection isn’t properly supported in them, for example, so you may not be able to use certain libraries that you’d normally use.
These also still require a minimal runtime that’s baked into the binary, to handle garbage collection and such.
Personally, I enjoy fully compiled languages, because they generally don’t lock you into an ecosystem, i.e. you can use them to create a library which can be called from virtually any programming language, via the C ABI.
You cannot do that with a language that requires a (baked-in) runtime to run.
But yeah, obviously someone just specifying “compiled” probably won’t have all these expectations…
I don’t think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.
Yeah, that is why I prefixed that whole comment with “arguably”.
I feel like the definition of memory safety is currently evolving, because I do think data races should be considered a memory safety issue.
You’ve got a portion of memory and access to it can be done wrongly, if the programmer isn’t careful. That’s what memory safety is supposed to prevent.
Rust prevents that by blocking you from passing a pointer for the same section of memory into different threads, unless you use a mutex or similar.
And because Rust sets a new safety standard, I feel like we’ll not refer to Java and such as “memory-safe” in twenty years, much like you wouldn’t call a car from the 90s particularly safe, even though it was at the time.
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.
C# has native compilation capability, thanks to Native AOT
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
I mean, yeah, valid point. JVM languages also have GraalVM for that purpose.
But I’m playing devil’s advocate here. 🙃
Arguably these don’t count, because they’re not the normal way of using these languages. Reflection isn’t properly supported in them, for example, so you may not be able to use certain libraries that you’d normally use.
These also still require a minimal runtime that’s baked into the binary, to handle garbage collection and such.
Personally, I enjoy fully compiled languages, because they generally don’t lock you into an ecosystem, i.e. you can use them to create a library which can be called from virtually any programming language, via the C ABI.
You cannot do that with a language that requires a (baked-in) runtime to run.
But yeah, obviously someone just specifying “compiled” probably won’t have all these expectations…
How are they not memory safe in a multi-threadded context?
There’s nothing to prevent data races. I myself have fallen into the trap of using the same list from multiple threads.
I don’t think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.
Yeah, that is why I prefixed that whole comment with “arguably”.
I feel like the definition of memory safety is currently evolving, because I do think data races should be considered a memory safety issue.
You’ve got a portion of memory and access to it can be done wrongly, if the programmer isn’t careful. That’s what memory safety is supposed to prevent.
Rust prevents that by blocking you from passing a pointer for the same section of memory into different threads, unless you use a mutex or similar.
And because Rust sets a new safety standard, I feel like we’ll not refer to Java and such as “memory-safe” in twenty years, much like you wouldn’t call a car from the 90s particularly safe, even though it was at the time.
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.
The question mine as well be “what is your favorite compiled language?”. There is a lot of overlap between the possible answers.