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.
- 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
The question mine as well be “what is your favorite compiled language?”. There is a lot of overlap between the possible answers.
Gleam?
https://gleam.run/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?
I dunno it looks well designed but I dunno why I would use it instead of Rust.
Rust
That is a very specific subset
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!
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.
It is compiled into bytecode. A transpiler translates to another programming language with the same level of abstraction. A compiler translates into a level that is nearer to or 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.
Scala 3 native. If the compiler was faster I’d be even happier. Curious to try Ada
Rust and Haskell (I think Haskell counts)
Swift
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
People don’t understand that JIT languages are still compiled, JIT literally describes when it’s compiled.
That said, F# and/or OCaml.
Crystal, but only because I’m a full time Ruby on Rails (and sometimes Hanami!) programmer.
It’s fantastic, and I had an excuse to use it at work when we needed to gather PHP Watchdog logs from a MySQL database and format, output them to STDOUT in a Kubernetes environment. (This was necessary for our log monitoring tools expecting data in a standard way, AKA not connecting to a database. 🤦♂️)
I know there are perhaps better options out there (Go, Rust, etc.) but from a Rubyist’s point of view Crystal gives you that “flow” from working in a beautiful language but with the performance boost of compiled software.
I’m anxiously waiting for Crystal to be able to compile for Windows so game development with it can get a kickstart
I’m kind of sad to say that I don’t think it’s going to reach the adoption level of Ruby but I hope I’m wrong.
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’.
