Oh no, it is. You need to go straight down to the metal, Mano a Mano with each bit in the CPU status registers. I'd like any high level language to try this. The reason rust links to C and an OS us that otherwise they would need to link to assembler. But it can't be rust all the way down.
Sounds like programming a PDP-11/45 with the flip switches on the front...
For today it's enough to jump start your code from a JTAG. You don't need to (as I did once upon a time) write a converter from binary image to verilog code to be loaded into the bus controller as an EPROM substitute. That machine had no switches and no JTAG. But hey, it worked. The boot loader/monitor started as expected.
I respectfully disagree. I believe in using the right tool for the job. My little machine shop in the basement has 80 square feet (8 square meters) of wall covered in pegboard, with tools hanging on it. There isn't one screwdriver, there are a dozen different ones, for different tasks. In the last 24 hours alone, just for home projects, I've programmed in C, Python and SQL, all integrated together. This evening (if I have any energy left after yard work), I'll add some shell script and a way to hook two python programs together via ssh.
No way. SDL is in C doing things the C way. The point is to do things the Rust and/or memory managed way.
Alright, well, how did they do?
Unsafe (in rust terminology) inline assembly. E.g. this is PIO:
/// Read/Write for word PIO
impl Io for Pio<u16> {
type Value = u16;
/// Read
#[inline(always)]
fn read(&self) -> u16 {
let value: u16;
unsafe {
asm!("in ax, dx", in("dx") self.port, out("ax") value, options(nostack, nomem, preserves_flags));
}
value
}
doc.rust-lang.org
doc.redox-os.org
Embedded programming can be quite interesting. Though most of it is done in C/C++ (or asm or 4th). Rust is starting to be used....
And using libX11 solves that instead somehow? I doubt it. For one the APIs between SDL and libX11 are actually very similar.
In that case, it still doesn't quite make sense (the article, rather than msplsh), as per the Cargo.toml. They are simply using libwayland-client (also written in C) instead of libSDL or libX11.
This is the way. If it ever happens, this I think is the only way that Rust can get out of C's shadow.
It's irrelevant that those companies support Rust. They gave up their code to a permissive license. It could also be said about LLVM/Clang compiler and lots of FreeBSD components which code is donated by companies to permissive or other opensource licenses. If were one company behind a language, which that company solely depended on it, it could be the case of the for profit conflict of agendas. Rust is maintained independent of those companies, even though it gets their help. Competing companies working together is also for the benefit of a language neutral to different companies so it can benefit all and become a standard.
Whilst I don't think this is a problem specifically, it certainly explains why there is such an artificial hype around what is effectively, a fairly mediocre language. Their marketing budgets are vast!
I would see it on who's behind of Rust language in terms of language maintenance and development and who is behind C/C++?
C/C++ is maintained by ISO/IEC JTC 1/SC 22C++ - Wikipedia
en.wikipedia.org
What's your point here? FreeBSD has to do this?
I thought you asked how they did "everything" in Rust in#407:
I obviously mis-read the discussion between you and Crivens as to how they achieved it "all in Rust".
The difference is that C has no need to be C all the way down to deliver on a promise.