I am looking for memory-safe languages that can be used for systems/graphics programming. I love Rust, but it often feels like too massive a language with too much stuff going on. Is there a language like C, which is simpler (obviously without all the UB and other problems)?
This is an especially hard ask, given how useful the FP-like features of Rust are, and I find it almost impossible to live without them. Basically, I am looking for a middle ground between C/Zig and Rust.
One such language I have found is Austral[0]. What other such languages are there?
[0] https://austral-lang.org/
¹https://0xc0ffee.netlify.app/osdev
I, too, have been looking for a unicorn systems programming language, but it doesn't exit yet. Here's what I looked at so far (only languages that don't rely on a GC):
- C: lots of UB, less safe (memory- and type-wise)
- C++: too complex, not a big fan of OO
- Rust: too complex, gets in the way when writing mostly unsafe kernel code
- Zig: Good, but syntax is too noisy; lacks interfaces/dynamic dispatch
- Swift: Doesn't have a good bare metal story
- D: Seems interesting, I may be looking at it (although need to use betterC mode, i.e. not all language features)
- Odin: Game programming focused, small but growing community
- Ada: Strong candidate, but it has too much ceremony
- Pony: I like the capabilities model, but tiny community
- Hare: Also tiny community, lacks polymorphism
- Hylo (Val): Experimental (mutable value semantics), too immature
- Vale: Experimental (regional memory management), seems stalled
- V: Good candidate, but mixed reviews on its claims vs. reality
- Austral: Experimental (linear types), tiny community, not much progress
- Jakt: Built for Serenity OS, not sure if it's getting enough attention
- Jai: Focused on game programming, good reviews, but currently closed source (beta)
- Mojo: (Python-like) Seems very interesting and I'd give it a try, but too focused on GPU/parallel programming; also too early for adoption
On a side note and coming from high-level languages, D is the easiest to learn IMHO, as it is very dev-friendly, mature enough and has a good interoperability with C libraries.
I considered for a long time nim for its syntax and "low-levelness", but my lack of knowledge in low-level languages made the learning curve too much steep for me. I think I'll switch to it when I'll have more experience.
A programming language is always going to make some kind of compromise; better at some things, worse at others.
Simplicity/power and safety pull the design in different directions.
https://saaramar.github.io/iBoot_firebloom/
> Beautiful is better than ugly.
> Explicit is better than implicit.
> Simple is better than complex.
> Readability counts.
What really sets Zig apart from the usual suspects (C, C++, Rust) is that it has first class compile-time reflection capabilities built into the language (comptime, @field, @typeInfo, etc.) rather than bolted on as macros or templates.
Funny you make that analogy. I remember back when the two contending C alternatives were Zig and Nim, with Nim being syntactically almost a Python clone.
It seems Nim has gone the way of Crystal (Ruby version of Nim) and is just kind of there but mostly forgotten and doomed to be abandoned unless it finds a niche.
> What sets Zig apart is compile-time
I see this claim a lot, but I'm not sure. I think it's the fact that Zig is more or less still C syntax and semantics, just... fixed. The way it does comptime does seem better than how other languages do it, but I haven't actually used it, much less for long enough to judge it properly.
But at the same time, I'm pretty sure that smaller/simpler is going to mean less safe.
https://github.com/AdaCore/spark2014
There's also this paper, "Memory Safety in Ada, SPARK, and Rust"
https://www.adacore.com/papers/memory-safety-in-ada-spark-an...
https://blog.adacore.com/should-i-choose-ada-spark-or-rust-o...
I absolutely adore Ada [1], but the Pascal-syntax isn't for everyone.
I haven't used it yet, but have been hearing rumblings about Odin [2] a fair bit in these kinds of discussions. I tend to avoid too many symbol-heavy langs, but it's probably still less than Rust (I use a screenreader half the time).
[0] https://vlang.io/
[1] https://ada-lang.io/
[2] https://odin-lang.org/
Not saying you in particular, but it's weird, how too many won't tolerate running into some problems when they knowingly chose something still in beta. "Oh my, there was an issue with the beta software I'm using".
Maybe why JBlow refuses to release his beta to the public. Actually, it can be a good thing for the language, by people filing bug reports (so they can get fixed) or to do a PR (if they are at that level). That way, the language has more vetting, from more eyes on it.
(I have no idea what the current state is)
As for concerns... The main developer is a concern. Hard to trust them to support the language well, with some of the... Well, tantrums. This isn't aimed at a personal attack. But it is very hard to describe their responses in another manner.
This [0] thread on HN covers some of all of the above.
But, probably also important to point out that V and its drama have had dang threaten to ban the topic altogether [1]. There's a lot of drama.
[0] https://news.ycombinator.com/item?id=39492680
[1] https://news.ycombinator.com/item?id=37335249
See this article and the discussions, and if you’re so inclined follow along links in that thread from last time that show folks from the vlang team flaming all over HN.
> But I've had a few issues with the safety aspects of the language. Breaking through the checker isn't that difficult.
What do you mean? Can you "break through the checker" outside of unsafe blocks?
But there was a time where autofree was just a compiler flag and wasn't actually implemented, even though the author claimed that it was.
[0] https://github.com/vlang/v/issues/24271
[1] https://github.com/vlang/v/issues/23509
[1]: https://justinas.org/the-bizarre-world-of-v#memory-unmanagem...
Better to review more balanced and neutral takes on V[1][2], where the reviewers are not just stirring up drama with their community or funneling traffic to their site.
[0] https://github.com/vlang/vinix
[1] https://www.youtube.com/watch?v=puy77WfM1Tg (Anthony GG reviews Vlang)
[2] https://www.youtube.com/watch?v=dmVKerNY-fQ (Mike Shah reviews Vlang)
Dead Comment
What intrigues me quite a bit relative to the main topic of the HN thread is Low[0]
> Low
is not only a language subset, but also a set of F* libraries that model a curated set of C features: the C memory model, stack- and heap-allocated arrays, machine integers, C string literals, and a few system-level functions from the C standard library. Writing in Low, the programmer enjoys the full power of F for proofs and specifications. At compile-time, proofs are erased, leaving only the low-level code to be compiled to C. In short: the code is low-level, but the verification is not.[0] https://fstarlang.github.io/lowstar/html/Introduction.html#t...
https://austral-lang.org/
> Austral is a new systems programming language. It uses linear types to provide memory safety and capability-secure code, and is designed to be simple enough to be understood by a single person, with a focus on readability, maintainbility, and modularity.
Curious if there are any D users here who try to stay within that intersection?
The bigger problem is guaranteeing concurrency safety, which you can only provide with nonblocking IO. Everybody loves blocks though, so that's far away.
That depends. It is really a Hard NO for GC?
Crystal is low level enough with a GC and people have written a complete OS with it. On my mobile now so I can't provide link. But it was featured on HN a while ago.
[0] https://ocaml.github.io/ocamlunix/index.html
[1] https://matt.might.net/articles/best-programming-languages/#...