Investing in Rust | Hacker News Reader

Investing in Rust

lawfaremedia.org

47 points0xedb54 comments

What I really, really need from Rust maintainers is a #[forbid(panic)] somewhen in the next releases.

What do you need it for? That would forbid tons of code, like array indexing and unreachable!().

There's the UnwindSafe marker trait that isn't exactly the same thing but addresses the only real case I've seen for forbidding panics which is FFI.

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.

Adding to this argument:

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.

But what about those panics for "I know this situation cannot possibly happen"?

For those you have `unreachable!()` (a hope rather than a certainty):

https://doc.rust-lang.org/std/macro.unreachable.html

In those cases you strike a deal with the devil. The type system won't help you.

Maybe it's an acceptable tradeoff for readability and efficiency.

Maybe you could have modelled the code so it wasn't necessary.

I think you can divide the use of `unreachable!()` in two cases:

  1) As a consequence of style (applying LEM to code)
  2) As a consequence of low-level abstractions

One can be avoided by remodelling. The other can be tucked away behind safe interfaces.

The unreachable macro invokes a panic. It wouldn’t be allowed if panics were not allowed.

As the other commenter said, `unreachable!()` panics. You'd need https://doc.rust-lang.org/core/hint/fn.unreachable_unchecked...

Which is arguably even worse, because now if it fails you don't even see it! You wanted to make the code more robust and ultimately made it less.

Yes, I'm not saying `unreachable!()` isn't a `panic!()`.

And I am also not arguing for the use of `unreachable_unchecked!()`.

I am only arguing that in all the other cases mentioned, you can simply avoid panics.

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...

My claim is that's not actually very useful for ensuring the correctness of code, since Rust doesn't dependent typing.

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.

For embedded code that must never fail. I don’t want array indexing, I can just use „get“

I would allow array indexing if the compiler can prove the bounds have been properly checked before use.

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.

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.

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?).

Put your code in a thread to turn panics into errors.

You don't need threads for that, just std::panic::catch_unwind().

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.

https://doc.rust-lang.org/std/panic/fn.catch_unwind.html#not...

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.

Which alternatives exactly? Mainstream languages like Go and Swift use a GC and don't allow the same level of control over memory layout.

There are probably some reasons Rust is only non-C language to get into Linux kernel.

That’s just not true, Swift doesn’t use GC but reference counting.

Reference Counting is a type of GC.

Stop using words you don't understand, it's dishonest.

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.

C++ also got into the Linux kernel at some point in the past, it just failed to stay there. Let's see how it fares for Rust.

Do you have any sources on when this happened and in which part of the kernel? My search has turned up nothing.

I assume LWN or some other Linux adjacent news outlet should have written something about it.

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.

The author does not seem to have written much code.

Also trying to get government funding for a particular language seems like a lobbying to me.

In its own words, this paper calls for:

- 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 proﬁted the most from open source software—its biggest consumers. The Open Source Trust can offer ﬁnancial support to open source communities, allow for more free-ﬂowing 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 ﬁrst 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 signiﬁcantly 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."

They cite this study: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/

>"Rust is also the easiest programming language to sight-read. [...] Researchers have concluded that Rust has a signiﬁcantly 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.

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.

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.

Is there currently public funding for any other programming languages?

At least OCaml, Haskell, SML.

Futhark is being developed at a university, so at least there is partially public funding.

The Sovereign Tech Fund lists Fortran and PHP among its investments.

https://www.sovereigntechfund.de/tech

Reply on news.ycombinator.com