There's plenty of situations where telling developers to go change their code so it doesn't panic might be an appropriate lint. Think safety critical rust for example.
A lot of panics are placed instead of proper error handling as a cause of happy-path programming. (E.g. all cases of .unwrap())
Some panics are placed not knowing they’re panics. (E.g. indexing, calling a function that panics)
Some panics are legitimately placed by people who want a program to panic at a given place; this may collide with the caller’s desire to use Result and error types.
There are lots of situations where being notified about where the panics live can make your code more robust, because they do sneak in.
The problem however is that a generic "panic" lint will trigger on these as well. Which will be pretty annoying. Combined with the fact that such a lint will have to see through functions in other crates (otherwise `unwrap` and indexing won't be linted) will make this pretty annoying. I hope maintainers won't be nagged to remove lecit panics like these just because the lint annoys some dependents...
Correctness of safety critical code (and others) is about more than just memory and logical safety. Imagine your brake control module is running rust and something unwinds. Now your time budget is being spent unwinding the stack and you're probably going to run into a watchdog halfway through, forcing a reboot and possibly escalating into a hard stop depending on the safety model. You can imagine similar issues with cryptography for example, or network stacks.
I'm not saying that lint should be enabled by default. It's a highly specialized config, but it's an important protection when it's useful.
If you want to prove that an array is never indexed out of bounds in some procedure for an embedded program, you can use Ada with SPARK or use Frama-C to prove it. As far as I know, Rust has no equivalent.
Otherwise, like duped said, using get will return an Option<T>, and so you'd either have to use unreachable!() and panic anyway, or you'd have to propagate the error up the call stack and let it affect all the types of those functions (at which point, what is the caller supposed to do about it?).
get() returns Option<T> which you need to match against, and if it's None then you may have no choice but to mark it unreachable!() which will panic in debug compiles.
Or you can use get_unchecked which is unsafe and avoids the bounds check. If you pass the bounds check up higher then you have no risk of panic.
My point is that forbidding code from panicking isn't that useful - you still need to audit the code to make sure it's correct.
This is not that simple at all. For starters, what is a bound check? There's no such concept at the type level that the compiler can check. You'll need to add one such concept that propagates through functions, increasing the complexity of function signatures.
And this still won't solve the problem of when you as a programmer know that something is definitely inbound but you can't express the proof in the language. Ultimately this means using `panic` (but you don't want to), dummy default values (but this is just `null` all over again!), adding dependent types (which AFAIK nobody has managed to do in a low level language, and even if it was possible it would add a lot of complexity) or just give up and accept your program cannot be accepted.
catch_unwind doesn't catch all panics. I imagine that running a thread would actually catch all panics, but I don't know enough about the subject to say that confidently.
Aborting panics won't by caught by threads either.
And they are common only in two scenarios: if you set panic="abort", or special UB checks that the standard library does. The former is just a simple configuration change, the latter is not really something you can handle in any way.
I support the push towards memory safe languages but emphasizing Rust in the way this paper does seems misguided. It creates a false dichotomy between c style languages without safety guarantees and Rust as though there are no other alternatives. There are other approaches and models that can also achieve bare metal performance for many problems without taking in all of the complexity of Rust. Moreover, we will never settle on one language to rule them all (and if we do I am 100% sure it will not be Rust), so we should be emphasizing approaches to mitigating vulnerabilities rather than prescribing a particular tool.
Sorry? So obviously with GC one means managed GC. Otherwise the comment above doesn’t make any sense at all since then Rust itself would use GC because it also supports reference counting.
Strictly speaking you could obviously say reference counting is a form of GC. So to avoid GC you then surely recommend people to use C since that, in contrast to Rust, Swift, C++ and many others, really doesn’t use any GC, neither managed nor reference counting based.
Reference counting is a form of GC. Saying Swift, or Perl, are not GC’ed would be misleading.
In Rust, reference counting is opt-in for individual objects. It is a necessity for any powerful, low-level language to be able to implement any high-level feature.
You can, after all, also implement reference counting in C.
To avoid GC, you need a language where it’s opt-in. For example C++ or Zig, but not OCaml.
I wonder if you have any experience or opinions about dealing with the Rust Foundation itself. My personal observation from small talks with them is that Rust decentralized communities are the driving force.
- an addition to the critical infrastructure information technology sector,
- a cloud computing tax to fund critical U.S. cyber defense
- U.S.-sponsored governance for emerging cybersecurity solutions like Rust, and
- a U.S.-sponsored open source library verification service.
Some relevant quotes:
- Cloud sales tax:
-- "A cloud computing tax is long overdue, and it must be collected to secure the software supply chain for American consumers."
-- "A cloud sales tax would put the cost of securing open source for U.S. economic stability on the companies that have profited the most from open source software—its biggest consumers. The Open Source Trust can offer financial support to open source communities, allow for more free-flowing exploration of our technology frontier, and close a gaping hole in America’s economic stability."
- "A public-private partnership effort to build an actionable cookbook for memory-safety migration would be a better first step than urging technology manufacturers to use the one available today." ... "CISA should partner with early Rust adopters to identify their insights, costs, and wins and visibly incorporate that data into the roadmap guidance." ... "CISA should lead an initiative to create this cookbook for memory-safety migration starting with Rust, where there is little institutional knowledge available today, and this work should be funded by the Open Source Trust."
- Because Rust's memory safety and analysis tools are limited, and because engineers "need education and tools to know when to use [unsafe Rust] and how to mitigate the risks 'unsafe Rust' introduces," CISA SEI should "receive Open Source Trust funding to continue their research and development and (a) reduce the limitations of the Rust compiler, (b) audit the Rust compiler’s correctness in assessing the memory safety of Rust code, and (c) develop both static and dynamic analysis tools for safe and unsafe Rust."
- Also, CISA should "receive additional Open Source Trust funding to support rapid, in-depth development of standards across package repositories, compilers, and build tools" to mitigate the the security problems that come from one person controlling a crate that thousands depend on.
This isn't that important, but it's interesting, because I have often heard complaints here that Rust is hard to read.
"Rust is also the easiest programming language to sight-read. Engineers reading new code are like musicians reading unfamiliar sheet music. There are always recognizable elements, but the theme, pace, and key may be outside of the player’s experience. In software, those unfamiliar elements can take a developer through a complicated maze of dependencies and logic trees, and Rust makes the trail of logic in a program easier to follow. Researchers have concluded that Rust has a significantly lower cognitive complexity than C, C++, Python, JavaScript, and TypeScript (all languages studied), “meaning that [Rust] can guarantee the highest understandability of source code compared to all others.” As a result, software maintainers can understand unfamiliar Rust code far more quickly than code wri0en in many other popular languages."
>"Rust is also the easiest programming language to sight-read. [...] Researchers have concluded that Rust has a significantly lower cognitive complexity than C, C++, Python, JavaScript, and TypeScript (all languages studied), “meaning that [Rust] can guarantee the highest understandability of source code compared to all others.” As a result, software maintainers can understand unfamiliar Rust code far more quickly than code written in many other popular languages."
I like Rust, but this sounds like opposite world. I have trouble imagining how this conclusion was made.
I think the type signatures are really helpful in this regard. It makes it really easy to tell what’s happening and if I have to worry about mutations.
Writing the signatures can become a pain because you have to think everything through up front, but we spend more time reading code than writing it.
I imagine it's about type signatures. Rust makes it very easy to attach strong invariants to types. In most other languages, it's either harder to attach these invariants or harder to trust them. By one metric (definitely not all of them), this makes properly written Rust code much easier to understand (and trust) than in the other languages from that list.
Bingo. I'm already in a bad mood from c++ stl compile errors and template bs ... rust ain't helping. And for my work (low level MT csp (communicating sequential processes) and as another hn post made reference to, better design verification ie better integration of spin or lean with a dev lamguage would go further to deal with the unwieldy aspects of systems.
Unsafe doesn't operate on that scope, and it's not about the language primitives but the features that let you to ensure things about their usage.
Something I've just realized recently is that while not all Rust programs are safe and sane, Rust is one of the few langages with a type system powerful enough that you can actually specify and build safe and sane programs with it.
Languages like C/C++ and friends don't have more inherently dangerous primitives they just lack that type system. Same floor, lower ceiling.
It's not just the type system either. It also helps that rust has a great ecosystem of tools that catch all kinds of errors at build time. The compiler and clippy together genuinely do prevent a lot of mistakes.
This is a big part of why people often say "if it compiles, it works" in rust.
You people seem to underestimate the average sloppy programmer. Rust is yet composed of people that take programming seriously. One day it will be as popular as C++ or Java, and will you start seeing wonders in code bases around the world.
I've seen it before with Java. That thing was pure OO, contained in a VM with GC, perfect world. Poor guy that has to maintain Java legacy code these days. Right, right, this time is different.
Rust is already popular and old enough to have terrible Enterprise Rust code bases.
There are a few things working in Rust's favor:
* unsafe code is used to build safe abstractions around it, so most users don't have to write unsafe code themselves. It is easy to forbid use of unsafe blocks in your own codebase. You can flag unsafe code during code reviews, and have a policy who is allowed to write unsafe code.
* Rust leans on open-source dependencies a lot. Commonly used libraries are decent, since the community can band together to improve or replace them. This makes Rust applications mostly "glue" code, where there's less room to mess up in novel ways.
* the language allows defining strict library APIs which are harder to misuse. There's Clippy checking for common mistakes and sloppy code.
Rust already assumes that it will be written by less than prefect programmers.
One step further, many rust libs use `#![forbid(unsafe_code)]` to explicitly disallow any unsafe. The rust community really likes that sort of thing, and for good reason.
Rust is not widely adopted yet. When the mass of sloppy programmers are required to write code (applications, drivers, etc.) in Rust, you will take the bet back.
I disagree. Rust is more widely adopted than you think, more so in mission critical software. Every major player uses it. It runs on embedded, Android, iOS, in your browser, it’s in the Linux kernel. Things will just be accelerating from here.
