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.
- 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
Rust
<?php declare(strict_types=1)😏 😁
🏃♂️💨
🏃♂️💨
The dash emoji. Always looks like a fart.
🦀
As others have said, Haskell and Rust are pretty great. A language that hasn’t been mentioned that I REALLY want to catch on, though, is Unison.
Honorable mention to my main driver lately: Purescript
Tell us more about unison
Hard to describe in one phrase other than to say:
NixOS is to Linux as Unison is to Haskell
Content-addressing used in the context of programming languages in the service of solving the problem of distributed systems and their inability to share code across time and space.
Haskell has a content-addressed module that was perhaps influenced by Unison.
Here’s an excellent interview with one of the authors of Unison:
C# is good too. If you havent heard of lobster you should look into it.
C# isn’t exactly compiled, at least not into machine language. It is transpiled into byte code that is run on a virtual machine that on turn is an interpreter/JIT-compiler.
Depending on why someone is asking for a compiled language that may or may not be a problem, because to the one writing the code it looks like a compiled language, but to the one running it it looks like an interpreted one.
It is compiled to bye code. Just to be clear transpiling is completely different. It is also not interpreted.
But ahead of time compilation is available now. So you can compile straight machine code.
The newer tiered JIT can actually give better performance than a traditional compiler as well.
Overall C# is an awesome language. If performance is absolutely critical you can use raw pointers and manual memory management, but obviously you lose safety then.
Not necessarily these days! With NativeAOT, C# can be compiled to machine code.
OCaml.
Sad I had to scroll to the end to see this.
Ocaml is brilliant and has the nicest type features. It’s almost like Haskell but more approachable imo.
As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.
I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.
What are your thoughts on this comparison? https://github.com/sidkshatriya/me/blob/master/007-My-Thoughts-on-OCaml-vs-Haskell-Rust-2023.md
Largely reasonable?
Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.
Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.
The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.
As someone who is not deep into type theory or functional programming, can you please explain why you mean by “ergonomic overloading”?
My understanding is that ocaml mitigates the need for type classes through its more advanced module system. So far I have been enjoying the use of OCaml modules, so I’m curious what exactly I’m missing out on, if any.
Thanks for taking the time to talk with me btw!
You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.
And then even once you’re using a module, you can’t overload a function name. See:
+vs+.. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).
Hands down, Rust 🦀
Rust.
Ada, hands down. Every time I go to learn Rust I’m disappointed by the lack of safety. I get that it’s miles ahead of C++, but that’s not much. I get that it strikes a much better balance than Ada (it’s not too hard to get it to compile) but it still leaves a lot to be desired in terms of safe interfacing. Plus it’s memory model is more complicated than it needs to be (though Ada’s secondary stack takes some getting used to).
I wonder if any other Ada devs have experience with rust and can make a better comparison?
I have done quite a bit of C, C++, Ada, and Pascal development. I recently got into Rust. I am still getting used to Rust, but it feels a bit like someone tried to apply Ada to C++. I like the modern development environment, but I am slower writing code than I would be in Ada or C++. The one feature of Ada that I really like and want other languages to adopt is the Rep spec. I write driver code and being able to easily and explicitly identify which symbol corresponds to which bit is really good.
I would use Ada or Spark in a heartbeat if there was an easy-to-use, mature cross-platform GUI library for it.
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.
Rust and Haskell (I think Haskell counts)
People don’t understand that JIT languages are still compiled, JIT literally describes when it’s compiled.
That said, F# and/or OCaml.
Kotlin is nice
