How does Ada's memory safety compare against Rust?
ajxs.me
ajxs.me
> Why wouldn’t the Linux kernel team choose Ada instead of Rust?
To which I say: Ada doesn't have a large user base beyond DOD projects. Virtually no greenfield projects except for DOD. Whereas there has been a Cambrian explosion of Unix kernels/tools/servers written in Rust.
More generally, these questions of the form "Why are you ignoring X?" where X is Ada or Zig or C++ are really "Why didn't you write/don't you rewrite this in Rust?" by a different name.
And my/that answer goes both ways. Notably, Roc recently has stated it is moving away from Rust. Ghostty uses Zig because Mitchell Hashimoto doesn't like Rust. But the answer is always someone has to show up and do the work, usually because they like doing the work in some language.
So -- it's okay to like the project strictly because of the language chosen. That being said -- I'm super interested in the more technical differences.
> It's okay to like the project strictly because of the language chosen.
I think that the massive groundswell of interest around Rust will end up being positive overall. At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.
It has a lot of the VMS features, and most of them are unused or effectively only used by malware (e.g. alternate file streams).
I did not get a chance to use VMS myself, but I did use Unix (and VMS/CMS, and a bunch of other OSes) at a time VAX was still a viable alternative even for greenfield projects.
My impression is that it is sort of like J/K/APL - powerful, compact, coherent, got almost everything right from a technical standpoint - but not friendly, feels foreign, and not liked by anyone who has ever used a Unix, or Windows, or a Mac - which is 99% of the relevant population since about 1985.
(Added): Macs also had multiple file streams (“forks”). It doesn’t anymore, for many reasons, but the chief one is interoperability. Less is more, worse is better.
You trade ability for reduction of complexity - getting an operating system that you can learn in months instead of years, which - since the tech industry has been in hipper-growth phase for much of the last 30 years, was more important.
Same with HAL (1) and IBM, I read somewhere once.
(1) The one from https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey
Google hal ibm connection.
Given Cutler hated UN*X, that only makes sense. NT did a lot of things right at the kernel level.
> and most of them are unused or effectively only used by malware (e.g. alternate file streams).
"Most of them unused"?
ADS was added to NTFS to support Mac OS file sharing over AFP ("Services for Macintosh"). Microsoft makes use of it for downloads from Edge, among other things. It's otherwise not a supremely useful feature and one that you'll silently lose data when moving to another fs/www further degrading it's usefulness.
Am I allowed to sigh here? It's a good thought, but this is humanity we're talking about here.
All it requires is some big-project, some big-corp creating some essential ecosystem with lame-language-A, and now it's got traction.
And frankly, look at rust and its weird crates. Weird as in "Let's make a super-safe language, then import random stuff from unknowns, unaudited, and just hope it all works out."
If rust was really serious about security, only signed crates from validated developers, with code review would be the norm. Oh but wait, that'd be "not easy".
Vetting code is extremely expensive in terms of human time and human energy. Sadly it's not only a problem for Rust, it's a problem for every single programming language out there.
While this is undoubtedly true, i suspect that there are also many cases where people presume the reasons are non-technical but when examined closly turn out to have hidden technical issues.
Zig seems to be gaining traction. Hard to predict whether it will succeed or slowly fizzle out after the initial excitement phase though.
I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions.
Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer.
I see a lot of space for different tradeoffs on different dimensions of safety.
It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.
The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).
Besides the fact I already mentioned about the dangers of casting pointers to references, there's also the problem that pointers are only valid as long as no operations are done with references to the same object (no interleaving). On top of it, the autoborrowing rules make it so it's not always clear when a reference is being taken (and operated upon).
So yes, in my opinion _unsafe_ Rust is significantly more difficult to get right than C.
In C++, multiple references to the same variable may cause «use after free» bug in it destructor.
For example, if I recall correctly it’s technically UB to cast to a *mut pointer unless the original variable was declared mut even if you have exclusive ownership over that object.
There was a fantastic blog post describing a lot of these nuances but I can’t find it.
Absolutely. This is evident in the different language features of Rust and Ada. At any rate, Rust has advanced the state of the art when it comes to memory safety. The next generation of programming languages are inevitably going to be compared against Rust. In the same way Rust has been compared against Ada. Especially given Rust's popularity. I imagine that if a next-generation 'systems language' can't at least match Rust's features, it won't achieve wider adoption.
I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev.
Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success.
The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use.
We had Lisp Machines, we need to go back to future.
You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky).
As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue.
IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".
Unfortunately, the history shows that such technically inferior languages and products winning out are also because of outright market manipulation by their corporate backers, tons of money in ads, or attacks on competitors. The elephant in the room, is to look at what's generating or paying for the hype and marketing behind recent programming languages like Rust and Zig (for example).
> I think that the massive groundswell of interest around Rust...
A review of the groundswell, around Rust or Zig, is its not attributable to just grassroots or genuine interest, and can significantly be the result of outright astroturfing and artificial brigading. Sadly, many people follow along with the marketing or are bombarded into submission, "must rewrite in X" or "GC all bad and manual all good" foolishness, versus actual use case and legitimate examination of language tradeoffs.
There are enough customers around the globe to keep 7 Ada compiler vendors in business, not many language ecosystems can claim that, in the age folks don't pay for their tools most of the time.
OTOH, DoD (and some public sector orgs in Europe) are extremely important customers of some of the companies that directly contribute the most support to the Linux kernel in a way that no Rust project is.
> We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.
https://www.infoworld.com/article/2247741/linux-at-25-linus-...
I have been attempting to compare Ada and Rust for a while, but never got around to doing it quite so much in depth.
So, my take on this is that:
- out of the box, Rust is distinctly better at memory safety than Ada without SPARK
- Ada + SPARK is extremely powerful (but iirc, SPARK doesn't allow compositional reasoning, which makes it harder to use in a crate-based library)
- for this specific use case, Rust's error model makes much more sense than Ada's (with or without SPARK)
- Ada's tooling to avoid memory allocation remain more powerful in some dimensions than Rust's.
Also, I think that we all (should) agree that the move towards memory safety in system-level programming is a very good thing, whether it comes through Rust, Ada, or any other language.
Using it directly is similar to the usual discussion of using unsafe in Rust for double linked lists.
As of Ada 202x, SPARK covers most of the language, no longer a subset, and also does affine types, aka borrow checking.
This is true. I admit that I didn't really acknowledge this in the article. I personally don't really like the Ada community's consensus on this matter. In many applications 'let memory leak and let the OS sort it out' just won't cut it. It's true that you can use controlled types for everything, but isn't this just moving the Unchecked_Deallocation somewhere out of sight? Also, if I'd have written 'You can't leak memory in Ada if you stick to using collections', wouldn't that just be like saying 'You can't leak memory in C++ if you stick to using the STL'? The point of the article was to show what Ada and Rust do to outrightly prevent you from shooting yourself in the foot, at the core language level.
There's a lot of misconceptions floating around the Ada community about memory being freed automatically when it goes out of scope, which I think have stemmed from the ARM leaving open the possibility for a compiler to implement its own GC. Admittedly even I was misinformed. In my defence, nearly all the Ada I write is for bare metal, and never touches the heap at all.
I wouldn't be surprise to hear this from C or C++ folks, never heard this in Ada circles, there is always that missile meme going around, and I happened in the past to occasionally drop into FOSDEM Ada's rooms.
Speaking of which,
"Memory Management with Ada 2012 from FOSDEM 2016"
https://archive.fosdem.org/2016/schedule/event/ada_memory/
> Also, if I'd have written 'You can't leak memory in Ada if you stick to using collections', wouldn't that just be like saying 'You can't leak memory in C++ if you stick to using the STL'? The point of the article was to show what Ada and Rust do to outrightly prevent you from shooting yourself in the foot, at the core language level.
A programming language is seldom used without its standard library, I don't care what a plain grammar + related semantics check offer, if there is nothing on the standard library, IDE tooling, libraries to chose from.
Otherwise than you should also do a comparisasion using no_std against Ravenscar profile.
And yes, unless you are using a C++ compiler that offers the option to harden its standard library, you are going to some surprises, starting by having to use at() instead of operator[]() for bounds checking, and even with hardened one, stuff like use-after-free/move only when using a good IDE like VC++/Clion or static/dynamic analysis tooling.
Also what is the point of .at()?
try {
myarray.at(invalid_index);
// how do you handle a logic error in your code?
// does that even make sense philosophically?
Yet you could also enable bounds checking for debugging on operator [] or use address sanitizer.
- if one were to write ‘ed’ in C++, that could be the code that handles going to the n-th line.
- in a lzw decompressor, it could be an integer read from the to-be-decompressed data stream.
In both cases, using at rather than doing a range check first can be defended because failing the range check is an exceptional case.
The point of .at() is to check the bounds at runtime. Here is your answer.
Regarding the comments. You don't necessarily know if it is a logic error and you certainly don't know if it is in your code.
Now onto the how. You handle it like any error. If you don't have a specific error handling strategy, you handle the error at a higher level e.g. your HTTP server returns a 500 http status code and logs the error and the location, so that the developer can fix the bug.
As to whether it makes sense philosophically. The only limitation is your lack of imagination. In C, the program would keep executing and create a security problem. The fact that the exception handler got called in the first place implies that at least the security vulnerability has been averted, meaning that you did indeed recover from the error, even if the catch block is completely empty.
You could argue it is ok when you use exceptions for control flow (e.g. what people sometimes do in python), but even there it looks questionable imo.
You can check manually, but we know programmers can't be trusted to do so correctly every time. There's an ocean of security vulnerabilities because of this, as out-of-bounds access of a raw array is undefined behaviour in C and C++.
It makes good sense to use at in debug builds especially, where you're less concerned about the performance penalty.
In C++ you can define a macro to select between at and [], and while this isn't exactly pretty, it does work:
#ifdef DISABLE_RANGE_CHECKS
#define AT_METHOD operator[]
#else
#define AT_METHOD at
#endif
#include <vector>
// ...
i = my_vector.AT_METHOD(my_idx);
Why? Its behaviour is pretty much strictly better than that of raw []. The only downside is a possible performance hit.
In some contexts sure, there's not really much you can do, but in many others it's perfectly clear. In a request-oriented system like a web server, you stop the failed request-handling logic and send back an error code. Exceptions can make this quite natural to implement. Much better than letting the error go undetected, invoking undefined behaviour, and risking mishandling of future requests, or perhaps even a serious security vulnerability.
> Yet you could also enable bounds checking for debugging on operator [] or use address sanitizer.
I'd flip that around. Why bother with additional platform-specific cleverness when the standard library already gives you what you're after?
I tried to track down where I read someone advocate this, but I can't find it now. I probably shouldn't have accused the whole Ada community (of which I'm a member) of this attitude. Regardless, I find it odd that 'Unchecked_Deallocation' is so thoroughly discouraged without what I'd consider an acceptable alternative.
> A programming language is seldom used without its standard library...
Nearly all of the Ada I write is for RISC-V microcontrollers, using the 'light' runtime that comes bundled with GNAT. There's no collection classes, and no heap for them to allocate anything in. The semantics of the language are absolutely still important. I still want a language that makes harmful mistakes difficult.
They weren't even born when we were using them, or if they were their toys were actually toys not systems programming languages.
Rust was their first encounter with systems programming, and Standard ML linage, after lots of Python, Ruby and JavaScript, and most likely never seen anything else other than C and C++. Most likely that also believe the fairy tale of C being the very first systems programming language.
For example, serde (and serde_json, toml, etc.) is a gamechanger, as is tracing, reqwest, and many others.
So, maybe less about the language itself for many people, but more about the human factor of overcoming fear of being stuck on an island
To quote Hoare in 1980,
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
===> I note with fear and horror that even in 1980 language designers and users have not learned this lesson.
Referring naturally to C, by the way 1988 is the birth year of the Morris Worm, taking advantage of C's buffer management capabilities.
Yes, a pretty low bar that 40 years after those events is still largely used across the industry.
And the copy paste compatibility of Objective-C and C++ with C doesn't help, because even though those languages provide better capabilities and safer alternatives than writing raw C, there are always those folks that will write C style code no matter what.
Network effects and business' risk aversion.
Nothing to do with technical superiority / inferiority really. The MBAs only hear "we must replace everything from scratch" and immediately shout "NO!".
Offensively simple I am afraid. That's all there is to it.
Believe me, I'd jump with joy if we scrap like 75% of all UNIX crap, especially "untyped text rulz" in the terminal -- and introduce one good terminal protocol in the process. But it ain't happening in yours and my lifetime.
Though to me it seems that a good percentage of those efforts will improve a general area. Still your point stands.
Sure, you still get use-after-free and manually memory management, which does not hold folks to now race into rewriting stuff in Zig.
However it gets you covered on:
- proper strings with bounds checking
- proper arrays with bounds checking
- no pointer decays, you need to be explicit about getting pointers to arrays
- less use cases of implicit conversions, requires more typecasts
- reference parameters reduce the need of pointers
- variant records directly support tags
- enumerations are stronger typed without implicit conversions
- modules with better control what gets exposed
- range types
- set types
- when using COM like interfaces, reference counting
- arenas
Sure C++ also covers some of that, that is why I went C++ after Turbo Pascal, but too many folks still use C like idioms instead of improved C++ ones, it is like adopting TypeScript, but still write JavaScript instead.
EDIT: typo, missing not
I find the allocate / try / finally / free paradigm in Delphi makes things easier, it just becomes a habit.
eg
var obj := TMyObject.Create
...do stuff
obj.free //(or for bonus points freeandnil(obj))
I kinda vaguely remember Erlang being mentioned, but I don't recall Ada being discussed. To be fair, I didn't attend many of these conversations.
Otherwise Rust would not have inherited a ton of obsolete and useless features of C.
For example, when I have seen for the first time a "Hello, world" written in Rust, I have been appalled to see that in a language designed in the 3rd millennium one still has to specify whether function parameters are passed by value or by reference, which is the wrong thing to specify about function parameters, exactly like specifying in old C language whether a local variable was "register" or "auto" was the wrong thing to specify. (The right thing to specify about function parameters has been established in 1977, almost a half of century ago, by DoD "IRONMAN", which has been implemented only in a few languages, the most important being Ada. In my opinion, most difficulties and complexities of C++ have been generated by its failure to comply with "IRONMAN".)
In my opinion, attempting to design a new programming language without first studying carefully the history of programming languages, in order to know well the many good and bad choices that have already been used in various programming languages and to understand which have been their advantages and disadvantages, is an amateurish approach that cannot result in real progress.
Most recent programming languages have been built around some innovative great idea that makes that programming language better than the previous in some respect, e.g. Rust for compile-time checking of memory accesses, but because in the other areas of the language the best previous features have not been chosen, no language is uniformly better than older languages, all of them are better for something than older languages, but worse than older languages for other things, which makes the choice of a programming language very frustrating.
7.2.F. (7F.) FORMAL PARAMETER CLASSES
There shall be three classes of formal data parameters:
input parameters, which act as constants that are initialized to the value of corresponding actual parameters at the time of call,
input-output parameters, which enable access and assignment to the corresponding actual parameters, and
output parameters, which act as local variables whose values are transferred to the corresponding actual parameter only at the time of normal exit. In the latter two cases the corresponding actual parameter must be a variable or an assignable component of a composite type.
7I. RESTRICTIONS TO PREVENT ALIASING
Aliasing (i.e., multiple access paths to the same variable from a given scope) shall not be permitted. In particular, a variable may not be used as two output arguments in the same call to a procedure, and a nonlocal variable that is accessed or assigned within a procedure body may not be used as an output argument to that procedure.
7I is important (in the mutable case), and solving the problem that bought forth this rule is the core idea behind Rust.
7F draws useful semantic distinctions: Output parameters are return values. Input-output parameters are mutable references. Input parameters act as a copy or readonly reference – which are equivalent if you can't mutate or observe mutation through readonly references.
Your complaint is that Rust draws a distinction between whether input parameters are implemented via a copy or a reference, but Rust draws many more distictions here – arbitrarily many so, because it's part of the type system. This makes the system both applicable everywhere instead of only in function parameters and allows expressing more different semantics.
For example I have a hard time seing how one would, while following the Ironman requirements, distinguish parameter whos type is "dynamic array of elements of T" from one of type "dynamic array of elements of type mutable reference to T". Likewise you can define a record that holds a mutable reference and an immutable reference, or define a new reference type (such as a reference counted pointer) without new language support.
I said that passing a copy and a readonly reference are equivalent. However, in Rust there are no readonly references. Rather, there are non-aliasing references, which allow mutation, and aliasing references, which by default don't allow mutation – but types can make use of interior mutability to allow mutation through aliased references according to they rules they need. For example you can access data protected by a mutex if and only if you hold the lock, which means that even if other references to the mutex exist, there are no other references to the inner data.
> Input-output parameters are mutable references.
In/out can also be by value, it would copy any updates back after the call.
> Input parameters act as a copy or readonly reference
This is what your parent is getting at: the idea is that in/out/inout describe intent, not mechanism. The compiler chooses the mechanism for you.
I think in a language that's intended for lower-level tasks, describing mechanism is important. That said, outside of STEELMAN, there's an argument to be made for in/out/inout, and in fact, there's been some discussion over the years, for example, &uninit T as a sort of variant of out.
> For example I have a hard time seing how one would, while following the Ironman requirements,
You're right. STEELMAN updated this section to say
7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing (l.e., multiple access paths to the same variable or record component) that is not intended, but shall not prohibit all aliasing. Aliasing shall not be permitted between output parameters nor between an input-output parameter and a nonlocal variable. Unintended aliasing shall not be permitted between input-output parameters. A restriction limiting actual input-output parameters to variables that are nowhere referenced as nonlocals within a function or routine, is not prohibited. All aliasing of components of elements of an indirect type shall be considered intentional.
However, unlike Rust, Ada does do strict aliasing, and so you can also get miscompilations that way. It requires the moral equivalent of unsafe, though. See https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gnat_ugn/Optimizati... for an example.
Ada does prevent data races, because it has a built-in task system, and that task system only allows multiple tasks to access "protected objects" that are basically RWLock<T> in Rust terms.
Rust is very much designed as a low-level language. If you want a higher-level language with similar guarantees, OCaml, Haskell, F# or Scala do the job very well already.
The mechanism of argument passing has its uses in terms of both performance control and avoiding unwanted aliasing, something that not many languages do properly (not even Ada, iirc).
It's not the right thing to do for all languages/applications, but I believe that it's the right thing to do for Rust. Do you have a better design in mind?
In Ada, there are also requirements that some types are always passed by value or by reference. And as of Ada 2012 there's a way to force the "always pass by value" types by reference.
A while back someone wrote a post comparing Rust to the sort of design your parent prefers https://web.archive.org/web/20241009004034/https://jedbarber... I remember it being... fine.
The short of it is, Rust doesn't do great because STEELMAN wants subtyping and contracts (though I see contracts may be coming to Rust...) as well as return values instead of exceptions.
Also, yay for contracts in Rust :) Looking forward to seeing them proven by model-checkers, too!
Graydon is incredibly knowledgeable about programming languages.
Just because you have certain opinions about language design does not mean others do not know things.
Speaking of knowing history, Ada implements STEELMAN, not IRONMAN.
Rust's original designer credits these languages as the inspiration: http://venge.net/graydon/talks/intro-talk-2.pdf
Mesa (1977), BETA (1975), CLU (1974), Nil (1981), Hermes (1990), Erlang (1987), Sather (1990), Newsqueak (1988), Alef (1995), Limbo (1996), and Napier (1985, 1988).
The original Rust compiler was written in Ocaml.
> has to specify whether function parameters are passed by value or by reference
You specify whether arguments are borrowed or moved, and whether the access is shared or exclusive. This is not an implementation detail, it's an API contract that affects semantics of the program. It adds or removes restrictions on the caller's side, and controls memory management and thread safety.
People unfamiliar with Rust very often misunderstand Rust's borrowed/owned distinction as reference/value, but in Rust these two aspects are orthogonal: Rust also has owning reference types, and borrowing types passed by copying. This misunderstanding is the major reason why novices "fight the borrow checker", because they try to avoid copying, but end up avoiding owning.
There are different possible approaches to achieving similar results for argument passing, but Rust prefers to be explicit and give low-level control. For example, Mutable Value Semantics is often cited as an alternative design, but it can't express putting temporary loans in structs. The syntax needs a place to declare lifetimes (loan scopes), as otherwise implicit magic makes working with view types tricky or impossible: https://safecpp.org/draft-lifetimes.html
Rust is objectively better than what I tried before, in several ways.
From where I was standing several years ago, there was almost zero "human factor" in adopting Rust for many companies (and devs). People simply saw the better features, performance and security and got excited and wanted to work with that language. And then many mistook that for hype. Yourself included apparently?
Sometimes things get popular just because they are good, you know. Not super often historically, mind you, but it does happen. IME Rust is one of these outliers.
It also wasn't the point. There was a number of completely unnecessary annoyances.
Academics writing compilers actually seemed like a good idea to people back then. Still makes me smile thinking of it sometimes.
A lot of modern compilers don't seem to be directly done by academics though. If you know of such modern examples I'd be happy to be proven wrong.
It is full of PhD paper contributions.
For example, research students doing internships at Embecosm (https://embecosm.com), as many others, plenty of material from LLVM Developers Meeting sessions.
Obviously a lot of what passes for "AI" these days is researched and created by academics.
Thanks.
Ada does not offer anything similar. It's designed for programs that are mostly static. It also does not compose well, as you can't dynamically allocate without losing most of Ada touted advantages.
To be fair, they recognized it. Their plan is to adopt a borrow-checker.
For example I just ripgrep. Arc is used 29 times, compared to 185 uses of Vec.
Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they?
Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it.
(Disclaimer: I do like Rust)
That depends on what "fast enough" means. A better way would be to say "memory-safe with (near) zero overhead".
I would think that the main cause for wasted CPU cycles is the code written by the developer, not the language.
My point was that it's not enough to say "If you use Rust, your code will run faster", because the language does not do it all. Most code out there is largely inefficient. The tendency is to pile up dependencies and frameworks to be more productive.
No need for Rust to make an ElectronJS app vastly more efficient.
Similarly, I recently wrote a TUI with a popular Rust TUI library, and it takes up to 10% CPU just by refreshing the view when typing a text. It's not my code, it's the (again, popular) library that explicitly doesn't consider that a problem. It's not because it is written in Rust that it is efficient, is it?
no, but 1) Rust significantly raises the boundary and on average it's probably more likely too
I don't see why they would care more, and in my experience they don't, on average.
Your experience is a singular event not representing the average.
My original opinion was that people should use more Rust to write more efficient software, because it's beneficial to humanity.
You're welcome to use Python for whatever slow scripting you personally need, but it's not suitable for writing an OS and libraries because it's going to make every program slower, and while that might be ok for you, it's not going to be ok for a lot of people.
> without compromising on speed
I was just trying to explain why that matters to you.
Nobody is saying you have to use Rust for everything.
> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed.
My point is that I am not completely sure if we can say that Rust is the first (yes, first) at that.
Before you get at me for "fast enough", let me say that "without compromising on speed" doesn't mean anything either. I can write super slow code in Rust, it's not like the language prevents me from doing it.
My point is that in many cases, the speed is really not the problem with the JVM.
It means you couldn't write faster code if you did it by hand in assembly. In C++ they call it "zero-cost abstraction" (you can Google that).
Adding GC adds all sorts of overheads that you can avoid in C and Rust.
Obviously in some cases you can beat the compiler, but in general it means there aren't any systematic overheads.
I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there?
"Zero-cost abstraction" is a concept I understand. But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
Feels like it is compromising on speed, to some extent.
> but in general it means there aren't any systematic overheads
Or maybe I am wrong and there are absolutely no systematic overheads in any concept similar to `RefCell` in Rust? Is `RefCell` zero-cost? That's not my understanding.
It's not a formal term. The meaning was clear though.
> But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
Absolutely!
https://godbolt.org/z/aMPfqz396
The second example is what you'd do if you were writing C or assembly. Rust takes the safer option by default.
> Is `RefCell` zero-cost? That's not my understanding.
I think you are misunderstanding what "zero-cost" means. Or maybe what RefCell does. RefCell checks are runtime if a value is borrowed by some other code. It's kind of like a single-threaded mutex. You can't implement that in assembly any better, so it is zero cost.
You are probably thinking "but in C you don't need to use RefCell at all!", and that is true but unsafe. You can avoid that in Rust, but nobody does because it's 2 instructions (which will be perfectly branch predicted) so it essentially costs nothing.
It's kind of like how `std::vector::at()` is still a zero-cost abstraction in C++. The thing you are abstracting is "array access with bounds check". You can't perform that function any better with hand-written assembly. Saying "aha, but in C we never bother with bounds checks!" doesn't invalidate that.
Was it? You are telling me that it is actually possible to write faster code if it is unsafe, but for some reason it doesn't count as faster in your book, and therefore it's not compromising on speed ("just ignore the faster solutions").
With that kind of definition, all the code I ever wrote is provably optimal: if you ignore all the solutions that are more efficient than my code, then my code is the fastest.
I think you understand at this point and are just nitpicking to avoid admitting it, so goodbye.
You said "you're wrong, it is optimal".
Now you say "it is not optimal, but it is very good, and I think you are nitpicking when you say it is not optimal".
Sure, I'm nitpicking. I was nitpicking from the beginning on, I'm not sure what you were trying to say now.
For all my 23 years of work a language like Elixir (or even Ruby) was "fast enough" but there exist a ton of other world out there that needs more.
Because when I said "for the vast majority of use-cases", I expected people to understand that I agree that some use-cases can't run e.g. a garbage collector.
I just feel like I read a lot of "Rust is the only worthwhile language our there", and actually there are many languages that are a better fit in their use-case.
Pay no attention to zealots. Every community has them. I love Rust beyond what's rational and I still am sensible enough to reject it for projects where it would only prolong development time for not much gain (the projects in question do not need the super-duper speed or to use much less memory than you would get with my favorite Elixir, for example). And for a lot of script-ish / one-off / I-want-to-finish-it-quickly projects I just opt for Golang.
IMO projects like rewriting the UNIX userland utilities in Rust makes perfect sense; the originals are super old and nobody wants to seriously find security bugs in them and since they are written in C you can bet your neck they absolutely do have buffer over-/under-flow bugs that can likely lead to escalation of privileges. Is anybody fuzzing those tools 24/7 for years? They are the buildings blocks of at least 90% of all servers out there!
Rust makes sense in embedded as well, in financial trading, or in any system that has to squeeze every last drop of its hardware in general.
But web applications / API endpoints / API gateways and such? Meh, a compiled language in a VM like Elixir is plenty enough and always will be.
"Right tool for the job" should be the first catechism of the future Tech Priests and their cult to the Omnissiah (insert "Warhammer 40,0000" reference here ㋡).
And adding a GC is a hugely impactful step.
I've seen more segfaults in my Python code than I have in any other language ecosystem. Yes, that's in the C modules that Python libraries so often wrap, but the result is still that Python is far from the best choice for memory safety.
JavaScript actually tends to be better at avoiding dropping into C unless absolutely necessary.
> Ferrous Systems and AdaCore are.. joining forces to develop Ferrocene - a safety-qualified Rust toolchain, which is aimed at supporting the needs of various regulated markets, such as automotive, avionics, space, and railway.. qualifying the Ferrocene Rust compiler according to various safety standards.. [including] development and qualification of the necessary dynamic and static analysis tools.. our long-term commitment to Rust and Ada extends to developers who will be using both languages at the same time. We are looking at interoperability between them - including, in particular, the idea of developing bi-directional binding generators.
Nvidia uses Ada/SPARK for formally-verified security firmware on RISC-V cores on GPUs [1] and SPDM attestation of devices like GPUs and Infiniband NICs [2].
[1] https://blog.adacore.com/when-formal-verification-with-spark... & https://static.sched.com/hosted_files/riscvsummit2024/fe/Key...
[2] https://www.adacore.com/papers/nvidia-using-recordflux-and-s... & https://docs.nvidia.com/networking/display/nvidiadeviceattes...
Ada is not actually type-safe: https://www.enyo.de/fw/notes/ada-type-safety.html
As also explained at your link, the same type-safety breaking technique works in unsafe Rust. Both "unchecked" Ada and "unsafe" Rust do not provide type safety, while the safe subsets of the languages provide it.
The article was written in 2011, and the trick still seems to work in a 2024 version of GNAT.
> Both "unchecked" Ada and "unsafe" Rust
But the `Conversion` function isn't using `Unchecked_*`. That's the point of the article. The type safety hole is in "safe" Ada.
I'm not sure what the difference was, given that the representations haven't changed, and I'm doing this without invoking the optimizer.
EDIT: I had issues with Miri so I dug into the MIR myself:
let uncopied : *const Uncopyable<*const B> =
match magic {
Magic::B(b) => &raw const b,
StorageLive(_4);
StorageLive(_5);
_5 = move ((_3 as B).0: Uncopyable<*const B>);
_4 = &raw const _5;
StorageDead(_5);
After I figured that out, miri started working, I must have made a mistake earlier. It will tell us the same thing:
test test ... error: Undefined Behavior: memory access failed: alloc113986 has been freed, so this pointer is dangling
--> src/lib.rs:24:13
|
24 | assert!((*uncopied).value != std::ptr::null());
| ^^^^^^^^^^^^^^^^^ memory access failed: alloc113986 has been freed, so this pointer is dangling
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
help: alloc113986 was allocated here:
--> src/lib.rs:18:16
|
18 | Magic::B(b) => &b,
| ^
help: alloc113986 was deallocated here:
--> src/lib.rs:18:23
|
18 | Magic::B(b) => &b,
| ^
= note: BACKTRACE (of the first span) on thread `test`:
= note: inside `magic::<&str, &u8>` at src/lib.rs:24:13: 24:30
note: inside `test`
--> src/lib.rs:36:5
|
36 | magic::<&str, &u8>("magic string");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside closure
--> src/lib.rs:35:10
|
34 | #[test]
| ------- in this procedural macro expansion
35 | fn test() {
| ^
= note: this error originates in the attribute macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
Funny enough, if we take the critique in the forum as correct, and try with a union: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Rust will:
1. force us to use ManuallyDrop
2. the API makes this move explicit, and we get a compile-time error!Out of all of them, the best would probably be Rust (great ecosystem) and Odin (the designer behind Odin is literally a game dev iirc)
Uh? I thought that Ada suffered from the "aliasing issue"(1): given that the compiler choose whether to copy or alias, there is a risk that the semantic of your program change when the compiler/optimisation change, am I wrong?
1: if you have a function with two parameters, one "in" and the other "inout" and you pass the same variable to the two parameters.
2) The output value depends of the size of IntArray!
>> with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
procedure Text is type IntArray is array (1 .. 500) of Integer;
type MyStruct is record
Value : Integer;
A : IntArray := (others => 0);
end record;
function Compute (Value1 : MyStruct; Value2 : in out MyStruct) return Integer is
begin
Put_Line ("1 value1=" & Integer'Image(Value1.Value) & " value2=" & Integer'Image(Value2.Value));
Value2.Value := Value2.Value - 1;
Put_Line ("2 value1=" & Integer'Image(Value1.Value) & " value2=" & Integer'Image(Value2.Value));
return Value1.Value * 2;
end Compute;
Value1 : MyStruct := (Value => 10, A => (others => 0));
Value2 : MyStruct := (Value => 20, A => (others => 0));
Result1 : Integer;
Result2 : Integer;
This should have also been detected as an error by the normal Ada compiler, but I assume that this is avoided in order to enforce market segmentation.
Those who are not happy with the reduced error detection abilities of the free Ada GNAT compiler are expected to pay for SPARK.
I think that the main reason why the use of Ada has remained restricted is that even today having access to complete Ada development tools is expensive, even if the free GNAT tools are enough when you do not need the better error detection provided by the paid tools.
Note that at some point Zig had the same semantic as Ada, but then they changed to use C's (less efficient) semantic: this aliasing detection must be difficult to do..
Is there an online Ada compiler which detect the issue?
The compiler may choose to pass by value the "in out" parameters in which case their aliasing may have no effect ("in out" parameters that are passed by value, typically in order to be passed in registers, are loaded upon function entry and stored back upon function exit).
In Rust, C or any other language with parameters passed by reference, you can always alias 2 parameters passed by reference, unless the language defines that as an error that must be caught at compile-time or at run-time. Usually aliasing will lead to errors if at least one of the 2 parameters is modified inside the function.
Because of this, aliased parameters which may be modified inside a function and which are not allowed explicitly shall always be flagged as an error.
> Ada has its own nomenclature for multithreading: Tasks, and provides its own built-in mechanism for preventing data races between them. Ada's Protected Objects encapsulate data inside an implicit mutex, allowing only one thread access at a time via a public interface.
I believe ADA doesn’t have a guarantee that you are accessing data thread safely. And that lack of guarantee is where use-after-free and double-free can hide. Heck, you don’t even need any threading.
1. Create an alias
2. Free the original value
3. Access the alias
If I read it correctly, the variable holding the original value is reset to null after a free but the alias can still access freed memory.
TLDR: Rust has almost no competitors when it comes to the very robust safety guarantees it makes and none when you combine with the performance niche it services.
I have not noticed yet anything innovative in this aspect of Rust.
As explained in the article SPARK detects such double free or use after free, even if the standard Ada compiler does not.
The separation between Ada and SPARK in the power of detecting unsafe memory uses is just a market segmentation mechanism, not something intrinsic to the Ada language.
The SPARK development tools must be bought, while the free Ada development tools have less comprehensive error checking.
This is the main disadvantage of Ada vs. Rust. It is a question of money, not of technical qualities.
> Rust has *almost* no competitors when it comes to the very robust safety guarantees it makes and *none when you combine with the performance niche it services*.
The almost is doing important work in that statement and the none is referring to systems programming. As another commenter noted, SPARK is more than just a cost thing - it fails to scale to non trivial sized projects.
I’m not saying there’s nothing to learn from Ada. All I’m saying is that Rust offers significantly stronger protection and memory safety out of the box than Ada and no language has managed to deliver such memory safety with the performance profile of C and able to target all the same variety of use cases in terms of systems programming (but then also scaling to web services which C/C++ can’t really reach unless you like trivial memory exploits)
> I have not noticed yet anything innovative in this aspect of Rust.
Innovation often times can be subtle like packaging up existing ideas in a friendlier package that can get more mass adoption. If you fail to see the innovation Rust has done with the borrow checker (which afaik is truly novel) and then making the entire language be able to scale from embedded to web services in a cohesive way and also making it a legitimate replacement to C++ in ways that other languages have tried and failed, I think you’ve been too dismissive.
And I've coded in Ada...