Elm, which is the loveliest language ever.
But I’m not sure if compiles to javascript counts as compiled, in which case haskell, which is considerably less lovely but still good.
Roc isn’t finished, but it might turn out lovely, I don’t know.
Transpiles :)
D
I started learning Go about 3 months ago and it quickly became one of my favorite languages. It feels like C with a bunch of Python niceties thrown in. And performance isn’t super critical in my work so being garbage collected is fine with me.
C on Morello (or any other capability machine).
C is memory safe if you program it well enough, so I guess C
every single language (except Vlang of course) is memory safe if you program it perfectly.
Very, very few humans are capable of doing that, especially with C.
C? Memory safe? HAHAHAHA
落ち着いてください
deleted by creator
Please work on your Japanese.
deleted by creator
Every car has airbags if you drive well enough. Right?
You can still make stupid mistakes in Rust. It may make it harder to make the most common mistakes, but pretending the guardrails are prevent any type of mistake is asking for a problem to happen.
The only one pretending mistakes can’t happen is the person I replied to. Mistakes definitely can happen and no programming language is fool proof.
Continuing my car analogy, would you rather drive a car with airbags and seatbelts or one without them? Of course you can still have a fatal accident, but it’s nice to have safety features that make it as unlikely as possible.
Lol. The people downvoting your comment need to get good.
Skill issue.
Gleam?
https://gleam.run/I dunno it looks well designed but I dunno why I would use it instead of Rust.
Honest question, what would make you pick Gleam over Elixir? Both seem to have significant overlap
Isn’t Elixer dynamically typed?
Oh, I forgot that detail, makes sense. Does Gleam already have something equivalent to Phoenix for elixir?
Rust.
purescript if you count “compile to js” as compiled.
Otherwise Haskell
That’s transpiling, not compiling. Compiling is usually meant as “directly to machine code”, but I am yet to find an “official definition”.
There is no official definition, in part because there isn’t any formal way to define the term that satisfies our intuition.
Most treatments will handle “transpiling” as a special case of “compiling” and some will even handle decompilation as a special case where the object language is higher level than the source. Of course, even defining “higher level” can be quite hard.
Plenty of languages “compile to C” and I see no issue with saying something “compiles to js,” especially given that js mostly lacks features of purescript rather than the other way around.
transpiling is just a type of compiling. compiling in no terms means ‘directly to machine code’.
Scala is the the first I used and I like it a lot. If I had more time I’d love to give ocaml a decent try but I don’t think I can get into it these days.
C++, with some Skill
/s
but seriously, I don’t know any language with a good, C/Cpp-like Syntax (so not Rust), with a good compiler (again not Rust). So I’m sticking to Cpp.
What’s so bad about the Rust compiler? I know it’s slow, but given all the analysis it’s doing, it makes sense. And, from my own experience, setting correct optimization levels for dependencies along with a good linker makes incremental builds plenty fast.
You should check out zig, its compiler can even be used for c/c++. If you have time to listen to an interview, this developer voices interview on zig explains some of the advantages of this: https://www.youtube.com/watch?v=5_oqWE9otaE&t=3970s
Thinking about zig for some stuff.
Mostly because those rusticles are pissing me off.
I don’t know what you are talking about?
Rust is such an amazing language, it’s so safe and clean and beautiful and simple and clear to read and such wow community that are making amazing crates for cargo because cargo is so cool I like it so much so easy to…
Oh, and your fav lang sux alot!1 lolololllll
“Hey Linus, why haven’t you rewritten the kernel in rust yet, you idiot?!?! Don’t you realize you’re missing the future, old man!?!?”
Nim. Small compiler, small executables, easy to understand (except the macros, I still can’t get my head around them).
FreePascal. Yeah yeah, Pascal’s dead, etc etc, but it being so verbose and strict certainly help programmers (or at least me) keeping things somewhat tidy.
Also shoutout to V
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, I like subleq.
- 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).
Subleq is the obvious winner in my mind.
- compiler is extremely fast, faster even than
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.
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.There’s a reason why data races aren’t considered a memory safety issue, because we have a concept that deals with concurrency issues - thread safety.
Also for all it’s faults, thread and memory safety in java aren’t issues. In fact java’s concurrent data structures are unmatched in any other programming language. You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.
You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.
In Java it isn’t always clear when something crosses a thread boundary and when it doesn’t. In Rust, it is very explicit when you’re opting into using
unsafe, so I think that’s a very clear distinction.Java provides classes for thread safe programming, but the language isn’t thread safe. Just like C++ provides containers for improved memory safety, and yet the language isn’t memory safe.
The distinction lies between what’s available in the standard library, and what the language enforces.
Oof, I guess, you’re not wrong that we’ve defined data races to be the separate issue of thread safety, but I am really not a fan of that separation.
IMHO you cannot cleanly solve thread safety without also extending that solution to the memory safety side.
Having only one accessor for a portion of memory should just be the n=1 case of having n accessors. It should not be the other way around, i.e. that multiple accessors are the special case. That just leads you to building two different solutions, and to thread safety being opt-in.That’s also the major issue I have with Java’s solution.
If you know what you’re doing, then it’s no problem. But if you’ve got a junior hacking away, or you’re not paying enough attention, or you just don’t realize that a function call will take your parameter across thread boundaries, then you’re fucked.
Well, unless you make everything immutable and always clone it, which is what we generally end up doing.
Even though they are not what people mean when they say “memory-safe”, it is technically a kind of memory safety. It is unsafe to modify non-mutexed/non-atomic memory that another thread might be modifying at the same time.
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)
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…
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.
Modern C++ does use references, which can also reference memory that is no longer available. Avoiding raw pointers isn’t enough to be memory safe.
The question mine as well be “what is your favorite compiled language?”. There is a lot of overlap between the possible answers.
Rust
Julia
I wouldn’t consider Julia statically-typed; am I wrong?
It’s actually optionally-typed. But if you’re liberal with type annotations you can treat it as statically typed.
That is a very specific subset
Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)
Garbage collection is still allowed, and technically JIT languages are still compiled so it really isn’t that restrictive
Java, the language so good you compile it twice!
