The Case for Rust (in the base system)

It's my fault the Pascal or it's derivation Delphi discussion in this thread.
My point was it has to be a wise decision what language you chose for a project in terms of code maintenance over the live expectancy of the project.
The risk is quite obvious, to start over in case no one else will want to maintain that project as it will get archived over the years and getting dust... or rust.
 
rmomota said:
It's my fault the Pascal or it's derivation Delphi discussion in this thread.
My point was it has to be a wise decision what language you chose for a project in terms of code maintenance over the live expectancy of the project.
The risk is quite obvious, to start over in case no one else will want to maintain that project as it will get archived over the years and getting dust... or rust.
Click to expand...
In that case, implementing the FreeBSD kernel in C was a friggin' smart idea... 😏
 
Alain De Vos said:
In space ,
github.com

GitHub - n7space/aerugo: Safety-critical applications oriented Real-Time Operating System written in Rust

Safety-critical applications oriented Real-Time Operating System written in Rust - n7space/aerugo
github.com github.com
Click to expand...
How about this:
github.com

GitHub - flosse/rust-os-comparison: A comparison of operating systems written in Rust

A comparison of operating systems written in Rust. Contribute to flosse/rust-os-comparison development by creating an account on GitHub.
github.com github.com
 
dchmelik said:
Didn't most/all Rust development team ragequit because of mismanagement/scandal and those remaining are burnt-out? Doesn't seem like a good candidate.
Click to expand...

Yeah... this sounds like a familiar pattern of a trumped-up software whose devs got so disgruntled they broke the Internet. I now avoid node.js, and it looks like rust is falling into the same trap of unsustainable project management practices. Even if rust has technical merits, knowing that the project is a mess has me thinking that it probably won't last...
 
bakul said:
That’s Brian Kernighan holding John Lions’ book.
Click to expand...
blackbird9 said:
Ha, you're right :D, I thought he looked strangely familiar! The absence of a blue jumper was what fooled me! Corrected!
Click to expand...

Kernighan and P.J. Plauger also co-wrote the excellent Software Tools books. I still have my Software Tools in Pascal, which had a profound influence on my software since the late '70s, not least for rendering many of those tools into Chung & Yuen's Tiny (aka People's) Pascal as gifted in three Byte Magazine articles around then - later as Tandy TRS-80 Pascal - which I ported to the Signetics 2650 CPU of a popular kit micro in Australia from ~1976.

Please excuse my nostalgia for some things very few here will remember, let alone with any fondness! <&^}=
 
blackbird9 said:
And the classic: https://seriouscomputerist.atariverse.com/media/pdf/book/Pascal - Manual & Report.pdf
Click to expand...

Indeed. Slight pity about the 'ghosted' column down the middle of most pages, but intent is usually clear.

Shows how much Borland and later FreePascal people, while respecting keeping everything pure in the 'teaching' definition of the language, added the essential additions needed for widespread practical use, in the same spirit.

For comparison, can someone point to a quick tutorial on Rust including BNF diagrams, ono?
 
dchmelik said:
Didn't most/all Rust development team ragequit because of mismanagement/scandal and those remaining are burnt-out? Doesn't seem like a good candidate.
Click to expand...
It seems Rust is more hype than reality. There are comments, such as, "It's taking the world by storm."

If so, why are there only 814 jobs on LinkedIn for Rust programming? C++ has 407,000+ jobs listed.
 
cracauer@ said:
Maybe the Rust programmers are that much more productive? :) High turnover in C++ jobs?
Click to expand...
Perhaps. But that would be the HUUUUUUUUGEST productivity curve in the history of programming languages ;) Except for maybe the elimination of punch cards!

Go was released in March 2012 while Rust was released in May 2015. One can argue that Go has wider adoption than Rust. That may be due to Google. But the NSA telling everyone to stop using C/C++ doesn't seem to have the same effect as Google and the former Plan 9 guys and Ken Thompson working on Go. FWIW, Rob Pike retired.
 

Google Making $1M USD Investment To Improve Rust & C++ Interoperability​

Google Making $1M USD Investment To Improve Rust & C++ Interoperability - Phoronix

www.phoronix.com www.phoronix.com

That will be interesting. C++ is kind of nasty to interface with if you don't want to through pure C code. They will probably leverage LLVM to give them all the metainformation they need. Whether C++ templates will be covered I find doubtful.
 
That is interesting about Google. Not to hijack this thread which is about Rust in the base system, but has anyone read about OpenBSD's new pinsyscalls(2)?

pinsyscalls(2) has gone into the tree without too much difficulty, and no
issues are currently known.

None of this could have been possible without help from a few groups of
people.
Click to expand...
- gnezdo@ and others for early on reviewing the ports tree and removing (or
at least reducing) calls to syscall(2)
- afresh1@, who followed my guidance and over 6 months wrote a syscall(2)
emulator inside perl
- But most of all -- jsing@, who went through multiple iterations inside
the go ecosystem to (1) force it to use libc system call stubs, which
permitted msyscall(2), and (2) incrementally remove use of syscall(2)
inside go and go libraries.

