171–180 of 365 posts
Earlier quoted context omitted.
Can someone cite a peer reviewed study that supports the belief that rust increases safety or productivity in actual use?
> rust increases safety or productivity in actual use? compared to what?
Earlier quoted context omitted.
That's a front end?
Compile C to Rust! Easiest language migration ever.
What kind of performance hit is rewriting part of the kernel in Rust going to entail when it comes to compiling the kernel? How many platforms will cease to be able to compile their own kernels? The article says there will be some, but doesn't give numbers. More worryingly, the article also says that only some platforms will be "Rusted" in this manner, splitting the codebase into "mainline Rust" and "obscure platform…
The point is that if you implement a driver for a device that only exists on hardware that supports LLVM then there is no problem.
(The further point is that it's impossible to have this discussion here.)
One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…
Earlier quoted context omitted.
> (Formally verified is shifting the goal posts here: the bar is just "has a native library".) It is, but it is for a good reason - ATS formally verifies your safe functions, so you only need to implement your proof once and make a compiler agree with you, and then you can save on a community-driven code-review process. Rust, on the other hand, provides safety guarantees only for a subset of safe guarantees that ATS…
It's moving the goal posts and changing the point of the discussion. We can equally well say that that "Rust formally verifies your safe functions", and that this reduces how much code review is required... it's a matter of degree and specifics. Focusing on pointer manipulations is also misleading: it's entirely true that it's dangerous, but most Rust code does not need to do any sort of raw pointer manipulation. For…
You cannot say that while this kind of CVE is possible https://gts3.org/2019/cve-2018-1000657.html and as long as Rust is not capable of performing safe pointer manipulations. The above issue may be solved for VecDeque in stdlib, but what about other data structures and algorithms in the wild?
> Focusing on pointer manipulations is also misleading
Remember that the discussion is happening in the topic about brining Rust into well-established C codebase, and C uses pointer-based arithmetics all the time, sometimes the whole algorithms are implemented this way because it brings efficiency to lower-level interfaces that are supposed to be very fast. If the motivation to bring a new tool is pronounced as "let's make it safe", why should we allow the argument to fallback into the "unsafe Rust" territory?
> For instance, there's extensive work on operating systems and other low level code that involves both inherent unsafety due to hardware specifics
I'm not going argue against that, because it's not related to the current topic related to Linux Kernel.
> Finally, if you are happy to cherry-pick specific examples, https://bluishcoder.co.nz/2017/02/22/borrowing-internal-poin.... discusses a case where Rust is able to prove more things safe than ATS 2 (at the time of writing).
it's not more, it's one specific example. Shall we now enumerate all the things that both languages are able to prove? I think we should, to make it clear what the differences are and what is possible to prove safe. That's exactly my point about comparing brining Rust into existing C codebases with alternative tooling available specifically for C codebases.
Earlier quoted context omitted.
The Linux kernel is fairly modular, I could definitely imagine rewriting subsystems by subsystems with fairly good ergonomics and safety. Like rewrite serial_core.c in Rust and then let people write serial drivers in Rust. Then the SPI code. Then the I2C. Then USB etc... Easier said than done of course, and definitely a huge effort especially for such a huge project as the Linux kernel, but there's also a significant…
> Also "the safety guarantees that Rust provides are neither unique nor complete", while technically true, is also borderline FUD-y. At least you should expand on what you have in mind here, because I doubt that there exists a programing language that deals with low level hardware configuration that could ever provide "complete guarantees" about anything. I meant inability to implement within the boundaries of safe R…
Rust routinely proves these to be safe.
> safe pointer arithmetic programming
You can't directly prove the pointer arithmetic safe with the compiler, but we routinely write a small amount of unsafe code which the programmer is confident in (and depending on the project that can mean an informal proof), and then re-use the data-structure that unsafe code created millions of times.
A ring buffer is a great example. Vecdeque is implemented once in the standard library, everyone who uses Vecdeque can do so in completely safe code provided the small amount of code in Vecdeque is safe.
This is orders of magnitude better than C, where every user of the ring buffer might make a mistake and cause a bug (or at least the API has no way of communicating that that is not the case, and in general the type system isn't expressive enough to make APIs that force that to be the case). It's not clear that taking the next step to proving the ring buffer implementation itself is correct to is actually worth the effort (it's not clear that it's not, but you need to make that cost benefit analysis, and I highly doubt it would be anywhere close to uncontroversially the case).
Earlier quoted context omitted.
> Also "the safety guarantees that Rust provides are neither unique nor complete", while technically true, is also borderline FUD-y. At least you should expand on what you have in mind here, because I doubt that there exists a programing language that deals with low level hardware configuration that could ever provide "complete guarantees" about anything. I meant inability to implement within the boundaries of safe R…
> stack-allocated closures Rust routinely proves these to be safe. > safe pointer arithmetic programming You can't directly prove the pointer arithmetic safe with the compiler, but we routinely write a small amount of unsafe code which the programmer is confident in (and depending on the project that can mean an informal proof), and then re-use the data-structure that unsafe code created millions of times. A ring buf…
it is, what about other similar cases of using pointers in other data-structures and algorithms that are not part of the Rust standard library?
I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target.
With all the hype and apple funding LLVM gets, it could have been better.
Earlier quoted context omitted.
Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here. https://news.ycombinator.com/newsguidelines.html
What would be the proper way of informing those who are interested in the topic about available alternatives? I assume not everyone follows the same topics and there may be people who see the presented information and the relevant references for the first time.
Earlier quoted context omitted.
> stack-allocated closures Rust routinely proves these to be safe. > safe pointer arithmetic programming You can't directly prove the pointer arithmetic safe with the compiler, but we routinely write a small amount of unsafe code which the programmer is confident in (and depending on the project that can mean an informal proof), and then re-use the data-structure that unsafe code created millions of times. A ring buf…
> Vecdeque is implemented once in the standard library it is, what about other similar cases of using pointers in other data-structures and algorithms that are not part of the Rust standard library?
As it turns out most code isn't datastructures with unique memory requirements (i.e. that can't be implemented in terms of other datastructures), most code just re-uses existing datastructures.