[HN Gopher] The Case for Rust in the base system
___________________________________________________________________
The Case for Rust in the base system
Author : pjmlp
Score : 158 points
Date : 2024-01-21 18:27 UTC (4 hours ago)
(HTM) web link (mail-archive.freebsd.org)
(TXT) w3m dump (mail-archive.freebsd.org)
| codetrotter wrote:
| That would be amazing :D
|
| I run FreeBSD on my servers and use scripts to manage jails and
| send and receive ZFS snapshots between hosts.
|
| I've been wanting to write some more robust tools of my own for
| those things, than the scripts I have now, and my favourite
| programming language is Rust!
| yjftsjthsd-h wrote:
| Can't you do that now? The article lists ports tools doing
| those things already
| codetrotter wrote:
| Sure I can but Rust in the base system would provide:
|
| - A stable target, and
|
| - Lots of FreeBSD specific Rust code to read from expert
| FreeBSD programmers, as guidance
|
| - Probably better ability to build ISOs of my own that
| include the base system and my jail and ZFS management Rust
| programs, so that I can install servers from that ready-made
| ISO and have less post-install work to do
| zilti wrote:
| In terms of server install ISOs, I can highly recommend
| mfsBSD, and also cloud-init to trigger post-install setup
| NewJazz wrote:
| I am not familiar with FreeBSD's development model. What
| constitutes the "base system"?
| gavinhoward wrote:
| The kernel, libc (they tie libc to the kernel unlike Linux),
| and a standard suite of programs.
| GrumpySloth wrote:
| The stuff that's included in the system after a standard
| install, before you install any additional stuff. It's all in
| one repository and it's maintained by the FreeBSD project.
| Stuff like the kernel, libc, utils, dtrace, compilers needed to
| build base, ... Basically everything that's needed for a usable
| system. It's updated all together through binary patches, not
| separately through packages like on Linux. When you want
| something more, you either compile it from source using
| Makefiles stored in a repository called "ports" (the Makefiles
| download the tarballs with source code, verify their checksums,
| build them etc), or you install pre-built packages using the
| pkg package manager.
|
| The FreeBSD project tends to like to slim the base system down.
| E.g. some years ago they removed Perl from the base system. So
| out-of-the-box the only scripting language that's available is
| shell. In contrast, OpenBSD has more stuff in its base system
| and on the subject of Perl they doubled down on it (their
| package manager e.g. is written in Perl). It's also visible,
| when you download the base system repos for each of them and
| run tokei to find out the numbers of LOC. (I don't remember the
| numbers off the top of my head.) That said, FreeBSD still
| includes a full LLVM toolchain due to the rule "base builds
| base", and LLVM is... a lot. It's the biggest source of bloat
| in my jails to be honest. I keep meaning to find out if I can
| remove it from them.
| ThePowerOfFuet wrote:
| This is a perfect and concise description.
| GrumpySloth wrote:
| Not after I added the second paragraph. ;)
| hartator wrote:
| Very naive question. What's the main selling point of Rust
| besides being stably sponsored by Mozilla?
| eropple wrote:
| In short: the type system is significantly more expressive and
| encourages domain modeling that tends to lead to fewer errors;
| "if the compiler says it's OK, it'll be OK" isn't strictly true
| but it's often pretty close. Rust also offers stronger
| guarantees around memory safety than C, as well as C++ as
| commonly practiced. (Which is to say, you can write very
| memory-safe C++, but you will work at it.)
| chaxor wrote:
| The build tools are incredible. That's the main reason many
| people love Rust. For kernel dev however, the memory safety is
| a big win.
| paulddraper wrote:
| Statically checked memory management
|
| Advanced typing
|
| Build tools
| adrianN wrote:
| Rust's type system prevents memory safety bugs because it
| reasons about object lifetimes statically. At the same time
| rust allows you to write systems code on bare metal.
| dosshell wrote:
| > it reasons about object lifetimes statically.
|
| How does that differ from RAII?
|
| I think i misunderstand you or lack knowledge, because this
| sounds exactly like RAII.
|
| I know that rust has major compile time checks, but saying
| that the difference is that it reason about life time as
| difference to c++ is misleading. I think the major point of
| c++ compared to c is that c++ "reason about object lifetime
| statically" with deconstructors and RAII. And saying that
| rust do this and implying c++ don't is misleading.
| oconnor663 wrote:
| Rust and C++ work very similarly with respect to objects
| you _own_. In both languages they get cleaned up by a
| destructor when they go out of scope. However, Rust also
| has a lot of language features that deal with objects you
| _borrow_ , i.e. have a pointer to. In C++ you might make a
| "use-after-free" mistake and hold a pointer to an object
| that's already been destructed, which can lead to all sorts
| of memory corruption. In Rust, the same mistake almost
| always results in a compile-time error. The part of the
| compiler that enforces all this is called the "borrow
| checker", and getting used to the borrow checker's rules is
| a big part of Rust's learning curve.
|
| One thing C++ programmers might be interested to learn, is
| that this doesn't only apply to simple variables and
| references; it also applies to library data structures and
| their methods. The Rust compiler doesn't really "know" what
| the .clear() method on a Vec does, but it knows enough to
| prevent you from calling that method while you're holding
| references to the Vec's elements.
| baq wrote:
| > getting used to the borrow checker's rules is a big
| part of Rust's learning curve.
|
| It's also a big part of C and C++'s learning curves, it's
| just that the compiler doesn't tell you about it; you're
| being taught by segfaults and silent memory corruption
| instead.
| oconnor663 wrote:
| Very true. My hot take on this is, if you want to learn C
| or C++ "properly" (not just well enough to get your
| homework done, but well enough to write medium-size
| programs that pass ASan/UBSan/TSan), the fastest way is
| to learn Rust first. This is emphatically _not_ because
| Rust is quick to learn, but rather because ownership and
| borrowing discipline takes years of mentorship to absorb
| in C and C++, and plenty of career programmers never
| really get it.
| zozbot234 wrote:
| > Rust and C++ work very similarly with respect to
| objects you own.
|
| There is one major difference. In Rust you can memcpy
| objects you own to a different base address and they will
| still work, unless they're pointed at by a Pin<> type (as
| such, code that requires objects to stay put in memory
| must take a Pin<> reference. This arrangement may
| potentially be replaced by a special "?Move" trait in
| future editions of Rust). C++ pins all objects by default
| and allows objects to have custom "move" constructors, to
| sort of enable them to be moved elsewhere.
|
| In C++, objects that get "moved" must leave behind
| something that can be destructed cleanly; Rust has no
| such limitation, at least wrt. ordinary moves. Arguably
| the closest thing it has to a C++ move is the .take()
| pattern, which leaves a default-constructed object
| behind. But this is rarely used.
|
| The general tradeoff is that the Rust pattern memcpy's
| compound objects more often, but has less gratuitous use
| of the heap and less pointer chasing compared to
| idiomatic C/C++. This is a valid choice once one has the
| compiler support that Rust provides.
| oconnor663 wrote:
| If anyone's trying to follow along but wondering what the
| heck we're talking about, I have a video about this :)
| https://youtu.be/IPmRDS0OSxM?t=3018
| masklinn wrote:
| > However, Rust also has a lot of language features that
| deal with objects you borrow
|
| An other major safety difference is that Rust uses
| destructive moves, once a binding is moved-from it
| becomes invalid / inaccessible (and it won't be
| destroyed).
|
| In C++, a moved-from object is in a "valid but
| unspecified state", so it must be destructible (because
| destructors always run) but any interaction with the
| object other than destruction may be UB, and the compiler
| won't tell you (in the same way it won't tell you about
| borrowing issues whether it's UAF, invalidation, ...).
| avgcorrection wrote:
| The language features.
| formerly_proven wrote:
| I don't think Mozilla has had any major sponsorship role for a
| few years now?
| hartator wrote:
| > https://internals.rust-lang.org/t/mozilla-is-hiring-for-
| the-...
|
| It seems that some Rust folks are still on Mozilla payroll.
| steveklabnik wrote:
| That post is from 2019, the layoffs of the teams were in
| 2020.
|
| Mozilla is still a member of the foundation, so they do
| support it in that sense, but they are one of many
| companies that do so.
| oconnor663 wrote:
| There are two very broad set of features:
|
| 1) Memory safety. If you live in the world of kernels and
| embedded code, your options are mostly C, C++, and (as of just
| the last few years) Rust. Of those, only Rust reliably prevents
| memory corruption mistakes like use-after-free.
|
| 2) Being a 21st century language. Rust has a lot of features
| that any new language would be expected to have these days: a
| unified build system, a library ecosystem that the build sytem
| knows about, slices over arrays and vectors, UTF-8 strings,
| convenient ways to de/serialize JSON, something like
| async/await, etc. This makes it competitive with languages like
| Java and Python for doing "everyday stuff", where realistically
| ~no one would use C. The main downside of Rust in a Java/Python
| sort of context is that the learning curve is a lot steeper.
|
| A couple other notes:
|
| - Some of nice 21st century features (like JSON) go away when
| you're writing embedded/kernel code, but others still work.
| Embedded ("no_std") Rust still has enums, error handling,
| slices, iterators, and sometimes even async/await. Those
| quality-of-life features are hard to replicate in C, even if
| you believe your code is 100% bug free :)
|
| - If you know you're going to be writing multithreaded code,
| Rust's thread safety features are really unmatched. A lot of
| the same machinery that gets used for memory safety also turns
| out to be useful for thread safety. Libraries like Rayon make
| it surprisingly convenient to write multithreaded code, while
| also catching a huge percentage of mistakes at compile time.
| (Deadlocks are still possible though.)
| hartator wrote:
| > Memory safety
|
| Another very naive question. Are memory safety concerns from
| a cybersecurity standpoint or from less-dev error standpoint?
| eloisant wrote:
| Mostly from a less-dev error standpoint but I think you
| gain in cybersecurity as well, as the language won't let
| you write code that accesses memory in places it's not
| supposed to.
| masklinn wrote:
| It's mostly from the cybersecurity standpoint actually,
| at least for large projects / companies. MS, Chromium,
| Project Zero, Mozilla, have pretty consistently found
| that north of 70% of vulnerabilities were rooted in
| memory safety.
|
| The dev-error is broader language guarantees, which
| dovetail into memory safety but are useful on their own
| e.g. data race safety, rich type system, ...
| CharlesW wrote:
| Both, and they're related in the sense that software errors
| can become exploitable vulnerabilities. This is a handy
| summary by the NSA: https://media.defense.gov/2022/Nov/10/2
| 003112742/-1/-1/0/CSI...
| oconnor663 wrote:
| Both for sure, and which one is a bigger deal depends a lot
| on context.
|
| Cybersecurity issues make Rust a good choice for writing
| parsers for example. File format parsers handle scary data
| from the internet (JPEG, X.509, etc), and those often
| contain addresses and offsets that turn into raw pointers
| in the implementation, so they're a common source of
| security bugs. At the same time, they're usually isolated
| behind a reasonably tight API, so it can be practical to
| rewrite them in Rust even when all the calling code is
| still C or C++ or even Python.
|
| On the other hand, fewer-mistakes-sucking-up-dev-time is an
| especially big deal in multithreaded code. There was a
| story from Mozilla about how they'd tried to add threading
| to part of Firefox (I think it might've been the CSS
| engine?) and failed multiple times, but then they succeeded
| in Rust. Threading bugs tend to be painful to reproduce,
| and Rust's compile-time checks are extremely valuable
| there.
| brobinson wrote:
| Microsoft, Google, and other companies have all determined
| that about 70% of CVEs are memory-related. Here's the US
| government's take: https://www.cisa.gov/news-
| events/news/urgent-need-memory-saf...
|
| These memory-related exploits disappear with Rust aside
| from in "unsafe" blocks (possibly the worst named keyword
| in any language... it should have been called "trusted"),
| and that means you have a smaller and more easily auditable
| attack surface for these types of memory-related exploits.
| Some code (e.g., FFI) can't be verified as memory-safe by
| the Rust compiler at compilation time so "unsafe" is there
| as an escape hatch. I've written a bunch of Rust since 2014
| building things like webservers, realtime futures
| processing algorithms, MEV bots, etc., and I've only had to
| use "unsafe" a few times.
|
| I've also worked in security on products at Fortune 100
| companies, and C is a constant nightmare for CVEs. I think
| I have PTSD from having to update libcurl. The more
| software we have written in memory safe languages, the
| better off we all are.
| wredue wrote:
| Just to avoid any "cyclist rides more aggressively when
| wearing helmet" type behaviour:
|
| It's probably worth nothing that that vast majority of,
| and of large scale attacks, is basic shit that has
| nothing to do with memory safety.
|
| There's benefit to memory safety, but just cause you're
| wearing a helmet doesn't mean you're completely safe.
|
| Additionally, it's not Google overall, but chromium
| project that find this, as well as not Microsoft overall,
| but specifically Windows. These are two projects that
| will naturally see a much higher rate of memory safety
| issues.
| logicprog wrote:
| Both. On the one hand, what Rust essentially forces you to
| do is just to program according to proper RAII principles
| that an experienced C++ programmer would already know and
| should already be using (especially once polonius lands),
| it's just better at checking failure to do so than any
| sanitizer or linter could ever be, so it's a way to avoid
| having to deal with annoying, hard to track down memory
| bugs. And in fact, the greater confidence static lifetime
| guarantees give you allows you to do things like using move
| semantics more where C++ programmers would have to use
| copies out of defensive programming. That's predominantly
| why I personally use it, as far as memory safety goes. On
| the other hand, [around 60-70% of serious security bugs
| have been proven to be caused by memory safety across many
| different
| projects](https://alexgaynor.net/2020/may/27/science-on-
| memory-unsafet...) so if you _do_ care about security in
| what you 're doing, it's a boon there too.
| kstrauser wrote:
| Tomato, tomato.
| secondcoming wrote:
| You've got to be trolling
| jcranmer wrote:
| I can't give you just one selling point, because Rust has two
| main competitive features, and it's hard for me to say which
| one is enticing FreeBSD more here:
|
| 1. Rust has a more modern sense of computer primitives than C
| does. For example, C has the char-short-int-long-long long set
| of types which correspond to 8, 16, 32, and 64 bit integers in
| practice (and yes, 5 types for 4 sizes), whereas Rust has
| u8/u16/u32/u64. Rust also has a builtin slice type, which is a
| desperately needed notion of pointer + size of array, and C's
| lack of such type has proven to be the source of much malware.
| The standard library is also somewhat richer too, you have
| better support for things like threads or networking than C/C++
| does. But note that Rust is still like C in that it has a very
| thin runtime layer, and can also go a step further and have
| "no" standard library at all, which is necessary in several
| contexts.
|
| 2. The borrow checker. Effectively, use-after-free (or any
| other lifetime issue) vulnerabilities become compiler errors,
| and even many kinds of data races are also turned into compiler
| errors. Also it can do things like make iterator invalidation
| issues a compiler error as well.
| logicprog wrote:
| One of the biggest things about Rust for me is that it's
| essentially Prometheus, bringing the fire of modern languages
| and more advances PL theory to systems programming, which imo
| is sorely needed. We don't need a 10% better C or C++, we need
| a huge jump for the field. Rust I think does this. They have:
|
| 1. A type system that's deeply inspired by OCaml, a language
| that's designed and used by a lot of programming language
| research people and is widely praised (just look at how every
| other language -- C#, Java, Kotlin -- is suddenly trying to
| pile half baked imitations of ML features like ADTs and deep
| pattern matching onto their existing OOP type systems), except
| they've both imemented the type system _correctly_ and _fully_
| , and _also_ filed off all the warts and awkward features, and
| replaced OCaml 's verbose and underpowered first class module
| system with Haskell style type classes
|
| 2. got amazing, highly flexible and generalized iterator and
| monad support (you can use iterator methods _on_ monads),
| basically second only to Haskell itself, that compiles down to
| the equivalent of hand written assembly code loops
|
| 3. an error handling system using monads that neatly sidesteps
| the issues with both traditional C style error handling and
| exceptions that combines with point two in an exponential curve
| of awesomeness for error handling
|
| 4. hygienic (from Racket) _and_ procedural (eg Common Lisp)
| macros
|
| 5. And finally ofc their statuc memory safety and race
| condition safety, which is based on linear types ala Idris.
|
| But most importantly, Rust's designers seem to IMO have
| carefully picked only the advanced programming language
| features that tend to make your code _clearer_ as well as more
| correct, and help you model problems at the right level of
| abstraction to be intuitive, and also only features that can be
| implemented in a way that is as performant as the equivalent
| C++ code, roughly speaking at least. They also seem to have
| been very careful with how they integrate and implement
| everything in order to uphold those goals.
|
| So you get to have 90% of the power of a language like Haskell,
| in a language that performs like, and has the low level
| capabilities of, C++, with the extra benefit of -- for instance
| -- less dogmatic puritanism and more deterministic and
| comprehensible performance and execution properties then
| Haskell, and less Lovecraftian horror full of surprise gotchas
| than C++.
|
| It's kind of like the ultimate pragmatic language for someone
| like me who has gone deep into pure functional languages and
| other esoteric languages and wants to have as much as of that
| goodness as is practical.
| tialaramex wrote:
| By the way it's not "race condition" safety. Race conditions
| are a completely normal part of our world and so Rust can't
| magically fix race conditions. Bob's going to shred all "10+
| year old" paper records "after lunch" and Hannah needs the
| paper customer list from 2003 for the 2:30pm meeting? Well
| that's a race, good luck, Rust can't help. However, (safe)
| Rust can eliminate _data races_ , a very weird special case
| caused by the difference between how you imagine the computer
| works and how it actually works.
|
| A data race goes like this: At least _two_ simultaneous
| execution contexts (maybe threads for example) are looking at
| the same object X and at least _one_ of them changes it, but
| there is no particular _order_ of these events agreed between
| these contexts.
|
| In your head, even with parallel computing everything _seems_
| to happen in some sort of global order. A happens before B,
| or B happens before A. This is called Sequential Consistency,
| and it 's a lie, the machine doesn't actually work like that,
| but humans can't really understand non-trivial software
| without this lie, so, all our high level software (and when I
| say "High level" I mean like the C Programming Language)
| pretends sequential consistency is always preserved and goes
| to some lengths to achieve that.
|
| In Rust you can go about your business. (Safe) Rust promises
| this is true and it'll make damn sure. But in many languages
| like C or C++, actually you can very easily inadvertently
| construct a data race, revealing that it was a lie and if you
| do so _all bets are off_. Since you probably can 't reason
| about your program's behaviour anyway, they figure "fuck it"
| and that's Undefined Behaviour.
|
| Bonus round for languages which do better than most: Go says
| if you race a _trivial_ object like an integer, you lose
| Sequential Consistency but this isn 't automatically UB.
| Complex races are UB.
|
| Java says races are never UB, but they do lose Sequential
| Consistency. Your Java Program is now very, very difficult to
| understand, but it's not nonsense.
|
| OCaml goes furthest, it says your race isn't UB _and_ it
| offers very tight constraints on what 's wrong. OCaml's work
| on this is relatively new, so it may be a while before we're
| confident whether this is a manageable situation normal
| humans (well OCaml programmers) can handle.
| faitswulff wrote:
| > fusefs tests. Absolutely impossible to do in C. I considered
| Rust, but went with C++ so they could live in base. They are too
| closely coupled to fusefs(5) to live out-of-tree.
|
| Can anyone comment on why this is impossible in C?
| loeg wrote:
| "Impossible" is mild hyperbole. Googletest makes it relatively
| easy to structure complicated mocked tests in a way that is
| verbose but not impossible in C.
| bluGill wrote:
| Not impossible, but a big pain. vtables can be done by hand,
| but C++ does that for you. I don't know rust or the problem
| they are talking about, but I believe something like that.
| yjftsjthsd-h wrote:
| My first thought was that rust doesn't target as many platforms
| as FreeBSD (at least not well), but looking at
| https://www.freebsd.org/platforms/ apparently the answer is that
| FreeBSD doesn't support many platforms anymore so I guess that's
| no longer a problem.
| loeg wrote:
| Yeah, but Rust tier 1 is only x86, x86_64, and arm64. And only
| Linux. That excludes MIPS, PPC, and arm32, all of which FreeBSD
| continues to support to varying degrees. x86_64-FreeBSD is a
| Rust tier 2 "it might work" target, as are arm6/7 and PPC. MIPS
| is Rust tier 3 "we don't build for it or test on it."
| vlovich123 wrote:
| Surely that's not set in stone right? Like FreeBSD could
| contribute money & resources to hook up CI machines to make
| it a tier 1 target?
| bluejekyll wrote:
| My understanding of the tiers of support is based on the
| level of commitment from the community. That is, if the
| FreeBSD folks wanted to make it a Tier 1 target, they can,
| "If running the testsuite requires additional infrastructure
| (such as physical systems running the target), the target
| maintainers must arrange to provide such resources to the
| Rust project, to the satisfaction and approval of the Rust
| infrastructure team." -- https://doc.rust-
| lang.org/nightly/rustc/target-tier-policy.h...
|
| This seems very much within the realm of the FreeBSD's
| capabilities.
| ijustlovemath wrote:
| From that link, it looks like FreeBSD is beginning to phase
| out MIPS and PPC entirely, and 32-bit ARM is nearing phase-
| out. It seems entirely reasonable that over the next few
| years it takes to integrate a Rust core that the "blessed"
| architectures of both projects will be aligned
| midmagico wrote:
| FreeBSD can't really be said to support native-hardware PPC.
| Also don't forget riscv. Which it also doesn't really support
| in native hardware.
| tialaramex wrote:
| You may have been thinking of NetBSD. NetBSD prides itself on a
| very broad platform support.
| midmagico wrote:
| Maybe in the 1990s. Now, try getting it running even on a
| network edge platform like those from Netgate. NetBSD's
| hardware support is singularly unstable and unusable.
|
| Most new platforms port to Linux, commit drivers to the Linux
| kernel, and ignore the other platforms. The other platforms
| don't really seem to bother anymore, unfortunately. Things
| have bit-rotted to such an extent that FS will destroy large
| amounts of data and.. nobody seems to notice. Kernel panic
| reports are ignored. Debuggers fail to set functional
| breakpoints on native hardware. CPU quirks that need
| workaround to prevent panics are never committed.
|
| Meanwhile, _developing_ this kind of expertise is about as
| far from the minds of younger experimenters and hackers now
| as baking cakes and permaculture gardening were from the 00s
| hardware hackers decades ago. Not only is it far from the
| minds of younger experimenters, but even attempting to
| develop it hits a hard wall of hardcore, draconian
| behavioural purists, secops fashionistas who deride
| essentially any burgeoning attempts at writing drivers, and
| language revolutionaries who rage extensively at people for
| writing any new code in any language but their own favourite.
|
| The situation is pretty harsh and it's likely not going to
| get any better anytime soon.
| yjftsjthsd-h wrote:
| No, I meant FreeBSD, though NetBSD is (much) further on the
| same spectrum. If I read that Darwin or NT were looking at
| using Rust, I'd figure that was easy enough; they more or
| less only target x86 and ARM, which are mostly well-covered
| by Rust. If NetBSD said they were moving to Rust... I dunno,
| I'd assume that either Rust had _really_ changed their
| approach to platform support, or that NetBSD as I knew it had
| ceased to exist. OpenBSD is actually also on that far end of
| the spectrum, because they care even more about self-hosting,
| which means that the inability of rustc to actually run (or
| at least self-host) on 32-bit x86 is a hard blocker. FreeBSD
| is in the middle; I knew they don 't intend to hit as many
| hardware platforms as their siblings, but I still thought
| they had broader coverage than rustc. And (per the page I
| linked) they _used to_ , but as of the latest releases
| they've been really cutting down their targets. Which... I
| dunno, it's practical, but still sad. I guess there's at
| least still OpenBSD and NetBSD to cover portability.
| influx wrote:
| Ironic since I've been thinking:
|
| FreeBSD : Go :: Linux : Rust
| bluejekyll wrote:
| Can you explain your comment a little more? I don't understand
| the relationship between these that you're suggesting.
| influx wrote:
| FreeBSD and Go are slow to change, extremely hesitant to
| introduce API changes, and adhere more towards tradition.
|
| Rust and Linux are changing rapidly and aren't as worried
| about completely uprooting entire systems. See for example
| sys v init vs systemd.
|
| Go didn't get generics until 1.18 and promises backwards
| compatibility.
|
| In Rust, the popular command line parser Clap completely
| changed its API between 3 and 4 such that you'll need to
| update your code.
|
| As much as I like predictably and simplicity, I think Rust
| will largely be more successful similar to Linux winning over
| FreeBSD.
| pgwhalen wrote:
| All mainstream languages treat backwards compatibility as
| paramount at this point, it's table stakes at this point.
| Rust is no exception.
|
| I will admit that because the library ecosystem in Rust is
| younger, you do see things like Clap's breaking changes
| more often than in other languages.
| jitl wrote:
| Go and FreeBSD share the similarity of a large base system
| that's useful out of the box: in go the runtime and large,
| useful stdlin, in FreeBSD the base system composed of the
| kernel and standard programs. Both also encourage a certain
| cultural aesthetics around that base of accepting and going
| with the flow of the base's limitations. For FreeBSD, things
| like composing posixly-correct sh scripts, BSD Makefile
| stuff. For Go, boilerplate, if err != nil, for a long time
| "you don't need generics".
|
| In contrast, Linux and Rust are both smaller core systems
| with more exposed complexity, but also require a large user
| space to make the core useful. Linux is just a kernel so you
| gotta bring everything else in the OS. Rust you need
| libraries for things most other languages (including Go)
| include, like regex, async, etc. However both Linux and Rust
| have a culture of adapting the system to work exactly how you
| like, in Linux again you bring everything you want - want
| systemd? Cool. Don't want systemd, that's cool too. In rust,
| people go absolutely crazy with macros and abstractions and
| likely it will still be plenty fast at runtime.
| avgcorrection wrote:
| The Go/Rust rivalry is just a peanut gallery meme. It's never
| been a real thing IMO.
| baq wrote:
| Yeah, go competes with Java and Python. Rust is in a
| different class of tools.
| pgwhalen wrote:
| I would narrow it even further: Go competes with Java.
| Their forte is both programming-in-the-large on the
| backend.
|
| It's much harder to manage a large codebase/application
| with Python, but it excels at data science and research
| programming, which Go and Java do not.
|
| (Obviously, there is overlap between all, and you _could_
| do anything in any language.)
| wharvle wrote:
| Go is what I reach for if my other options might be Java or
| Python but I don't want deployment and support to be really
| stupid and awful.
|
| Rust's close alternative is C++. Maybe also C? I don't know
| if Rust can fill its niche of ultra-portable libraries that
| are relatively easy to import and use in tons and tons of
| other languages & systems.
| mattsan wrote:
| Other than LLVM portability concerns, I think Rust can for
| sure replace C/C++ libraries (I'm talking DLLs etc).
|
| Sure, there will be a small C ABI shim but the developer
| experience writing in Rust I think is worth it.
|
| Also, nowadays whenever I want to write a fast Python
| extension, I don't think twice before using pyo3, super
| simple to write and build.
| loeg wrote:
| To strongman the "anti" case: I believe that FreeBSD still
| nominally supports a number of architectures that have immature
| or no Rust support, which seems like a major blocker to (at
| least) rewriting major system components like devd in Rust. And
| build times are already a problem -- the joke five years ago was
| that the FreeBSD build was a wart on the side of Clang. Doubling
| that isn't ideal.
|
| That said, I'm a big Rust believer and think it's the right tool
| for the job in a lot of situations where the historical answer
| was C or C++. Maybe it's the right tool for FreeBSD, too.
| boricj wrote:
| If these architectures can't muster enough manpower to keep up
| with modern toolchains then they are living on borrowed time.
| Maintainers of active, modern development projects have a
| limited tolerance for anachronism before they say "get a modern
| toolchain up and running or get left behind, we're sick and
| tired of C89".
| duped wrote:
| If by "modern" you mean "LLVM" then I'm sure the chip vendors
| will get right on it when they have a GCC backend that works
| and all of their customers use it.
| boricj wrote:
| There is a Rust front-end for GCC that is under active
| development [1]. If the chip vendors are not willing to
| develop and upstream a LLVM back-end then they can start
| contributing to it as an alternative.
|
| [1] https://rust-gcc.github.io/
| refulgentis wrote:
| > If the _chip vendors_ are not willing to _develop and
| upstream a LLVM back-end_
|
| oh, my sweet summer child...
| duped wrote:
| You've got the prioritization backwards
| mrweasel wrote:
| I feel like that might leave embedded devices without an
| upgrade path, and those are the devices that needs to longest
| "warning". So yes, borrowed time, but that might be a decade.
|
| That no to say that Rust shouldn't be considered, but maybe
| initially for new development or selective rewrites. Some of
| the mentioned, like nscd or devd in particular, shouldn't be
| that high on the list. The ZFSd should be fairly safe, as
| that's mainly needed on the larger platforms.
| patmorgan23 wrote:
| If those devices really need updates then the vendor can
| fork BSD and do the updates they need. It's not like the
| existing code will stop working on them.
|
| This is also why we LTS versions.
| pharmakom wrote:
| What if Rust compiled to C? Wouldn't that be a good way to
| support long tail platforms with low effort?
| jcranmer wrote:
| Not necessarily. C isn't a great language to target, since
| it's full of fun undefined behavior quirks that you will
| trip over if you look at it slightly cross-eyed. And part
| of the problem with the long tail platforms is that they
| can have issues that you don't expect (e.g., function
| pointers and data pointers might have different
| representation!).
|
| So the main set of platforms you're looking at are ones
| that are functional enough to have modern, stable C
| compilers, aren't too quirky that reasonably portable C
| code would "just" work, and yet ones that you don't already
| have support for in Rust. Outside of the embedded space,
| there's like... fewer than 5 architectures left, the most
| notable of which probably being Alpha.
| nocombination wrote:
| Honestly, after being in the software industry for a couple of
| decades and seeing how many times folks attempt to reinvent the
| wheel (for commercial or other reasons), I am beginning to sigh
| when I see how many language zealots there are (not you, just
| in general). The reality is, Rust does not need to replace
| everything. Nor should it be held on some kind of pedestal.
|
| E.G. Curiosity rover is doing just fine running on millions of
| lines of C.
|
| https://vdocuments.mx/monitoring-the-execution-of-space-craf...
|
| If it's going to impact OS stability and decrease performance
| _and_ portability of the humble, dependable, simple C, it doesn
| 't belong in the core. C is better than Rust for OS
| development.
| richardwhiuk wrote:
| I assume you are still programming in COBOL?
| nocombination wrote:
| It's not what you program in that matters--it's _how you
| test_ and ensure quality results.
| littlestymaar wrote:
| The amount of budget and time you have for the all
| project is finished, and in practice it's much easier for
| management to skip testing and QA than to reduce the
| scope of the project / the amount of features.hence the
| terrible quality that's plaguing this entire industry.
| kstrauser wrote:
| I like that Rust tests my code as I write it.
| ben_bai wrote:
| Just like C, COBOL will always be with us.
|
| > According to research, up to 850 billion lines of COBOL
| code are currently running in nearly 30,000 organizations,
| typically in critical production environments. 90 percent
| of Fortune 500 companies rely on it. Never has there been
| this much COBOL in circulation and the volume is only
| likely to increase for the foreseeable future.
|
| https://www.chrly.pt/en/2023/06/14/cobol-the-immortal-
| langua...
| timeon wrote:
| How is this relevant to parent comment?
| jimberlage wrote:
| The Curiosity rover might be doing ok, but the many places
| that have my social security number are not. I care more
| about the latter than the former.
| nocombination wrote:
| Right--and maybe those places ought to install OpenBSD.
| https://www.openbsd.org/
|
| Rust is not immune to security vulnerabilities. And at the
| end of the day, social engineering will steal more data
| than "hacking the mainframe". Why break in when you can
| just ask to be let in?
|
| OpenBSD has a great security track record because _they
| resist excessive change_ and _prefer simplicity_. For those
| who want to add Rust to the core of FreeBSD my primary
| question: is it _really_ necessary? Or is it just because a
| bunch of Rustaceans want to?
| mcronce wrote:
| Not solving _all_ security issues isn 't the same as not
| solving security issues. I'd rather my financial data be
| handled by software written in something that solves many
| whole classes of vulnerabilities than something that
| solves none of them.
| nordsieck wrote:
| > Right--and maybe those places ought to install OpenBSD.
|
| Sure.
|
| But running on OpenBSD doesn't solve application level
| vulnerabilities. And sure - OpenBSD may help limit the
| ability of an attacker to leverage one vuln into
| compromising the entire system. But if the original
| attack was important enough, that's cold comfort.
| raggi wrote:
| Yeah, the architecture point comes up in lost of rust in core
| type discussions, but I think when it comes to the BSD's it's
| actually a critical argument. I'm not particularly excited by
| limping along unusual architectures that most of the
| contributors can't perform reproductions on, but the BSD's are
| a bastion in this space and something probably has to be.
| Addressing this issue in both Rust and LLVM would be valuable
| at large.
| raggi wrote:
| It seems actually FreeBSD has dropped a lot of old platforms
| in recent versions, so this may not be a problem anymore. I
| imagine it would be with some other BSD's.
| mike_hock wrote:
| Even arm32 and x86 are Tier 2. Not exactly unusual
| architectures. The only Tier 1 architectures are amd64 and
| arm64, i.e. only the absolute mainstream. Not exactly a
| bastion of architecture support.
| PartiallyTyped wrote:
| Besides LLVM, there's been progress for a GCC backend, and in
| google summer of code, a suggested project is a c backend, so
| that all c compilers may be leveraged.
| bluejekyll wrote:
| Reading through the list it looks like it's not the kernel that's
| being discussed, and this comment implies to me that it's after
| much of the C system is built, " imp suggested adding an
| additional step after buildworld for stuff that requires an
| external toolchain". It's been a while since I've worked with
| FreeBSD, but I think buildworld includes linking, which would
| imply to me that you couldn't link Rust into portions of the
| system in that stage?
| loeg wrote:
| I think the idea is you would just move anything depending on
| Rust to the later stage.
| maybeben wrote:
| I thought the plan was to separate the toolchain from world.
| Building LLVM twice will suck.
| GrumpySloth wrote:
| Perhaps that will bring FreeBSD from Tier 2 to Tier 1 of Rust
| support, if they cooperate with the upstream?
|
| https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
| rwaksmunski wrote:
| I'm all for replacing C++ with Rust in the base system. Next step
| would be to move OpenSSL to ports, [with alternative libreSSL
| based ports tree available] and use rustls for fetch and friends.
| vermaden wrote:
| Pity the heading/topic is not like that:
|
| - _The Case for Rust in the FreeBSD Base System_
|
| Most Linux folks are not aware of what 'base system' means - and
| that its related to FreeBSD.
|
| About the Rust inclusion - I would include it - and would add
| these targets: # make buildworld (without Rust)
| # make rust (like Rush without 'buildworld') # make
| buildworldrust ('buildworld' + Rust)
|
| Regards.
| shrubble wrote:
| It would be a huge mistake for FreeBSD to adopt Rust in base at
| this stage, and would likely fracture whatever cohesion exists
| amongst the current team; it would be "emacs vs. vi" all over
| again, except worse; it would be that those using emacs wouldn't
| be able to easily read vi-created documents, and vice versa...
|
| That the very first thing to do is have to fix the compiler and
| build environment, and only then start to actually use it, is an
| additional complication.
___________________________________________________________________
(page generated 2024-01-21 23:00 UTC)