In the last round Bryan and Steve talked about being over-subscribed, especially from existing investors in prior rounds. That likely means those investors see exactly what I've described: a winner that's worthy of additional funding to pump their total return on investment.

A lot of prior guidance I've seen tends to stop at the level of running Miri, but (as the article says) there are things Miri won't catch. The model-based tests with a known-good oracle and the use of fault injection (especially panic-related behavior) are really good.

Safety in the face of panics in Rust can be hard to reason about, and the standard library itself has made errors with those semantics in the past.

Great work Rain and Oxide for building something so useful and assuring it so robustly!

It takes an issue of people in power abusing that power, and ties it to their sexuality, as if the men abuse their power because they’re gay, or as if straight men never do similarly.

Identifying abusive power structures is good, but writing about it in a way that centers the sexuality of the participants has the effect of demonizing a whole group of people unfairly.

I am appalled that Wired published this.

Comments URL: https://news.ycombinator.com/item?id=46904937

Points: 1

# Comments: 0

[1]: https://www.alilleybrinker.com/mini/rusts-culture-of-semanti...

Comments URL: https://news.ycombinator.com/item?id=46624883

Points: 219

# Comments: 234

There are open ideas for how to handle “view types” that express that you’re only borrowing specific fields of a struct, including Self, but they’re an ergonomic improvement, not a semantic power improvement.

https://cwe.mitre.org/

Comments URL: https://news.ycombinator.com/item?id=43017806

Points: 4

# Comments: 0

1) Decide to use the highly risky `pull_request_target` Actions trigger instead of the much safer `pull_request` trigger, 2) include in their Actions a script, executing in an environment with write access to the repo and access to repository secrets, which executes untrusted input (the branch name).

Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the existing memory unsafe code they had. In practice, they found that vulnerability density in a stable codebase decays exponentially as you continue to fix bugs. So you can reap the benefits of built-in memory safety for new code while driving down latent memory unsafety in existing code to great effect. [2]

[1]: https://www.alilleybrinker.com/blog/cpp-must-become-safer/

[2]: https://security.googleblog.com/2024/09/eliminating-memory-s...

In Sean’s “Safe C++” proposal, he extends C++ to enable new code to embed new assumptions, then subsets that extension to permit drawing new conclusions for safety by eliminating code that would violate the path to those safety conclusions.

Obviously this is more than a year ago, so it’s possible the facts on the ground have changed. However, this is reasonable evidence that at least as of a year ago, their shrink numbers were enough to be downplayed on an earnings call with investors.

[1]: https://www.cnn.com/2023/01/06/business/walgreens-shopliftin...