UtherII's comments

That's exactly the point. The patch in question is not to be used in any part of the kernel. It is a wrapper around the C API. It has no impact on current code and it will only be used by Rust drivers using DMA, the people of Rust for Linux were clear about it.

Duplicating this wrapper in every driver would just make painful the usage of DMA for Rust drivers for not benefit.

The concept of safety is pretty different in a kernel and in a programming language. The kernel can be attacked directly with malicious calls, while it's the program created by the rust compiler that can be attacked (unless you envision Rust as a sandboxing technology, what it is absolutely not).

The safety in a programming language is mostly protecting the programmer against itself. The probability for a programmer to write this kind of code by mistake is close to zero, as opposed to UB in C or C++ that are pretty common. To make a vulnerable program with this kind of issue, the programmer would have to make them on purpose, what is unlikely unless for this kind of joke repository.

Have you really used Rust on big codebases? One of the big advantage of Rust is especially that it fails far earlier than C++. Borrow checker error are local error that prevent bad behavior to propagate and cause problem on unexpected part.

The java slow build time is usually a dependency problem too. On similar complexity, Java is usually as fast or even faster than Rust.

It can used as an intermediate language, and since it was the only way to run code on the browser without plugins before WASM, it happened a lot.

But nowadays WASM is much more suitable for the job. JavaScript was designed as a scripting language, not a low level intermediary language.

You can even go back earlier : MessageFormat is available in Java since 1997.

I not sure he mean never panic at runtime. I think there are good reason to panic at runtime if you care about safety a buffer overflow is a good reason for instance.

But a memory allocation failure is clearly not a good reason.

You have to blame both the carpenter and the tools. Since there is no such a thing as a perfect carpenter, mistake will happen, that why a tool that can prevent a whole category of mistakes is a good thing. It's no mistake good carpenter don't use crappy tools. To be the most efficient, you need the good carpenter with the good tools.

Of course you have to care about the problem domain first, but it's absolutely wrong that nobody commit their budget to fix C++ safety problems. There is a massive amount of static and dynamic tooling to mitigate its problems and a substantial part of the C++ evolution these last years was to improve safety. Rust was able to go further than C++ in this area since it is not yet constrained by decades of history.

The IDE support use to be very poor but nowadays there are two really nice contenders :

- Jetbrains IDE with the Rust plugin (maintained by Jetbrains itself). The free IntelliJ IDE Community works really well. CLion or IntelliJ Ultimate are necessary for debugging support

- The Rust-analyser tool. A language server that can be used, in theory, on any IDE supporting the LSP protocol. Code is the most used IDE with this tool since it is the reference IDE of the project.

The problem would be to get a definition of idiomatic code.

Would it be fair to accept an optimization on a language and refuse it on another because it is not idiomatic ?

I'm not so sure. I remember a presentation of Webrender with nice demos : https://www.youtube.com/watch?v=erfnCaeLxSI&spfreload=10

Everything was perfecty smooth, but according to pcwalton the bottleneck was CSS handling.

A new programming language is not required, it's just a bonus to help developers handling safety and concurrency.

The most obvious case is bound checking. If you have a code with direct array indexing you have to use unsafe code or loose a little bit of performance.

That's why on Linux, by default, Rust link everything statically except the libc. But you sill can make a fully static executable by using the "musl" target.

Yes, the crash can come from every line of code, but the origin of the bug is in the unsafe code. That's why unsafe code has to be cleanly inspected to be sure it has a safe interface, and by reducing the dangerous area to only few lines, it is far easier to do.

C++ has no advantage over Rust in this regard : C++ and Rust does not have stable ABI. But both can use the C ABI when a stable ABI is needed.