Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

Post reply on HN
Print view View original

51–60 of 155 posts

Re: The Case for Rust in the base system

#51

Post by baq »

oconnor663 wrote: post #32
dosshell wrote: post #27

Earlier quoted context omitted.

> 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 d…

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.…

> 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.

Re: The Case for Rust in the base system

#52

Post by zozbot234 »

oconnor663 wrote: post #32
dosshell wrote: post #27

Earlier quoted context omitted.

> 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 d…

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.…

> 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.

Re: The Case for Rust in the base system

#54

Post by boricj »

loeg wrote: post #19

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…

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".

Re: The Case for Rust in the base system

#55

Post by masklinn »

oconnor663 wrote: post #32
dosshell wrote: post #27

Earlier quoted context omitted.

> 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 d…

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.…

> 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, ...).

Re: The Case for Rust in the base system

#56

Post by oconnor663 »

zozbot234 wrote: post #52
oconnor663 wrote: post #32

Earlier quoted context omitted.

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.…

> 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…

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=3019

Re: The Case for Rust in the base system

#57

Post by midmagico »

boricj wrote: post #54
loeg wrote: post #19

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…

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".

[flagged]

Re: The Case for Rust in the base system

#58

Post by midmagico »

loeg wrote: post #22
yjftsjthsd-h wrote: post #11

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.

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."

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.

Re: The Case for Rust in the base system

#59

Post by wharvle »

avgcorrection wrote: post #37
influx wrote: post #14

Ironic since I’ve been thinking: FreeBSD : Go :: Linux : Rust

The Go/Rust rivalry is just a peanut gallery meme. It’s never been a real thing IMO.

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.

Re: The Case for Rust in the base system

#60

Post by duped »

boricj wrote: post #54
loeg wrote: post #19

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…

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".

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.
Post reply on HN