The Case for Rust (in the base system)

libs, deps and conflicts and a new funny language sintax to learn.
A python like programming language with the difference that compared to C takes much longer to get compiled into a binary file.
But still interesting
 
I remember this when trying to use in rust
simple-locale = "0.2.0"

error[E0432]: unresolved imports `crate::ffi::___mb_cur_max`, `crate::ffi::CODESET`
--> /home/miguel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/simple-locale-0.2.0/src/settings/codeset.rs:10:18
|
10 | use crate::ffi::{___mb_cur_max, CODESET};
| ^^^^^^^^^^^^^ ^^^^^^^ no `CODESET` in `ffi`
| |
| no `___mb_cur_max` in `ffi`


still got no solution
 
rmomota said:
I remember this when trying to use in rust
simple-locale = "0.2.0"

error[E0432]: unresolved imports `crate::ffi::___mb_cur_max`, `crate::ffi::CODESET`
--> /home/miguel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/simple-locale-0.2.0/src/settings/codeset.rs:10:18
|
10 | use crate::ffi::{___mb_cur_max, CODESET};
| ^^^^^^^^^^^^^ ^^^^^^^ no `CODESET` in `ffi`
| |
| no `___mb_cur_max` in `ffi`


still got no solution
Click to expand...

This is one of my pet peeves. With most if not all of the complex systems in ports. Somewhere in the dependency chain there is some package with a version number way below 1.0.
 
cracauer@ said:
This is one of my pet peeves. With most if not all of the complex systems in ports. Somewhere in the dependency chain there is some package with a version number way below 1.0.
Click to expand...
but it should work, right?

simple_locale - Rust

API documentation for the Rust `simple_locale` crate.
docs.rs docs.rs

I think there's a script I must execute

FFI Bindings​


As mentioned above, this crate depends on FFI bindings to POSIX localefunctions, and there are O/S differences that make this a pain. The scriptcreate-bindings.shis used to generate these bindings (using cargo bindgen) in such a way thatdifferent O/S bindings can be built effectively.



And this is why Rust is not yet ready for consume.
 
My big complaint about Rust is that using any of it requires to basically reinvent the wheel from scratch... (Anyone who watched even a few minutes of the compilation process for rust or rust-written stuff would know what I'm talking about).
 
FreeBSD, as a platform, is reference material for a lot of research and development; academia and industry being a large part of it. C was birthed from it's own purpose. What benefit would it be to uproot all of that momentum and mindshare over a non-tried, flashy language? Try eating a peanut butter and mustard sandwich; doesn't work. You need the jelly. They go hand in hand.

Imagine, for a second, someone (or a group) re-creating the entire TCP/IP stack from scratch. BSD was the platform for the development of it; even involving work from DARPA and other big industry players. Our stack is second to none. Even the ReactOS folks are using our network code. Same for storage; we have first class ZFS support. We practically own the open source storage market. That'd be a huge waste of engineering time and/or energy; let's not talk about monetary issues involved either.

This is why I think CHERI/Capsicum is so important IMO ; it could help alleviate a lot of these issues with modern systems development. FreeBSD doesn't get enough attention it deserves.

Just my two cents.
 
Jose said:
I remember measuring 40-second GC pauses when the heap got into the gigabyte range.
Click to expand...
The C64's BASIC (originally by Microsoft) implemented a garbage-collected heap for its string variables. It had to fit into the 38kB area usable for BASIC at all, together with the program text and other types of variables.

Mentioning this because I remember a funny competition to provoke the longest GC pause by creatively fragmenting this heap ... people managed to reach the minutes(!) range. 😂

Still surprised to learn a "modern" GC could ever take that long :-/
 
Beastie7 said:
We practically own the open source storage market.
Click to expand...
As a FreeBSD fan, I wished this was true. A recent post in TrueNAS forum brings some doubts. Have a look what Kris Moore says as someone who was the drive behind PC-BSD and FreeNAS.

Back to the main topic if the inclusion of Rust was to increase the number of developers for FreeBSD and any side effect (e.g. length of time to build up from source) was to be managed by other solutions (e.g. PkgBase), why not!
 
drhowarddrfine said:
Because the goal is technical excellence and not popularity.
Click to expand...
I agree, FreeBSD stands out as an elegant/excellent technical solution. However popularity should not be easily dismissed, as unfortunately that drives the trend for future hardware/software support. If technical excellence was generating growth of interest then there is no dilemma to worry about!
 
The link to the FreeNAS forums points out an example where third parties are putting work into Linux and not FreeBSD as an area of concern: If the platforms don't maintain reasonable feature parity, iX has developed an escape hatch for themselves. Popularity can dictate allocation of resources. Popularity is about vibes and standing still often doesn't help.
 
kpedersen said:
macOS is crazy popular but still currently runs on less hardware than Plan 9! ;)
Click to expand...

