Date: Wed, 4 Sep 2024 13:36:23 +0300 From: Anthony Pankov <anthony.pankov@yahoo.com> To: Rob Norris <robn@despairlabs.com>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <27925916.20240904133623@yahoo.com> In-Reply-To: <ZtgUQf0Ao7L9iQTD@crayon> References: <vdmg5zocd6wqcwc2bvzvzqn4bii2pwdc2r4mgnisukfkboj6nf@f7lv5quu4fjx> <CAOtMX2iDK3uN_oQgzzZAdoOZCfNsnvpefeZvKoTCRmPBhZywzA@mail.gmail.com> <CANCZdfqB1%2B-8BkpKwKoCM%2BzM4mCOFy63yHr1Pco7MnT1DFkb4w@mail.gmail.com> <knnsh327gxyvaajwrymvflnivf3tsnigyqw2d6etfhb4irft3x@ydkh3zmb6uch> <CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew@mail.gmail.com> <Zq69w1D7aYRiNdPx@kib.kiev.ua> <CAFYkXjmURZwBbrFL=uWT%2BDZ6h_qjjpoucxW4-3CpDhKn3XX2gg@mail.gmail.com> <jbuwu5qby7gb7abym3msutmojx26qhwcgyyb2cb6nfnf2w4a6h@otor5sawmss5> <dHVxEgS5MbvPceHSJF-G42LSk22NXsjKKwPzFagCTDNsKO4zgQpZKjteuGEAdO2ikPVIkP-3x6r2I1caTlM2YQrH3vjrWzgtRUVFtwsObOA=@proton.me> <202409031131.483BVdax004602@critter.freebsd.dk> <ZtgUQf0Ao7L9iQTD@crayon>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Rob, > What I actually want though is high-quality tools to make the kind of > problems I need to solve easier for my puny human brain to manage. Rust > is an approach to solving some of these kinds of problems. Other > approaches exist, have existed, and will exist in the future. I'm interested in your opinion. Do the tools like PROMELA-SPIN used for some (critical) part of a C-sourced project will give more correctness and less error prone compared to rewriting project in Rust? Is there an actual possibility to make such a tools integral part of project? Wednesday, September 4, 2024, 11:03:13 AM, you wrote: > On 03.09.2024 11:31, Poul-Henning Kamp wrote: >> But first and foremost: There has to be a good enough reason. > This is a near-enough hook for me to hitch a couple of thoughts on to :) > I work on ZFS, primarily on Linux with slowly increasing amounts on > FreeBSD too. By a long way, the kind of work that is the slowest and > most complicated is around complex locking sequences across multiple > threads. In most of these, getting it wrong leads to some kind of data > corruption that is usually impossible to track down. > The appeal of Rust for me, as for many, is that there are ways to encode > those kind of sequencing rules into the type system so that the compiler > can tell you where you got it wrong. But, I don't actually want Rust _as > such_. I like it a lot, I've written useful programs in Rust over the > last decade, and I'd be perfectly happy to use it in kernel and > filesystem development if it was available. > What I actually want though is high-quality tools to make the kind of > problems I need to solve easier for my puny human brain to manage. Rust > is an approach to solving some of these kinds of problems. Other > approaches exist, have existed, and will exist in the future. > This is mostly aimed at the "C is totally fine" crowd. I like C, and I'm > pretty good at it, but it absolutely not good enough for many kinds of > software. Frankly, I find "just get better at C" to be the most > infuratingly facile "argument" against Rust. > (And I would _love_ to get better at C. If substantially better C tools > are out there (on whatever axis you like to measure that on), then > they're either not visible to me, or they're not usable or > well-integrated enough to be in my standard kit). > There's plenty of plausible reasons not to include Rust in the base > system, many of them being discussed on this list, and I'm learning a > lot reading along. Just please don't pretend the problems it's trying to > solve aren't real. > Cheers, > Rob. > -- > Rob Norris | robn.au | robn@despairlabs.com > Working on OpenZFS, because there's a lot of data out there and it'd be > nice not to lose any of it. -- Best regards, Anthony Pankov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27925916.20240904133623>