The Case for Rust (in the base system)

I based my previous comment on work related things where I was looking at SDL bindings for stuff. Felt like "what the heck am I doing and why". It's often trivial when both sides of a binding are unchanging, but when one or both are evolving it becomes very much nontrivial.

Locking in one side or the other make future integration more difficult. "We need version xyz because security" but "we only support version xyz-- bindings".

So non trivial, but still "fun stuff".
 
kpedersen said:
what[=](do){you}<=>mean?
constexpr std::wstring("Modern") C++(Args...)const std::move(const is)std::span<perfectly>.lock(serviceable&&)!
Click to expand...
Johajpy.jpeg

:p
 
cracauer@ said:
Well, and C is easy to interface to.

Imagine you'd have to mix Rust and Golang.
Click to expand...
Or rust + Vulkan which gives Vulcano 😅
Well, given Vulkan is completely written in C.
I do not know anymore, but why not just keep C and C++ instead of introducing rust, which has mixed reviews anyway ?
I mean FreeBSD is completely written in C, atleast the kernel, right ?
So, like my IT teacher said in university, "Do not fix it if it aint broken, but slap your hand if you do...".
 
Well, this is one reason why I stick with C often.

If I later have to interface with a different language I have at least a fighting chance to use the existing C code.
 
If someone wants rust so desperately, what about Redox OS ?
Atleast that of many OS variants written in Rust is atleast proceeding, and it even has relibc a custom C library written in Rust.
 
"I" think making C as the "intermediate code" of new language is most straightforward way. Because, anyway, ALL languages (except on Java processor that made Java bytecodes as its machine language, not sure it had been "shipped as mass-production model" or not) are translated into the worst memory-unsafe language, machine (binary) codes.

This way, by mandating audit process to generate C code (not directly to binary code) allows auditors / reviewers who are NOT YET good at new languages to audit generated C code to determine the proposed new languages codes to be accepted or not.

This would be mostly same as auditing the efficiency and reliability of C codes by generating asm codes in ancient days.

And once the new language become the "backborn" (mainline) of a project originally written in C (or asm), switching to native new bindings for new major version.
 
LillieNB said:
Or rust + Vulkan which gives Vulcano 😅
Well, given Vulkan is completely written in C.
I do not know anymore, but why not just keep C and C++ instead of introducing rust, which has mixed reviews anyway ?
I mean FreeBSD is completely written in C, atleast the kernel, right ?
So, like my IT teacher said in university, "Do not fix it if it aint broken, but slap your hand if you do...".
Click to expand...
Careful, you are sounding "sane" :)

I've been in the industry for a long time, been through lots of "new and improved" things (languages). All the new things wind up binding/get compared to "C" or "C++". Syntax on the new looks very similar to C/C++, a lot get pushed to compilers/linkers to provide the safety.

That's not a bad thing, but then "bindings from language X to C" puts a lot of pressure on what is creating those bindings. "Provide/keep all the new and improved stuff but implement in C"

OS vs Application:
Write an OS in your preferred language but provide standard interfaces so exisiting applications can just be recompiled and run.
No issues with an OS written in Rust/Go/JavaScript/Ada, but it needs to provide standard library/interface so applications can just be recompiled, not rewritten.
 
T-Aoki said:
"I" think making C as the "intermediate code" of new language is most straightforward way. Because, anyway, ALL languages (except on Java processor that made Java bytecodes as its machine language, not sure it had been "shipped as mass-production model" or not) are translated into the worst memory-unsafe language, machine (binary) codes.
Click to expand...

There have also been the Lisp machines with special processors.
 
LillieNB said:
Because of that ugly syntax I prefer python...
I like C++ and have coded in it for 10+ years, but I have the feeling that the syntax grows to be uglyer with each new revision.
Hopefully C# is cleaner, since I will need it to continue to maintain the Ryujinx switch emulator...
Click to expand...
The ugly C++ syntax scared me off completely. I did learn C when I was in college, but could never stomach putting in the effort to learn any C++ in spite of C++ being a superset of C. Ended up learning Java (that was required for me in college), and being weirdly good at it (but not to the point of being able to compile Android Studio).
 
mer said:
Careful, you are sounding "sane" :)
Click to expand...
I am anything else, but not "sane" 😂
Well, putting the joke aside, I do not have anything against rust or something alike.
It is that I just cannot see the benefits if an application is well written in for example C to switch to another language.
The porting itself, or a complete rewrite would take a huge amount of time.

It is like in Linux with ALSA.
You have a working audio server, but instead you put pulseaudio, jack, or now pipewire which is essentially (pulseaudio, jack, or alsa through pipewire) instead of improving ALSA?
The same thing is done to OSS, which is really sad, atleast for me.
In Linux you also have OSS on ALSA, or Jack on OSS, or pipewire in all its glory.
😅
 