Well, macOS was vertically designed for a specific set of hardware. They go hand-in-hand; like the old SUN days. But due to it's BSD underpinnings you can run macOS on non-Apple hardware (ie. hackintosh). Kind of a moot argument to be honest.

blazingice said:
Back to the main topic if the inclusion of Rust was to increase the number of developers for FreeBSD and any side effect (e.g. length of time to build up from source) was to be managed by other solutions (e.g. PkgBase), why not!
Click to expand...

If you read that email thread; no-one there provided any real practical reason for inclusion; other than it being "hot, new and flashy". The cost-benefit ratio would be a complete net negative. The whole premise for Rusts existence was "better security" when we could just improve the security of existing software. Thankfully research has been done with FreeBSD to increase security at the low end of the stack. (eg. CHERI/Capsicum)
 
blazingice said:
Good one!
Click to expand...

Hehe. Fair, fair.

As an interesting example, I would note that Plan 9 has its own custom Git client (git9), as does OpenBSD (got), whereas the much more popular operating systems don't have a bespoke client. So in some ways, having a clean, unique operating system that targets a smaller group, but targets them well, can still yield some really interesting, and really competitive stuff. OpenSSH for example, can't be beaten.

In many cases FreeBSD's Bhyve is a good example at a much cleaner solution to a problem, that probably wouldn't have ever existed if it had 90% popularity of the market. Everyone would just demand a qemu backend rather than a custom solution. I even suspect big busy operating systems actually have the opposite effect on developer engagement, I think some people might get overwhelmed.
 
kpedersen said:
Hehe. Fair, fair.

As an interesting example, I would note that Plan 9 has its own custom Git client (git9), as does OpenBSD (got), whereas the much more popular operating systems don't have a bespoke client. So in some ways, having a clean, unique operating system that targets a smaller group, but targets them well, can still yield some really interesting, and really competitive stuff. OpenSSH for example, can't be beaten.

In many cases FreeBSD's Bhyve is a good example at a much cleaner solution to a problem, that probably wouldn't have ever existed if it had 90% popularity of the market. Everyone would just demand a qemu backend rather than a custom solution. I even suspect big busy operating systems actually have the opposite effect on developer engagement, I think some people might get overwhelmed.
Click to expand...
I do agree with this, that's one of the strengths of *bsd (and original unix philosophy); small enough to be ported easily and learned in a reasonable amount of time, not overwhelmed by zilliions of features and lines of code like a certain other "big busy o/s"...
www.gamingonlinux.com

Linux kernel 6.7 is out now and it's one of the largest releases ever

Linus Torvalds announced the release of the Linux kernel 6.7 on Sunday, 7th January 2024 and as it turns out it's one of the largest releases ever.
www.gamingonlinux.com www.gamingonlinux.com
it gets to where there's just too much of it and too much fragmentation... and, of course, now they have added rust in the kernel! :eek::-/o_O😝🥴
If any *bsd kernel developers are listening... please, keep it small :)
 
Doesn't rust has zillions of features compared to other programming languages like e.g. python.
I don't even start to learn it as it is too huge. Just like C++.
 
You must log in or register to reply here.
Back
Top