The Case for Rust (in the base system)

cracauer@ said:
To a certain degree I indeed think that people who want to compile the elephant ports should buy a semi-beefy machine (say $1000). I know this isn't possible for everyone, but machines that are cheap or otherwise crippled (some laptops) will naturally lead to high compile times.
Click to expand...

FWIW I just built rust in 59 minutes on fairly low-end desktop hardware. The same machine does buildworld in 42 minutes, so it would be a significant difference for the base system, but 59 minutes doesn't seem excessive for ports - at least not compared with the time desktop ports took when I still used ports.

It's a AMD Ryzen 5 5600G with 64GiB of DDR4, the CPU was over 4 years old when I bought it and DDR4 was much cheaper than DDR5 at the time , so it was pretty cheap.
 
Well, I suppose this is the place to mention this: today, I began to install FreeBSD ver 15 on my desktop 'pooter. One of the last things I wanted to do was to install Firefox. First, I was told, repeatedly and in no uncertain terms that there was no firefox available from the repository. So, being the adverturesome fool that I am, decided, to heck with it, and I would simply go to /usr/ports/www and make install clean firefox.

Since then, my system has been blasting screen after screen of "stuff" having to do with rust, of all things. I had no desire to get involved with rust at this point, but here we are. It has been at least 2 hours so far and things do not appear to be slowing down.

All I want to do is to use my box.

Thanks....I think. :rude:

Oh, and someone here recently mentioned someone who is "old" and mentioned 50 years old, the young sprout. I am 83.

Ken Gordon
 
KenGordon said:
Well, I suppose this is the place to mention this: today, I began to install FreeBSD ver 15 on my desktop 'pooter. One of the last things I wanted to do was to install Firefox. First, I was told, repeatedly and in no uncertain terms that there was no firefox available from the repository. So, being the adverturesome fool that I am, decided, to heck with it, and I would simply go to /usr/ports/www and make install clean firefox.

Since then, my system has been blasting screen after screen of "stuff" having to do with rust, of all things. I had no desire to get involved with rust at this point, but here we are. It has been at least 2 hours so far and things do not appear to be slowing down.

All I want to do is to use my box.

Thanks....I think. :rude:

Oh, and someone here recently mentioned someone who is "old" and mentioned 50 years old, the young sprout. I am 83.

Ken Gordon
Click to expand...

If you want to compile a port that is not in packages at the time you can still install the dependencies from packages.
 
ports(7)
Code: 
     install-missing-packages
                Install missing dependencies from packages instead of building
                them.
Code: 
     Example 2: Installing Dependencies with pkg(8)

       The following example shows how to build and install a port without
       having to build its dependencies.  Instead, the dependencies are
       downloaded via pkg(8).

         # make install-missing-packages
         # make install

       It is especially useful, when the dependencies are costly in time and
       resources to build (like lang/rust).  The drawback is that pkg(8)
       offers only packages built with the default set of OPTIONS.
 
I suppose the right way to do this is (talking about ports):
Code: 
#cd /path/to/port
#make config
#make install-missing-packages
#make install
dependencies use the default OPTIONS, the main port can be configured with custom OPTIONS.
 
rygo6 said:
However, in a production environment where CI will clone and do a from scratch build every iteration, potentially on multiple platforms. The from-scratch build time becomes a major chokepoint. I have been in scenarios where the CI iteration time would come to take so long, I honestly believed it was going to make the company fail as every little comment or change request on a PR would mean you'd have to wait another day, to even a week, to make it through CI. Things which a small team could sort out in a day if CI only took an hour or two would start to take an entire month in a bigger department.
Click to expand...
Yes! Add flaky "mocked" unit tests, and you're talking about the code base I work in. Half the time the build fails because these freaking "unit" tests fail for no discernible reason. And passing the build gives you no guarantees that the integration tests will go well because the vast majority of the "unit" tests are useless and stupid. (Testing getters? C'mon now!) The icing on the cake is that we have a poorly implemented monorepo. I often lose the race and someone merges to master before me. I get to start all over again.

