The Case for Rust (in the base system)

There needs to be an agnostic ports tree of Rust for any Unix-like operating system, like pkg-src but for Rust only. It needs compatibility and instructions for setting it or making it a supplementary ports and package tree.

Cargo needs to only be for libraries, so that there's no redundancy. The Rust ports tree specifically for Unixes would be different than Cargo. Of course this ports tree would rely on Cargo only for libraries.

This way, FreeBSD can stay how it is, and not have Rust redundancies in base or default ports, except for those who want to use a Rust ports tree on top of FreeBSD. When source is available in a Rust ports tree, it becomes removed from FreeBSD's ports tree.
 
sidetone said:
There needs to be an agnostic ports tree of Rust for any Unix-like operating system, like pkg-src but for Rust only. It needs compatibility and instructions for setting it or making it a supplementary ports and package tree.

Cargo needs to only be for libraries, so that there's no redundancy. The Rust ports tree specifically for Unixes would be different than Cargo. Of course this ports tree would rely on Cargo only for libraries.

This way, FreeBSD can stay how it is, and not have Rust redundancies in base or default ports, except for those who want to use a Rust ports tree on top of FreeBSD. When source is available in a Rust ports tree, it becomes removed from FreeBSD's ports tree.
Click to expand...

Isn't it that many of the large systems in port already have some minor dependency of a dependency written in Rust? If not now it will be soon I am afraid.

And in any case, if you do this for Rust, why not also do it for Go-requiring ports?
 
cracauer@ said:
Isn't it that many of the large systems in port already have some minor dependency of a dependency written in Rust? If not now it will be soon I am afraid.
Click to expand...
If Python and Perl are anything to go by; ports tend to drag in every random language.

That said, I just checked now and I am pleasantly surprised that there is no Rust installed as a dep for anything I use. I do however use an "out of tree" Firefox so that would have dragged it in I suppose.
 
cracauer@ said:
And in any case, if you do this for Rust, why not also do it for Go-requiring ports?
Click to expand...
Why not? They would be separate and independent projects. Have choices for those who want to use those on top of existing Operating systems, since Redox OS is incomplete as a desktop.

It would keep FreeBSD ports to the C family, and reduce dependency hell.

Edit: Zig would be considered in the C family, even if it's not, bc it's meant to compile C code. Also, I meant programming (programming) languages as opposed to scripting (programming) languages getting their own ports, but according to language family.
 
Based on recommendations from Google and Microsoft, , the NSA highly recommends Rust and Go as memory safe languages.

The use of C and C++ is highly discouraged as unsafe.

https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/

That right there would make me not want to use those languages with python included.

While we're at it let's put SELinux in there too so Freebsd can be just like Linux instead of being an independent system.

And before you think I don't know what I'm talking about, I've had this conversation twice...once in 2007 and the second time when Lynert Poettering
introduced systemd, who by the way works for Microsoft now.

I think Freebsd should find it's own niche and stop trying to be like Linux.

And the naysayers will start posting about it can't be done or how do you propose to do that?
 
lvyitian said:
Yes, Rust has no builtin tracing garbage collector, but it can be implemented. And there're some implementations already.
Click to expand...
Rust builds generates a binary that runs by itself.
Not like java that needs a JVM or C# that needs .Net Framework to run.
The magic is that Rust builds are free of memory leaks and other safety stuff because developers do not need to manage memory allocation as Rust manage place memory blocks allocation and release functions at build time in the right place.
There's no such GC stuff in Rust.
 
rmomota said:
Rust builds generates a binary that runs by itself.
Not like java that needs a JVM or C# that needs .Net Framework to run.
The magic is that Rust builds are free of memory leaks and other safety stuff because developers do not need to manage memory allocation as Rust manage place memory blocks allocation and release functions at build time in the right place.
There's no such GC stuff in Rust.
Click to expand...
Rust will possibly cause memory leaks, as long as you use Box<T> and Arc<T> and Rc<T> or unsafe, this is why https://crates.io/crates/gc-arena exists.
 
rmomota said:
The magic is that Rust builds are free of memory leaks and other safety stuff because developers do not need to manage memory allocation as Rust manage place memory blocks allocation and release functions at build time in the right place.
Click to expand...

Untrue. One will easily leak memory by creating reference cycles. And, most of the time, developers will be trapped by following the borrower 's advices.

By enabling Clangs' C sanitizers, software will crash in the same way as with Rust when an over-bound is hit.
Rust is not that «safe». Rust only prevents for undefined behaviors. A software crash is a defined behavior for Rust developers.

There is no «magic».
 
DavidMarec said:
Untrue. One will easily leak memory by creating reference cycles. And, most of the time, developers will be trapped by following the borrower 's advices.