The direct-syscalls-inside-the-binary model used by go (and only go, noone
else in the history of the unix software does this) provided the biggest
resistance against this effort.

Start to end, this took 5 years.

Together with library relinking, this makes some specific low-level attack
methods unfeasable on OpenBSD, which will force the use of other methods.
Hopefuly those other methods are more difficult, or also harmed by library
relinking and other changes we've made.

This is all about removing avenues, and forcing attackers to use other
methods which are hopefully more challenging.
Click to expand...
Click to expand...
I wonder if Google will run into the same implementation problems OpenBSD faced with Go using libc system call stubs, but that may be due to no one else doing direct-syscalls-inside-the-binary model as written by Theo.
 
bakul said:
A friend who works with LLVM and MLIR, etc. has this to say about Rust:
Click to expand...
In the last couple of years - I am seeing rust-like terminology (like "borrow checking") appear in the discussions of other languages. Even if Rust does not take over the world, it has made an impact.
 
gpatrick said:
That is interesting about Google. Not to hijack this thread which is about Rust in the base system, but has anyone read about OpenBSD's new pinsyscalls(2)?


I wonder if Google will run into the same implementation problems OpenBSD faced with Go using libc system call stubs, but that may be due to no one else doing direct-syscalls-inside-the-binary model as written by Theo.
Click to expand...

That's quite bad badger territory. Even SBCL doesn't use system calls directly.
 
cracauer@ said:
That will be interesting. C++ is kind of nasty to interface with if you don't want to through pure C code. They will probably leverage LLVM to give them all the metainformation they need. Whether C++ templates will be covered I find doubtful.
Click to expand...
Indeed. I know Apple is still not entirely happy with their Swift <-> C++ interop. Its still a bit in a state of "evolution".

https://www.swift.org/documentation/cxx-interop/

But its definitely tricky, C++ has so many "edges" that even slightly different eras of C++ can barely interop with itself successfully.

I can't see it being possible from a language level personally. Without seriously restricting to a subset. Your mentioned idea of approaching it at a more LLVM level could be interesting.
 
cracauer@ said:

Google Making $1M USD Investment To Improve Rust & C++ Interoperability​

Google Making $1M USD Investment To Improve Rust & C++ Interoperability - Phoronix

www.phoronix.com www.phoronix.com

That will be interesting. C++ is kind of nasty to interface with if you don't want to through pure C code. They will probably leverage LLVM to give them all the metainformation they need. Whether C++ templates will be covered I find doubtful.
Click to expand...
Just a million? That's barely enough to hire someone for a little over a year on Google's campus... and maybe not even that long... and it's Google... 🤷‍♂️

gpatrick said:
One can argue that Go has wider adoption than Rust. That may be due to Google. But the NSA telling everyone to stop using C/C++ doesn't seem to have the same effect as Google and the former Plan 9 guys and Ken Thompson working on Go. FWIW, Rob Pike retired.
Click to expand...
Let's leave unsavory politics out of this conversation... 😩 otherwise I'm gonna accuse kpedersen of being a Taylor Swift fanboi just because he quoted something from https://www.swift.org 😂
 
cracauer@ said:
The problem, however, is that almost all attempts to do better in a GC-less statically typed language have been screwed up. What is different about about Rust is that we don't yet know whether it is screwed up.
Click to expand...
I would take the position that we do not know in which way it is screwed up. There seems to be a fundamental problem with manual resource tracking and no amount of work will fix that - just like the halting problem (also known as a compiler writers full employment theory).
T-Aoki said:
As most C compilers support inline assembly codes, even assembly codes coulde be included in header files for C. Not meaning "pure C", but "practical C". And if I recall correctly, ancient C compilers had as(1) in its build pipeline.
Click to expand...
And there are rules not to use them. Yes, ancient compilers did have an "as" pass, and they had several passes before them. The reason was memory space. Not allowing people to sprinkle assembly into the codebase.
 
FYI:
On main (aka -current), libc was splitted into syscall part as libsys and remaining part kept as libc by Brooks Davis. Now syscall part of libc remains as a filter (thunk) layer to pass though to libsys. Heads up is here in freebsd-curret ML.
Following posts in the thread would help understanding and clarification.
I don't think it would be MFC'ed at least for now, but it could help languages other than C/C++ not to be tied to libc, but should still need to support C ABI (calling conversion) to call it.

First commit for preparation:
src commit 9cbd96582c0ac133f911270a47bff189d769ac8d

First actual commit:
src commit 8269e7673cf033aba67dab8264fe719920c70f87
 
dchmelik said:
Didn't most/all Rust development team ragequit because of mismanagement/scandal and those remaining are burnt-out? Doesn't seem like a good candidate.
Click to expand...
This rumor gets tossed about a lot. Based on what I see in rust development communities, rust development pace hasn't slowed down.
Could be that the rumor isn't true?
 
You must log in or register to reply here.
Back
Top