I spend 20-40% of my time trying to get a clean build. Then I get to spend 1-5 days fixing the integration tests that have been failing for a month and no one noticed or cared. That last one is not the platform's fault, though.

rygo6 said:
I worry Rust codebases will end up in the same place if they get big enough. As Rust already has worse compile time than C++, also has features which can cause compounding compile time, and is flippant about the cost of compile time with the 'Zero Cost' jargon.
Click to expand...
Yeah, the hubris really shines through in the "Zero cost" bleating. Our platform is perfect! Get a faster machine with more RAM!

bvdw78 said:
An application in Rust would pull in its dependencies through cargo and, usually, crates.io because that is how the Rust ecosystem is. That application could be a port in the ports collection. How the application itself gets built is not FreeBSD's problem to solve, it's an application developer and/or port maintainer problem. The port's "make" command spits out an artifact that "make install" puts onto your system and it's done.
Click to expand...
This is how it's done for bloated Java ports that use the Maven crapola, BTW.
 
I can’t build rust on a 28 core system with 32gb ram without a lot of extra tuning. So it is frustrating when I go to update a port that requires it. I want nothing to do with rust because of that.
 
malco_2001 said:
I can’t build rust on a 28 core system with 32gb ram without a lot of extra tuning. So it is frustrating when I go to update a port that requires it. I want nothing to do with rust because of that.
Click to expand...

It isn't reasonable to have just a little over 1 GB per core of RAM, though.
 
I routinely have Poudriere build Rust in a 32GB VM on yesteryear's 12 core Ryzen. No tuning. I don't know what I'm doing right, but other than that it takes a lot of time I have zero issues compiling the Rust port.
 
I think that the more things a language does for the programmer, the worse the result is. FreeBSD is great because its programmers are great. If you deny programmers control, you'll end up with less efficient programs, and we already have Windows for something very inefficient. I would never move from C and assembler. This is my unpopular opinion.
 
Seeking for opinions from Rust/C experts: how does readability of the two languages compare?

Context: long term support. I wonder how easy/hard it is to understand unfamiliar piece of code written in these languages? Does one need to become an expert (thinking of C++ ... for some reason) in order to understand the intricacies of the code?
 
skhal said:
Seeking for opinions from Rust/C experts: how does readability of the two languages compare?

Context: long term support. I wonder how easy/hard it is to understand unfamiliar piece of code written in these languages? Does one need to become an expert (thinking of C++ ... for some reason) in order to understand the intricacies of the code?
Click to expand...

Now wait a second. Are you talking C or C++?
 
What cracauer said. But even more, C++ has changed a lot. The dialect we used to program in the late 80s (no templates, completely manual memory management) gave way to STL and heavy (over-?) use of templates, and then gave way to auto pointers and move semantics. C++ of 2020 looks completely different from C++ of 1990.

I have no problem reading and understanding the C++ I wrote myself in my favorite programming style a month ago. I actually sometimes find programs I wrote 25 years ago and that haven't been modified, and I have a hard time figuring out how they work.

And then figure in that most programming languages, but in particular C++ (and C) have a wire variety of programming styles. For example, some people (and some companies) stretch out code a lot, with lots of continuation lines, parentheses and braces on a line by itself, very long variable names, so even a simple function call with 3 arguments takes up half the screen. Personally, I hate that programming style, because I lose track of what is happening; I like my code to be pretty concise as far as formatting is concerned. Other people have the opposite preference, and they find my code unreadably dense. There are many such stylistic preferences, which can make other people's code easy or hard to read.

I haven't done much work in Rust, tried using it for a few weeks, and then gave up again. It is verbose and difficult to use, with quite a bit of learning curve. Because of that, I think Rust code, once written, will be reasonably easy to understand, since the mechanisms of passing arguments will be very clear. It might be so verbose and overly clear that it becomes difficult to show the intent of the code.
 
Rust has a few bits that are unintuitive when you encounter them first, e.g. about error handling. But then C has no error handling at all and everybody rolls their own style of error handling. What's easier?