By enabling Clangs' C sanitizers, software will crash in the same way as with Rust when an over-bound is hit.
Rust is not that «safe». Rust only prevents for undefined behaviors. A software crash is a defined behavior for Rust developers.

There is no «magic».
Click to expand...
So like everywhere magic needs a magician.
 
I dove down the Rust rabbit hole for about six months in 2022. Bought a book, downloaded the tools, and went to work. Quickly learned that some coding patterns did not translate well to Rust. Some features I loved. Others were a struggle. The compiler screamed "nope you can't do that!" Through patiences and perseverance, I learned how to organize the code to make the Rust compiler and unit tests happy. Instead of continuing with Rust, I took those organizational ideas and applied them to my older, more mature C++ code.

One thing that has my interest is to write XCB client code in Rust for a simple X.org UI. Not yet tried.
 
grahamperrin said:
the rust project has a burnout problem

– Jynn Nelson. Via:

www.theregister.com

Rust is the latest open source project to face burnout

Spotting and tackling a widespread problem is a challenge
www.theregister.com www.theregister.com
Click to expand...
You keep posting this as it is something specific or unique to the Rust project.
It isn't.
Any project in a high turnover phase has the same problem; too many new participants makes for a heavy load on the "old hands" / experienced participants that is guiding the newcomers. Each project needs to find it's own way, but there is lot's of experience to learn from, the article you linked contains some.

Also burnout is a personal thing; each human needs to figure out the signs, and how to avoid burnout. Most of the time, other people don't know you well enough to see the signs in you. My advice: do a regular self-check on the joy you feel about an activity you do. If there is no / very little joy when you think about an activity you are going to perform, it could be a burnout signal.
Keeping yourself in a good state should be a high priority for everyone; it affects everything about your performance.
 
rmomota said:
I was meaning memory exploits.
But I'm no expert on Rust, yet.
I'm still discovering it and I'm not sure if I will definitely switch to it.
Click to expand...
Yes, Rust can avoid buffer overflow, use after free, double free, use before initalization, data racing and so on as long as you don't use unsafe keyword. But memory leaks still exist. But it is impossible to happen without unsafe or smart pointers.
 
lvyitian said:
Yes, Rust can avoid buffer overflow, use after free, double free, use before initalization, data racing and so on as long as you don't use unsafe keyword. But memory leaks still exist. But it is impossible to happen without unsafe or smart pointers.
Click to expand...

You can still pile up memory you don't actually use by accident. Just like in a GCed language.
 
cracauer@ said:
You can still pile up memory you don't actually use by accident. Just like in a GCed language.
Click to expand...
Yeah, and this also happens in GC language, for example, in Java, you store data in the static ArrayList field in the class and don't ever remove it, then it will cause memory leak.
 
Well, I know Rust doesn't prevent data racing, as that is more of a Run time condition, and is rather easy to do. I watched a twitch streamer(togglebit) prove that you can do data racing with less than 25 lines of code never using any unsafe/smart pointers. Just because you use async code, doesn't mean you need to use Arc/mutex; at the same time the nature of async code allows data racing to happen as you don't always know which order the code will be executed in. As with buffer overflows, you can still encounter that easily without sanitizing user input (like is often a prime cause for this).
 
ct85711 said:
Well, I know Rust doesn't prevent data racing, as that is more of a Run time condition, and is rather easy to do. I watched a twitch streamer(togglebit) prove that you can do data racing with less than 25 lines of code never using any unsafe/smart pointers. Just because you use async code, doesn't mean you need to use Arc/mutex; at the same time the nature of async code allows data racing to happen as you don't always know which order the code will be executed in. As with buffer overflows, you can still encounter that easily without sanitizing user input (like is often a prime cause for this).
Click to expand...
The yield action of async is not passive, it's initiative, so the context switching is controllable, as for buffer overflows, they will cause panics immediately so that there will be no undefined behavior executed.
 
ct85711 said:
Well, I know Rust doesn't prevent data racing, as that is more of a Run time condition, and is rather easy to do. I watched a twitch streamer(togglebit) prove that you can do data racing with less than 25 lines of code never using any unsafe/smart pointers. Just because you use async code, doesn't mean you need to use Arc/mutex; at the same time the nature of async code allows data racing to happen as you don't always know which order the code will be executed in. As with buffer overflows, you can still encounter that easily without sanitizing user input (like is often a prime cause for this).
Click to expand...
Rust does compile time checking to prevent data racing, it prevents non-thread-safe data from accessing across threads, and the ownership and borrow checker prevent you from writing and reading at the same time. It prevents writing to global variable in safe context, and it forces you to acquire the lock before accessing the data, and the lock will be released automatically as soon as it is out of scope.
 
You must log in or register to reply here.
Back
Top