6 ms·
In this vain, what about other options like beterC (a very capable runtime-less D subset)? What about allowing Ada into the kernel? The fact they are focussing
by gmueckl 7y ago
In this vain, what about other options like beterC (a very capable runtime-less D subset)? What about allowing Ada into the kernel? The fact they are focussing their evaluation on rust only is already an indication that they are playing the fanboy game to some extent. There are other languages out there that improve over C and can be used for systems programming.
- vardump 7y agoAlthough we were talking about Rust here, I'd love to see those evaluated and compared between each other as well. This is nothing away from BetterC and other languages. If anything, this could open up ways to using languages other than C in kernel development. That said, I don't think there's room for more than maybe two languages for the critical kernel components even in the long run. Not because of technical limitations, but human ones.
- roca 7y agoSomeone would need to make the case for them. AFAIK neither Ada nor BetterC prevent memory safety bugs like Rust does... for example it appears neither of them prevent use-after-free of dynamic heap allocations, a pretty common sort of exploitable memory safety bug.
- gmueckl 7y agoAll that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
- jhomedall 7y agoThe only types in the Rust standard library that do reference counting are `Rc` and `Arc` (which are both implemented in Rust). Borrow checking is done statically.
- gmueckl 7y agoBut borrow checking doesn't cover heap allocations.
- jcranmer 7y agoYes it does. Borrow guarantees that the lifetime of the borrower does not exceed the lifetime can provide. Heap allocations have a lifetime--the start of a Box<> is the call to malloc, and the end is the call to free. Borrow checking prevents you from using the value after the free.
- geofft 7y agoHuh? It absolutely does, you can store a Box<T> somewhere and get multiple &'a Ts out of it, where 'a is limited to the lifetime of the box, but only one &'a mut T out of it at once.
- gmueckl 7y agoNo, this does not mean that the borrow checker understands heap allocations. Box is just a wrapper to shoehorn heap management into the stack based analysis that the borrow checker is able to perform. In other words, Box<> is just the equivalent of std::unique_ptr in C++.
- dthul 7y agoI see what you mean, but I think there are two orthogonal issues here. One is the ownership/lifetime of the heap allocation. That is indeed coupled to a stack object, because non-stack bound lifetimes can (with the current state-of-the-art) not be analyzed at compile time. Calling this shoehorning is strange, that's the whole idea of RAII. The other issue is borrows of heap objects, which the borrow checker can of course handle since they are no different than borrows to stack objects.
- roca 7y agoYes, it's very similar to unique_ptr. The point here is that you can implement many kinds of complex and useful heap-allocated data structures in safe Rust code, without any reference counting, and the compiler will verify that you have no use-after-free bugs, or any other kind of memory-safety bug. The same is not true of (pre-SPARK) Ada, or C, or C++, or BetterC.
- epage 7y agoThe borrow checker is what is being referred to and has no runtime overhead. Now, an environment without a GC will use ref counting sometimes but it will regardless of C, Rust, or C++
- gmueckl 7y agoReference counting has well known issues that are independent of the programming language: - can't deal with circular references without user intervention - storing the reference counter is hard: either it clobbers a whole cache line or it ruins memory alignment - atomic reference counting has the potential to utterly ruin runtime performance unless it used extremely carefully
- steveklabnik 7y agoThe borrow checker does not use reference counting.
- littlestymaar 7y agoI'm pretty sure you are confusing Rust (borrowck, done at compile-time, no runtime overhead) and Swift (where every object is reference-counted, with some, sometimes big, overhead).
- pjmlp 7y agoIn Rust GUI code is quite common to have Rc<RefCell<>> scattered across all widgets callbacks.
- littlestymaar 7y agoI assume you're talking about GTK or Qt? AFAIK they are the only viable options for Rust GUI at the moment, but their paradigm doesn't fit well with Rust ownership and you need to use ref-counting everywhere as you said. I don't think the problem is inherent to GUI in general though.
- ajxs 7y agoSPARK Ada has a concept of pointer ownership that would offer similar protections: https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark
- roca 7y agoThat is true, but SPARK is more heavyweight and less mature than Rust. If someone wants to make the case that SPARK would be a better approach than Rust to writing safe code in the Linux kernel, they should go ahead, but I haven't seen anyone make that case.
- pjmlp 7y agoHow is SPARK less mature than Rust given its use in the industry?
- roca 7y agoI'm talking about SPARK-with-pointers. As of June this year, that was still only available as a preview: > If you now feel like using them, a preview is available in the community 2019 edition of GNAT+SPARK.
- pjmlp 7y agoFair enough, however SPARK-without-pointers is even more constrained in what concerns dynamic allocation, basically it is forbidden and everything must be known at compile time.
- roca 7y agoThis shifting-the-referent bug annoys me, because it happens with C++ too. "C++ is really mature and there are so many C++ projects and developers!" "Yeah but it has these problems..." "Just use C++17, it solves all that!" ... but C++17 is not the language that is really mature and that all those C++ projects and developers are using.
- ajxs 7y ago
- littlestymaar 7y agoLinus' opinion on Ada (vs Rust): > We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. From: https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-...
- gmueckl 7y agoNot sure whether I agree with him calling Modula-2 and Ada disasters. But his statement about programming languages not solving problems by themselves applies to a lot more than just operating systems.
- deleted 7y ago[deleted]
- Wheaties466 7y agoComplete opinion here but this is my take on anything Linus. Linus has learned that anything he says is potentially going to quoted and quoted over and over again. So it seems like he only talks in extremes now. I always tend to look at it like he likes rust more than the other two and nothing more. If he said the other 2 are alright, people would run with that quote, and vice versa.
- johnisgood 7y agoI do not see any reasons given for why he considers Ada a disaster. Cannot really do much with this opinion as it is.