This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem.
I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.
> Once you're doing interop with C you're just writing C with Rust syntax
Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.
My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.
My perception is that the designers have taken their rough experience onboard and have now settled on a reasonable development model with an emphasis on achievable feature additions. The language server is astonishingly good, the feature set as it stands very much batteries included and the reaction time to highlighted discrepancies and a reasonable resolution very commendable. I’m an embedded dev so my opinions are biased accordingly but I do see some pretty awesome additions with vls, veb, vui etc. Of course, please conduct your own experiments and research but I’m incrementally optimistic.
You’re right. But consider that in order to be useful when not fused off, the design would need to have a bunch of additional logic (interconnect ports, power control machinery etc) at the periphery of the to-eventually-be-fused-off area that would likely remain even when things were fused off. That may impact power.
Apart from that there’s the other usual angles: The very fact that there’s additional logic in the compute path (eventually fused off) means additional design and verification complexity. The additional area, although dark, eats into the silicon yield at the fab.
A large motivation for this move is likely to ensure that attempts by some incumbent ISAs to lobby the US government to curb the uptake of RISC-V are stymied.
There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
Turning the ISA into an ISO standard helps curb such attempts.
Ethernet, although not directly relevant, is a similar example. You can't lobby the US government to outright ban or generally slow the adoption of Ethernet because it's so much of a universal phenomenon by virtue of it being a standard.
Then, there's NASA, and their rad hard HPSC RISC-V. It's a product now, with a Microchip part number (PIC64-HPSC1000-RH) and a second source (SiFive, apparently.) I suppose it's conceivable the a Berkeley CA developed ISA that has been officially adopted as new rad hard avionics CPU platform by the US government's primary aerospace arm could get voted off the island in some timeline, but it's looking fairly improbable at this point.
Only time will tell if it ends like: "to avoid someone else shooting us, let's shoot ourselves".
Dedicated consortiums like CNCF, USB Implementers Forum, Alliance for Open Media, IETF, etc are more qualified at moving a standard forward, than ISO or government bodies.
> There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
> Turning the ISA into an ISO standard helps curb such attempts.
Why do you think that would help? I fail to see how that would help.
An ISO standard is hard to gepolitically regulate, I would think.
It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous for folks to worry about it being turned into a strategic weapon.
Taking the previously mentioned ethernet example (not a perfect one I should accentuate again): why bother with blocking it's uptake when it is too fundamentally useful and enabling for a whole bunch of other innovation that builds on top.
You can’t (easily) make a standard go away but being a standard doesn’t stop anyone from making it illegal to use.
> It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous
Why do you think everything with an ISO standard is even remotely fundamental? There is an ISO standard for M/MUMPS (https://www.iso.org/standard/29268.html, https://en.wikipedia.org/wiki/MUMPS, for example, but I wouldn’t call it fundamental. Some systems would break if MUMPS became illegal, but fundamental requires more, IMO.
> The risks aren’t theoretical. A new report found that DeepSeek, a Chinese AI firm, has been responsible for producing malicious code in roughly half the sensitive cybersecurity incidents analyzed on GitHub. If China is willing to leverage open software in ways that harm global security, why would we assume open-source hardware will be treated differently?
> A single compromised RISC-V chip in a power grid, data center or weapons system could hand Beijing a quiet path into critical infrastructure. The more these chips spread, the greater the odds a vulnerability becomes a weapon.
I think the concern here is more with the implementations (coming out of China) than the instruction set itself. Or perhaps if there is some Verilog/VHDL code out there with backdoors, and that then gets baked into chips.
> I think the concern here is more with the implementations (coming out of China) than the instruction set itself.
Yes that is the pretense, but what they actually want to block is RISC-V adoption.
It's a bit similar to car industry opposition to right to repair, they ran TV ads claiming dangers for safety and security if independent repair were allowed. Louis Rossmann did a series of videos on this.
In such scenarios, the assembly routines lend themselves to relatively easier manual scrutiny - given that they are smaller in size compared to the much larger higher level language code in the project.
It's the latter that really needs the compiler's assistance to help remove memory safety issues (it is much harder for humans given the code size and complexity order). The fact that that safe higher level language code is inter operating with inherently unsafe code (as per the Rust definitions) is absolutely OK.
Reaching parity with Linux's immense suite of device drivers is perhaps the single biggest hurdle.
That's one of the biggest reasons why alternative kernels either remain fringe or fail.
Initiatives such as NetBSD's Rump kernel but for Linux may provide a bridge to Linux's drivers but it's brittle. There's already LKL - the Linux Kernel Library project with similar aims but not much traction.
