Date: Sat, 20 Jan 2024 20:44:16 -0800 From: Ihor Antonov <ihor@antonovs.family> To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <ef4ad207-5899-42b6-8728-bc46f1417e9e@antonovs.family> In-Reply-To: <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <1673801705774097@mail.yandex.ru> <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/20/24 14:31, Warner Losh wrote: ... As someone who's been writing rust since 2018 both professionally and for personal projects I want to share my perspective on the question. I've come full circle from being a zealous rust fan-boi and now back to being a careful skeptic. There is a lot of ground I want to cover in one email so I excuse my style, I will be happy to elaborate and provide more data to back up my statements. Rust in base ------------ I think the consensus in this thread has already reached the right conclusion. This would be a absolutely counter-productive for the following reasons: - Rust needs its own special brand of LLVM. We all know how long it takes to build. - Rust compiler is not usable without Cargo, and Cargo is a fast-evolving project that will need constant upkeep. - There is no way to bootstrap rust compiler other than by using previous version of their compiler. Effectively you start from a blob from a third party that you need tp trust. This can be a huge problem for people who care about supply chain security. C/C++ compilers can be bootstrapped in a reasonable amount of steps almost from nothing (google GNU Mes, stage0) - Rust and its entire ecosystem has severe dependency bloat problem. It is a 'left-pad' minefield. For those who want proof take a look at Cargo.toml files of Cargo and rustc projects - they depend of half of the Internet. Getting a closed-loop self-sufficient set of crates is almost impossible. Rust compiler is not self-hosting and its dependency set has unbounded growth problems. - There could also be legal problems, as Rust Foundation is not a very adequate or mature entity. Not so long ago they were trying to ban all "unapproved mentions of the word Rust", waving their trademark left and right. Search for "rust drama" on the internet to find more details. Rust in General --------------- Rust's ecosystem is infected with async, aka. function coloring problem. It creates so much more pain that writing rust becomes nearly impossible. But hype-driven crowd has not yet realized it. Read more [2] Rust in Ports ------------- Something like mentioned `freebsd-rust` separate repository could make sense, with careful crate curation to maintain self-sustaining offline-build capable set. And avoid async rust at all costs. The question here - what is the "contract" here? I dont think we are ready to force Rust on every FreeBSD src consumer. Alternatives ------------ I never thought I would ever say this - but C++20/23 is actually not that bad. C++20 modules are finally here and they actually solve header problems. Linux kernel developers were discussing C++ last week here [1] for use in Linux kernel. Lots of good reasons expressed. Replying to Warner's comment: > We have had C++ in base for many years, but I don’t see any good libraries > for CLI, logging, JSON, etc. Despite being full time FreeBSD user since 2017 I didn't know we needed those (and I am happy to contribute) I will say that this is not a C/C++ problem and Rust is definitely not a solution It is a FreeBSD problem and there are 2 aspects to it: 1. Social Aspect - we have a problem with attracting contributors: 1.1. A path to becoming a src contributor is vage and unreasonably long. 1.2. Unclear project directions(from a newcomers perspective) Is FreeBSD a stagnation cult? Do we want to re-implement every linux feature? Were does the Project go? Who is in charge? How decisions are made? 1.3 Unclear who needs what. It is the first time I hear Allan needs help with writing code. (Allan - expect a dm to discuss details, I'm happy to help) 2. Technical Aspect 2.1. FreeBSD has tooling problem: bespoke BSD Makefiles are not making it easy to start a new project or port new code. IMHO we need to import Ninja and Cmake into base to make it easy write and _test_ more C/C++ code. Phabricator forces everyone to have PHP. Bugzilla is a retro-vomit from 2000, Jenkins is a devops nightmare from hell (speaking from a decade of personal experience) 2.1. FreeBSD has information fragmentation problem: Where was that piece of information? A PR on github? Review on Phab? Maybe it is in the wiki? Check the handbook to be sure. Oh, right, it was that patch attached to a bugzilla comment. Go check Jenkins if the latest *post* commit run as succeeded... Summary ======== As much as I love the idea of Rust, I don't think it is going to solve our problems. Rust is hype tech at the moment and 2 years down the road compaines will start to realize how much maintenance of async rust code actually costs. I would very much like to see us simplify contribution track. On the technical side - migrate off of phabricator to gitea and import cmake and ninja. Kill bugzilla and build a decent pre-commit CI. --------- [1] https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/#t [2] https://blog.hugpoint.tech/avoid_async_rust.html Ihor Antonov -- Ihor Antonov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef4ad207-5899-42b6-8728-bc46f1417e9e>