I would say that if you know the language sufficiently well (which is more expensive than doing it for C) then Rust code from different programmers can be easier to read. C can be a nightmare. There is no obfuscated Rust code competition (yet). On the other hand you don't find plain screwed up C code in the FreeBSD kernel.
 
I would like to see it killed off.

Code: 
load: 1.27  cmd: sh 61524 [select] 7113.34r 0.56u 1.27s 0% 4032k
[01:58:34] [mbm-default] [2025-12-26_11h27m45s] [parallel_build] Time: 01:58:24
           Queued: 6 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 6
 ID  TOTAL       ORIGIN   PKGNAME     PHASE TIME     TMPFS     CPU% MEM%
[01] 01:58:08 lang/rust | rust-1.92.0 build 01:57:35 6.85 GiB 18.9% 3.4%
[01:58:34] Logs: /poudriere/data/logs/bulk/mbm-default/2025-12-26_11h27m45s

This is all for astro/gpxloggerd. Why do I torture myself with anything that needs it. (This is not an actual gpxloggerd dependency but something in its path)
I bet it takes 4hours on 8 core machine with 16GB RAM
 
Phishfry said:
I would like to see it killed off.

Code: 
load: 1.27  cmd: sh 61524 [select] 7113.34r 0.56u 1.27s 0% 4032k
[01:58:34] [mbm-default] [2025-12-26_11h27m45s] [parallel_build] Time: 01:58:24
           Queued: 6 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 6
 ID  TOTAL       ORIGIN   PKGNAME     PHASE TIME     TMPFS     CPU% MEM%
[01] 01:58:08 lang/rust | rust-1.92.0 build 01:57:35 6.85 GiB 18.9% 3.4%
[01:58:34] Logs: /poudriere/data/logs/bulk/mbm-default/2025-12-26_11h27m45s

This is all for astro/gpxloggerd. Why do I torture myself with anything that needs it. (This is not an actual gpxloggerd dependency but something in its path)
I bet it takes 4hours on 8 core machine with 16GB RAM
Click to expand...
Exactly. Why people insist compiling things when ports are already available is beyond me.
 
Well I am trying to figure out how to use Poudriere Bulk. To learn I have to tear it down and build from scratch. Over and over.
Once packages are built it is brilliant. Getting there can be a pain. My poor machinery is taking a beating..

Believe me if the -b option worked the way I like I would not be poking into this thread.
 
cracauer@ said:
Rust has a few bits that are unintuitive when you encounter them first, e.g. about error handling. But then C has no error handling at all and everybody rolls their own style of error handling. What's easier?

I would say that if you know the language sufficiently well (which is more expensive than doing it for C) then Rust code from different programmers can be easier to read. C can be a nightmare. There is no obfuscated Rust code competition (yet). On the other hand you don't find plain screwed up C code in the FreeBSD kernel.
Click to expand...
Straight C is much less complex than Rust, so the "code" is indeed easier to read. But you can't make complexity go away, you can only hide it out of sight. Error handling is the tip of the iceberg. Things like sensible string processing, memory management, parallelism and locking all still exist, and in C everyone (or every group / project / tribe) has to roll their own. Usually using bizarre naming conventions that other people have to guess. So that's where the complexity is often hidden.

C++ on the other hand is much more complex than either C or Rust.

Anecdote on naming conventions: In my personal Python code, I use two bizarre naming conventions. First, variables are snake_case, and functions/methods are camelCase. Other people use different conventions. And I explicitly use single-character variables that are greek letters for short-lived and commonly used variables, like Σ for sums, ε for small numbers, λ and μ for loop indices (to replace l and m). That one tends to freak people out. The one I did for fun once was to consistently use π, but not for 3.14159..., but for a variable called "policy_index", which was used extremely frequently in a piece of code. The reaction on people's faces were priceless.
 

The Algebra of Loans in Rust

The heart of Rust borrow-checking is this: when a borrow is taken, and until it expires, access to the borrowed place is restricted. For example you may not read from a place while it is mutably borrowed.
nadrieril.github.io

Let me share one table from the above
Screenshot 2025-12-27 at 10.57.06 AM.png


🙄
 
You must log in or register to reply here.
Back
Top