cracauer@ said:
I want to pick up the current fight going on in the Linux community about Rust in the kernel.
Click to expand...
Fight over, Linus stepped in. ;)
cracauer@ said:
While mainline Rust code is a pretty straightforward programming language the interface-to-C definitions are not. They looks like line noise. Now, the problem is that these API definitions need to be edited by non-Rust programmers when the API changes. This is happening with the DMA API right now. This is the worst kind of Rust code to be changed by non-Rust programmers and they feel that the effort to learn is too much/excessive/to worth it for the proposed benefit.
Click to expand...
Policy is that non-Rust API changes have to be communicated to the Rust owners and it's Rust owner's responsibility to change it, nbd.
 
LillieNB said:
I am anything else, but not "sane" 😂
Well, putting the joke aside, I do not have anything against rust or something alike.
It is that I just cannot see the benefits if an application is well written in for example C to switch to another language.
The porting itself, or a complete rewrite would take a huge amount of time.

It is like in Linux with ALSA.
You have a working audio server, but instead you put pulseaudio, jack, or now pipewire which is essentially (pulseaudio, jack, or alsa through pipewire) instead of improving ALSA?
The same thing is done to OSS, which is really sad, atleast for me.
In Linux you also have OSS on ALSA, or Jack on OSS, or pipewire in all its glory.
😅
Click to expand...
When I compile ports, I make sure to turn on support for any and all sound systems (OSS, ALSA, Pipewire, Jack, PortAudio, sndio, you name it). Never had a problem with sound as a result. If I install something that is supposed to make sound, then making sound is NOT a problem, even if it only supports a limited number of Open Source sound systems. Pre-compiled FreeBSD packages don't do that, which is why I switched to ports :P
 
msplsh said:
Policy is that non-Rust API changes have to be communicated to the Rust owners and it's Rust owner's responsibility to change it, nbd.
Click to expand...

I might have to read more on this.

But either way, it delays a possible commit until the Rust version is done.
 
