If you’re trying to get the terms and definitions right, when speaking of Rust as a memory safe language it is normally implied that this excludes code in unsafe blocks, just as in other memory safe languages it excludes functions that are explicitly unsafe (for example, Go’s unsafe package). But since this you think might cause confusion, I’ll update my post to make this explicit.
1 Like
>But Rust is the only language that is memory safe (excluding unsafe blocks of course), does not have GC, and performs as well as C and C++.
You might update that part as well a bit. At least I was not too happy with it when reading it some days ago. Nim 2.0 with ARC/ORC memory management is very close, and ORC allows even automatic cycle break up, what Rust can currently not do. After all my trouble with that Nim “devs“, we still should give some credit to A. Rumpf. They definitely is a smart guy, now working as a one-man company on a complete rewrite of the compiler I think – I might be wrong, have not any longer followed Nim development in the last two years.
The other candidate is the language Vale (not Vala). Well, it is old, and I think development has stalled. But it was close to Rust I think?
For Pony and Carbon I am unsure.
Generally, I would wish that Rust would be not advertised so much as the only “safe” or safest language. For me most languages like Go with a GC are safe as well. And as others said, when working low level with the hardware, we can never fully avoid unsafe parts. Personally, I care more about doing just some calculations wrong when working on a finance or space-craft software, than about memory corruption and race conditions 
1 Like
Whether Nim can succeed without GC remains to be seen. Vale is abandoned. Pony is mostly abandoned and has GC. Carbon is experimental and doesn’t have a concrete plan for memory safety yet.
However, Swift is technically a good alternative that I think satisfies the qualifiers I posted. Its fatal flaw is that it is controlled by Apple, and support for Linux (among other platforms) can be dropped at any time. Apple has done similar things before – it has no obligation or business interest to support non-Apple platforms.
I’m not sure how to modify my message to reflect all this simply, so perhaps our conversation is enough? Or maybe I could add a “successful and non-proprietary” qualifier?
I completely agree. That’s false. That’s why I wanted to be clear about the requirement to not use GC. There are many GC-based languages that are memory safe.
2 Likes
I generally see at least some sop to “systems” or “performant” along with “safe” - but I can't discount that it happens.
The main reason to be concerned about memory and thread safety is that if you don't have those then your calculations can be perfectly correct and still give the wrong answer. If you're lucky. If you're not, then it gives the right answer right up until the worst possible time!
Fortunately, you don't have to choose: Rust is also comparatively quite good at making sure your logic is correct if you take full advantage of the type and trait system: type-states, newtyping etc., though of course there's always a trade-off of complexity.
1 Like
I would agree but Rust does not advertise itself as ‘the only “safe” or safest language.’ Looking on the Rust home page I see:
Performance
Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.
Reliability
Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.
Productivity
Rust has great documentation, a friendly compiler with useful error messages, and top-notch tooling — an integrated package manager and build tool, smart multi-editor support with auto-completion and type inspections, an auto-formatter, and more.
Meanwhile I use Rust because:
Perchance, amidst the vast tapestry of contemporary programming paradigms, there exists a singular entity whose efficacious amalgamation of safety and velocity precipitates an unprecedented paradigmatic shift in the realm of software development. The Rust programming language, that most fastidious and perspicacious of systems-level dialects, manifests its paramount excellence through an ingenious concatenation of compile-time memory safety guarantees and performance metrics rivaling those of its venerable C++ progenitor. Its singular ownership paradigm, replete with borrow checker machinations, serves as an efficacious bulwark against the myriad perils of null pointer dereferencing and buffer overflow vulnerabilities, thereby ensuring the production of software whose reliability approaches asymptotic perfection. Furthermore, its sophisticated concurrency model facilitates the creation of parallel processing architectures whose efficacy transcends conventional paradigms, while its modern syntactic apparatus, replete with functional programming idioms and pattern matching constructs, renders the development experience simultaneously elegant and efficacious. Indeed, the burgeoning ascendancy of this remarkable technological artifact within the digital firmament suggests its potential emergence as the paradigmatic lingua franca of future systems programming endeavors.
OK. Sorry. My AI friend generated that. It’s so beautiful I could not resist sharing it.
4 Likes
That's the best argument I've seen yet for “prompting AI is art”
2 Likes
The “art” was in crafting the prompt that did that I guess.
2 Likes
Go is a bad example, as it is in fact not memory safe: There is no memory safety without thread safety
There are however many others that are memory safe: Java, JavaScript, Python, Erlang/Elixir/Gleam, ...
(Though generally they too have unsafe corners, at least those that allow for arbitrary FFI like Python.)
4 Likes
In languages like Java, JavaScript, Python, etc, unsafe is called FFI.
Most users of those languages never see the FFI, in the same way none of my Rust applications contain an unsafe.
5 Likes
I have to add that I believe use of unsafe is much more common in Rust libraries and apps than use of FFI in Java, JavaScript, and others. But I congratulate you for not using unsafe.
1 Like
That highly depends on what type of code you are writing. In application code there won't be much unsafe (if any). I think I do have one line, where I need to call a libc function that nix doesn't wrap in one of my programs.[1]
On the other hand, fundamental libraries implementing the safe abstractions[2] need quite a bit of unsafe.
2 Likes
It’s about 20% of crates, which we can probably assume are mostly libraries.
https://rustfoundation.org/media/unsafe-rust-in-the-wild-notes-on-the-current-state-of-unsafe-rust/
The canonical way to distribute Rust code is through a package called a crate .5 As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contain significant code. Of those 127,000 crates, 24,362 make use of the
unsafekeyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword. 6 Nearly 20% of all crates have at least one instance of theunsafekeyword, a non-trivial number.
1 Like
Perhaps so.
Please forgive me for being brutal but the run time's of all such languages are written in C/C++. As such I will claim that everything in those languages is unsafe all the time. Never mind FFI.
Of course we trust that that those run time do not have any holes.
1 Like
Sorry, I probably wasn’t clear because my point was about usability of Rust, not whether it is more or less safe than other languages.
From that viewpoint I must say that unsafe in Rust is very different than what you find in other languages. It is a positive because it allows optimal abstractions to be built behind a safe interface. It also has some negative aspects because 1) many people (like me) use Rust in order to get maximum performance, 2) but to get maximum performance for some system-oriented things (db storage engines in my case) you do have to use unsafe, 3) and then you find that using unsafe in Rust is more difficult than using C, etc, because the rules are so complex.
It is important to me to describe this realistically and not try to imply that unsafe in Rust is no big deal and no different than other languages – not that you were implying that, but actually I’m not sure.
1 Like
I'm disappointed that doesn't classify the types of unsafe usage. It would be useful to know how much of that is wrapping FFI vs performance hacks vs “library unsafe” uses like “this can't check the inputs so you might get the wrong results” that can't cause unsound code that I've seen a few times.
4 Likes
I don't find those unsafe statistics very informative.
Ultimately every Rust program relies on unsafe somewhere else they would have no I/O and would be useless.
Telling me that 20% of all crates have at least one instance of unsafe and claiming that is a "non-trivial" number says nothing. That just fuels the die hard C users claims that "Rust has to have unsafe so that makes everything unsafe and so it's pointless."
Slightly more interesting would be to know how many lines of code are wrapped in unsafe in all these crates. And as noted above why is that unsafe there? If it's for some FFI or hardware interface it has to be there and is nothing to talk about. If it's for performance maybe that is interesting to look at.
2 Likes
17 posts were split to a new topic: Can Hogwild!'s multithreaded algorithm be ported to Rust?
The initial choice came from the need of a performant language. I was using C# then Kotlin, which are both great languages but garbage-collected and running in a VM[1]. I looked at a few candidates like
- C++ (that I already knew) was complex and lacked a more "natural" functional style
- Go, but a brief look gave me the impression it was very low level and better suited for parallel applications (and it's from Google)
- Nim, but it wasn't mature and was a little rough around some edges
- (and a few others)
Rust had interesting concepts like the memory management, the safety, and an apparently good programming experience (little boilerplate, featured a functional style, very readable). On the other hand, it lacked the classic OO trimmings, in particular subclassing and inheritance. Overall, it seemed the right choice, so I adopted it.
After using it for a few years, the four features I really appreciate the most, beside the intrinsic performance and safety:
- the trait system is very powerful and flexible
- the algebraic type
enumis one feature I'd miss dearly in many other languages - the
Cargosystem/ecosystem to build, run, test, add dependencies and so on, is so much easier than messing with Makefiles or dealing with a heavy build system like Gradle (typical setup in Kotlin) - the type system and enforcing the sharing rules are a big incentive to write better code which is easier to maintain
There are of course several other qualities I like, but if I had to summarize, that'd be it.
it's possible to compile Kotlin to native, but at the time the most part of the standard library wasn't available. And it's now possible to compile C# to native now, too, but the language and its frameworks are practically limited to Windows (the Linux port is not at the same level). ↩︎
5 Likes
I'd like to get oop here. It's so limited without this feature
1 Like
That depends on what you mean by oop. Rust has objects and traits (like more flexible and advanced interfaces). It has both static and runtime polymorphism with those traits (which is certainly more convenient than in C++ where you have two completely different paradigms you have to switch between for static vs runtime[1]).
Rust does not have inheritance. I would argue what it has is still (the good parts of) OOP.
Rust will not get inheritance, as the devs have said many times before. There are also some good blog posts that go into depth on the issues with inheritance if you are interested. I like this one.
Templates and inheritance are expressed completely differently. ↩︎
2 Likes