FreeBSD, instead of looking at Rust should look at Zig

Underrated language you meant? C is raw power; you have to take care of managing this power. UNIX has been written in C, and if someone claims he can do better, I'll say: just do it!
 
Underrated language you meant? C is raw power; you have to take care of managing this power. UNIX has been written in C, and if someone claims he can do better, I'll say: just do it!

It's not just a matter of coming up with a better language. It is also a matter of managing a mixed-language system. And that doesn't seem to go very well for the Linux kernel in the case of Rust.

Zig is said to have more streamlined FFI.
 
If you need more features, you write them yourself.
This is true - to date I can get everything I need to get done in "C". This largely applies to "C++" as well since you can just write standard "C" code side-by-side with your "C++" code. Heck throw in a little assembly code into the source files as well just to mix it up.

I think we are all interested in "new" stuff -- but the new stuff need to be a lot more flexible. I don't really understand when someone tells me "No, I can't link and use your C/C++ static/dynamic .so/.a library". And then quickly adds: "Anyway - I am going to "rewrite" that entire .so/.a library into (insert language) and use that instead". Have fun !
 
Zig is said to have more streamlined FFI.
Zig bindings do better than others, but still a little fiddly. But the cost is that the language is almost as unsafe as C. It has allocators and defer but pointers can still absolutely dangle.

But... ZigCC is actually a very decent packaging of the Clang compiler as a seamless C/C++ cross compiler, also distributing the runtime libs. Its kind of how Plan 9 handles its compilers. As an example, you can use Zig C++ on UNIX-like platforms to compile a Windows (MinGW binary) or a Linux Arm64 binary.

$ zig cc -target x86_64-windows-gnu main.c -o main.exe

$ zig cc -target aarch64-linux-gnu main.c -o main

Its just clang underneath but Zig collates all their libc / runtimes together.
 
Don't get me wrong. Rust is interesting. But there are issues with it (bindings, portability, limited vendors, etc) that mean it likely won't saturate the market in our lifetime. So professionally you are limiting yourself if you are solely focused on Rust.
Don't forget ridiculous compile times and the bloat you get from their download-the-Internet package manager.
 
This might be worth having a look at. MCGA - I like it 😁

I couldn't find a red cap so this will have to do! The brim is red anyway, and the future's so bright, you got to wear shades.

1763229817106.png


There is also "safe C" that has been around for ages.

I don't have any experience with either of them, but at least they should be linkage compatible with C.
 
This might be worth having a look at. MCGA - I like it 😁

I couldn't find a red cap so this will have to do! The brim is red anyway, and the future's so bright, you got to wear shades.

View attachment 24176

There is also "safe C" that has been around for ages.


I don't have any experience with either of them, but at least they should be linkage compatible with C.

where does one acquire this hat plz thx
 
It's not just a matter of coming up with a better language. It is also a matter of managing a mixed-language system. And that doesn't seem to go very well for the Linux kernel in the case of Rust.

Bindings seems to be a trap, don't you think a new language should start from scratch? This will avoid time wasted on mixing languages, for example Redox OS. Yes, I know: big work ahead.
 
Bindings seems to be a trap, don't you think a new language should start from scratch? This will avoid time wasted on mixing languages, for example Redox OS. Yes, I know: big work ahead.

Well, as I said, I see the requirement for bindings as a problem.

But an OS from scratch without the ability to re-use existing code for drivers in particular will have a very hard time. Same for the network stack. Even Microsoft had to re-use open source code for their first TCP/IP stack.
 
An also very interesting question is: how many non-rust-developers have any active interest in Redux? To what extent is there a real problem that Rust addresses?

If the market was there, the drivers would come. I guess nobody is going "when will Rust finally come to deliver us from the shackles of this piece of crap c software."
 
Can we please keep on track in this thread? If you want to debate other "mine is better than yours" topics, please open another thread for that (within the rules of this forum of course).
 
Back
Top