LillieNB said:
Well, putting the joke aside, I do not have anything against rust or something alike.
It is that I just cannot see the benefits if an application is well written in for example C to switch to another language.
The porting itself, or a complete rewrite would take a huge amount of time.
Click to expand...
Exactly. The language is a tool, like a hammer or screwdriver. If you already have a hammer that works, what do you gain by making a new hammer out of different material? Maybe better in the long run (new hammer doesn't rust, yes pun intended) but getting to the acceptance of new hammer may take a long time.

Application:
Choose a tool, use it correctly and to it's optimal level, move on. Rewriting something in a new tool, make sure you understand the why and the benefits.
 
LillieNB said:
Because of that ugly syntax I prefer python...
I like C++ and have coded in it for 10+ years, but I have the feeling that the syntax grows to be uglyer with each new revision.
Hopefully C# is cleaner, since I will need it to continue to maintain the Ryujinx switch emulator...
Click to expand...
Good luck with maintaining that, really. I hear the big N isn't particularly fond of that.
 
cracauer@ said:
I might have to read more on this.

But either way, it delays a possible commit until the Rust version is done.
Click to expand...
If I understand correctly, the root cause of the problems seems to be that Linux kernel committers with authority and responsibility as reviewers are still not good at Rust (and any other new languages to be used in the future, too), thus, cannot allow changes for interfaces in C side.

If I'm correct, Rust guys in Linux kernel community are too stupid. They should need waiting (maybe) 10 or more years for auditors/reviewers become good enough at reviewing Rust codes. In the mean time, possibly newly authorized reviewers who can audit both C and Rust codes increase.
 
astyle said:
When I compile ports, I make sure to turn on support for any and all sound systems (OSS, ALSA, Pipewire, Jack, PortAudio, sndio, you name it). Never had a problem with sound as a result. If I install something that is supposed to make sound, then making sound is NOT a problem, even if it only supports a limited number of Open Source sound systems. Pre-compiled FreeBSD packages don't do that, which is why I switched to ports :P
Click to expand...
I think I am just a minimalist in my nature, and I just cannot understand why someone needs an audio server on an audio server + the produced overhead, although the audio system present on the OS is already working.
Of course, if someone needs some specific audio server just to get an application to work, because company, or person x, y decided to drop support for your initial audio system then that is fine, but I would not accept it and search for ways to get my initial audio system to work like I did back then on arch linux with apulse, just to get ALSA working again on Firefox.
In the past I made a horrible experience with pulseaudio on ALSA, my cpu temp raised from 40 to 46 grade celsius while using an audio server on an audio server on Arch Linux, only because harry poetterings crafted wonder audio system which is just sitting on ALSA did something to raise the temps.
 
Keep in mind that OSS and ALSA in Linux do not have an in-kernel mixer like FreeBSD does. They only allow one client at a time - which most people choose to be a sound server out of necessity. FreeBSD users get away without that.

As for sound server stacking, due to the aforementioned problem you cannot have - say jack and pusleaudio directly on the same device. So you stack pulseaudio on top of jack, which interfaces to ALSA or OSS. I do the same thing on FreeBSD, BTW.
 
cracauer@ said:
Keep in mind that OSS and ALSA in Linux do not have an in-kernel mixer like FreeBSD does. They only allow one client at a time - which most people choose to be a sound server out of necessity. FreeBSD users get away without that.
Click to expand...
Ah, made sense.
And on FreeBSD ports (unfortunately I cannot recall what actually was), there were some audio/multimedia apps that grabs physical channel of OSS (without supports for vchans to allow kernel mixer to work) and having problems like on Linux you mentioned.

Sorry, too off-topic here.
 
LillieNB said:
I think I am just a minimalist in my nature, and I just cannot understand why someone needs an audio server on an audio server + the produced overhead, although the audio system present on the OS is already working.
Of course, if someone needs some specific audio server just to get an application to work, because company, or person x, y decided to drop support for your initial audio system then that is fine, but I would not accept it and search for ways to get my initial audio system to work like I did back then on arch linux with apulse, just to get ALSA working again on Firefox.
In the past I made a horrible experience with pulseaudio on ALSA, my cpu temp raised from 40 to 46 grade celsius while using an audio server on an audio server on Arch Linux, only because harry poetterings crafted wonder audio system which is just sitting on ALSA did something to raise the temps.
Click to expand...
Dunno, I just don't wanna spend my time trying to research this sound system, that sound system, features, drawbacks, and what not. For me, it's easier to just turn everything on, and NOT spend hours trying to connect the dots between lack of ALSA support and Firefox not working right. Besides, those sound systems compile fine, they don't need updates, they don't take up a truckload of disk space or CPU power... If one system is not working quite right, that's OK, I want Firefox to move on to the next one and not bother me.

If Firefox cannot move from ALSA to sndio (simply because it was compiled with support for one but not the other), and that starts causing CPU spikes, then yeah, I got a problem on my hands, especially one that could be avoided if FF were compiled with support for both.
 
Crivens said:
Good luck with maintaining that, really. I hear the big N isn't particularly fond of that.
Click to expand...
Right, Big N or Nintendou in Japanese.
I could cry out loud, really.
It is just I learned their langauge in just 4 months and passed the JLPT 1, and I wonder for which purpose learning 6 to 8 hours everyday like crazy.
Meeting almost everyday during this 4 months with Japanese people, and talking, and talking...
Japan was everything for me, games, music, food, even real people, and I wanted to play the Xenoblade Trilogy, or Quadrology with Xenoblade X Definitive Edition now releasing on March 2025.
Spent a huge amount of money which I saved for 1 year, just to enjoy Xenoblade 3 in 4K and almost stable 60 FPS, and and last year BIG N did, BIG N decided, and BIG N won.
Starting with YUZU, but the "tropic haze" group was at fault themselves, I cannot deny it that Nintendou was right in their decision.
However, GDKChan did nothing wrong.
Ryujinx is pure by design, and does not have a single line of nintendo code in it.
It uses LibHac to decrypt the games on the fly.
LibHac is a partly reimplementation of the reverse engineered horizon OS which the nintendo switch uses.
To my knowledge reverse engineering is sort of in a legal area, right?
GDKChan + team did absolutely nothing illegal, compared to YUZU which used Nintendos SDK for the firmware, and for decrypting games.

Another thing, Big N is not fond of Citron, too, but Zephyron does not care.
Torzu is also around, but Big N just does not reach them.
I do not like Yuzu or forks, because of theiry illegal activity, and vertex explosions in many games, but GDKChan + team did absolutely not deserve that kind of threatment, after putting in a lot of effort, too.
Big N can be fond, or not, I do not care, and I will not stop.
Ryujinx is legal, and nothing can claim against that.

Thank you, really... :)
I just see dreams of GDKChan and Ryujinx frequently, and it saddens me that GDKChan is away now...
Without GDKChan no one is really interested in Ryujinx anymore.
GreemDev is just a kid, and his attitude is nowhere near GDKChans.
GDKChan was really serious about Ryujinx, and I miss such kind of developers.
I miss GDKChan really much, but nothing to do, if I want to make something to work, I need to do it myself.
Stay tuned for Ryujinx on FreeBSD.
This is reality I guess.
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top