> Does cve-rs break any type system rules? Yes. > If so, why hasn't it been fixed yet? Pretty classic software engineering reasons. The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sen…
If cve-rs exists, is safe rust safe? Can one prove that Rust code is safe only by auditing the unsafe blocks?
Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk. The simplest solution to these problems, if you have the capital, is to buy them.
I get that but there is always node.js
They aren't exactly the same thing, moving to node would be possible but bun does more than node, so you need to replace the whole thing.
Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.
> Compilers are not security sensitive, usually. The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream. Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this…
Most compilers do not consider themselves a security boundary, and will not try to limit malicious code from hijacking the compiler. E.g. LLVM is explicitly not designed to handled malicious code (https://llvm.org/docs/Security.html#what-is-considered-a-sec...).
That is possible (clang has experimental lifetime annotations support), but that is not enough to guarantee memory safety. As a simple example, Zig has no private fields. That makes encapsulating any unsafety impossible.
no. You don't need private fields. All you have to do is analyze the code, harness the compiler to generate a time-dependent data dependency graph, and map allocation/frees/uses, if you can 'color' branches where data are shared you can also track and check to see there isn't an aliasing violation too. it is easy to patch the zig compiler to enable this this (export the code graph; about 50 LOC). The analysis is much…
This analysis is undecidable. There is a reason sound static analyzers (including languages like Rust) require in-code annotations.
That is possible (clang has experimental lifetime annotations support), but that is not enough to guarantee memory safety. As a simple example, Zig has no private fields. That makes encapsulating any unsafety impossible.
> Zig has no private fields You may have missed the point here. You could add a comment to the struct field that marks the field as private, and build a TypeScript/JSDoc analogue that analyzes all accesses to the field and fails if it finds accesses from functions that aren't part of the struct that owns the field. You don't even need a comment on the field - you could copy Go's convention, add a comment to the struc…
I have picked private fields as an example of feature that is needed because it is very simple. You're right that you can build an analyzer (with additional code annotations) to support that, but it's only one example.
Take another example: unsafe traits. They are fundamental to some safety encapsulations, most famously concurrency (`Send`/`Sync`). Here you cannot just build an analyzer to mark something unsafe, because Zig has no traits, its generics are duck-typed.
You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig, with all problems this entails (e.g. bad ecosystem support). It's also hard to claim that Zig can be memory safe then.
Many people try to twist the fact memory safe languages have unsafe code blocks to make the pivot that why bother. It is like someone arguing that since they always bump the head somehow while wearing seatbelts, then they are only a nuisance and should not be used.
Because they view "unsafe" as an escape hatch instead of a feature. It's a way to encapsulate dangerous behavior, tightly, with clear postcondiitions. Sometimes it's the only way to do things like interact with inherently unsafe FFI code, or hardware.
I adore unsafe, appreciate it as a feature... but it is an escape hatch. One that is sometimes necessary, one that is sometimes not necessary but might still be (ab)used for performance, or initial 1:1 porting of C/C++ code. There are a lot of cases where that escape hatch should probably welded shut though. Fortunately, the Rust ecosystem has tools like `cargo geiger`, and straight out of the box I can also write:
Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc. It's supposed to be a scripting language right you embed into your C ABI right? Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language. An…
Same question. I always like learning about languages I had not heard of, especially functional languages, so I was immediately curious what sorts of applications this might have. But after looking over the roc-lang.org website and the FAQ, I still don't know.
Exactly. Every part of the language must support memory safety from first principles.
empirically untrue. several projects exist that bolt on extra safety to unsafe languages or unsafe parts of language. SeL4 for C, MIRI for rust unsafe. i guess ada/spark for ada too, is the OG, spark being added to ada 4 years after its first release
Hardening is definitely possible, we've had sanitizers in C/C++ for a long time. It's not full memory safety though. Miri is the same.
SeL4C is formal verification, and while it can prove memory safety (and much more) it is much more difficult, to the point that you're basically programming in a different language.
Ada/SPARK is your best example, and also the example I know the least of, so I won't comment on.
No disagreement in principle; in practice taking that approach in Zig is safer than in Rust, because in Rust it’s “all or nothing.”
The interfaces to custom allocators are more idiomatic, standardized, and normalized in Zig, but there's nothing systematically unsafer about the Rust equivalent. You can use custom allocators all you want in Rust, as long as you're okay using third-party crates like Bumpalo. On that topic, worth mentioning that Rust's long-awaited `Allocator` trait is perilously close to stabilizing; watch for https://github.com/rus…
The 35ms incremental rebuild is the part that sold me. I'd be curious to see the same benchmark on ARM once -fincremental gets there.
Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.