Earlier quoted context omitted.
[flagged]
“Done software”?
[flagged]
What it means that Ubuntu is using Rust
81–90 of 312 posts
Re: What it means that Ubuntu is using Rust
#82Earlier quoted context omitted.
As unsafe as C or C++. In fact, safer, because only the ABI surface is unsafe, the rust code behind it can be as safe or unsafe as you want it to be. I was addressing this portion of your comment: "C's ABI and dynamic linking are the thing that enables the software to get huge". If the C ABI is what enables software to get huge then Rust is already there. There is a second claim in your comment about a "safe ABI", bu…
Here's the problem. If you told me that you rebuilt the Linux userland with Rust but you used C ABI at all of the boundaries, then I would be pretty convinced that you did not create a meaningful improvement to security because of how many dynamic linking boundaries there are. So many of the libraries involved are small, and big or small they expose ABIs that involve pointers to buffers and manual memory management.…
What you are asking for is to make a library definition replacement to .h-files that contain sufficient information to make rust safe. That is a big, big step and would be fantastic not only for rust but for any other language trying to break out of the C tar pit.
Re: What it means that Ubuntu is using Rust
#83Why am I hearing about Rust a lot these days? Did anything significant happen?
there has been a few adopters of rust... linux formally choosing it for some of their systems being the most notable recently(maybe a few months ago).
Re: What it means that Ubuntu is using Rust
#84Earlier quoted context omitted.
That is a reason why a lot of folks stick with C. In some sense, the chasm I'm describing hasn't been crossed by C++ yet
Except as you well know, C might not change as fast, but it does change, including the OS ABI. Those folks think it doesn't.
> Except as you well know, C might not change as fast, but it does change, including the OS ABI.
I don't know that.
Here's what I know: the most successful OSes have stable OS ABIs. And their market share is positively correlated with the stability of their ABIs.
Most widely used: Windows, which has a famously stable OS ABI. (If you wanted to be contrarian you could say that it doesn't because the kernel ABI is not stable, but that misses the point - on Windows you program against userland ABIs provided by DLLs, which are remarkably stable.)
Second place: macOS, which maintains ABI stability with some sunsetting of old CPU targets. But release to release the ABI provides solid stability at the framework level, and used to also provide stability at the kernel ABI level (not sure if that's still true - but see above, the important thing is userland framework ABI stability at the end of the day).
Third place: Linux, which maintains excellent kernel ABI stability. Linux has the stablest kernel ABI right now AFAIK. And in userland, glibc has been investing heavily in ABI stability; it's stable enough now that in practice you could ship a binary that dynlinks to glibc and expect it to work on many different Linuxes today and in the future.
So it would seem that OS ABIs are stable in those OSes that are successful.
Re: What it means that Ubuntu is using Rust
#85Earlier quoted context omitted.
FWIW, the GP comment's claim that you're lucky if you can compile 2-year-old code is exaggerated, but so is yours. Rust does not offer "strong stability guarantees". Adding a new method to a standard type or trait can break method inference, and the Rust standard library does that all the time. In C or C++, this isn't supposed to happen: a conformant implementation claiming to support e.g. C++17 would use ifdefs to g…
> and the Rust standard library does that all the time. I don't doubt this is true, but do you have an example? I think I haven't run into a build breaking like this in std in like maybe seven/eight years. In my experience breaking changes/experimental apis are typically ensconced in features or gated by editions. Granted, it'd be nice to be able to enforce abi stability at the crate level, but managing that is its o…
Almost every major release of rust stabilizes new library methods. For example, the latest major release (1.93) stabilized Vec::into_raw_parts. This isn’t gated by an edition. So if you had a trait with a method “into_raw_parts” which you had defined on Vec, after updating to 1.93 or later your code will either fail to compile, or start running different code when that method is called.
Sorry, I meant to write “method resolution”, not inference. This isn’t the same issue as type inference (though indeed, stdlib changes can break that too)
Re: What it means that Ubuntu is using Rust
#86Earlier quoted context omitted.
How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.
I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to…
> I don’t think GP is moving the goalposts at all
Thank you :-)
> It would be very hard to accomplish.
Yeah it's a super hard problem especially when you provide safety using the type system!
The work the Swift team did here is hella impressive.
> But if you could wave a magic wand and make it “done”, it would be huge for rust adoption.
Yeah!
Re: What it means that Ubuntu is using Rust
#87Here's the chasm I want to see Rust cross: Dynamic linking with a safe ABI, where if you change and recompile one library then the outcome has to obey some definition of safety, and ABI stability is about as good as C or Objective-C or Swift. Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.
Indeed, Victor Ciura from Microsoft DevDiv has several talks on how this is currently an adoption problem at Microsoft. They have been working around it with DLLs, and COM/WinRT, but still the tooling isn't ideal.
COM is interesting as it implements interfaces using the C++ vtable layout, which can be done in C. Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.
You can also access .NET/C# objects/interfaces via COM. It has an interface to allow you to get the type metadata but that isn't necessary. This makes it possible to e.g. get the C#/.NET exception stack trace from a C/C++ application.
Re: What it means that Ubuntu is using Rust
#88Earlier quoted context omitted.
for developer turnaround time, it is huge. we explicitly do not statically link Ardour because as developers we are in the edit-compile-debug cycle all day every day, and speeding up the link step (which dynamic linking does dramatically, especially with parallel linkers like lld) is a gigantic improvement to our quality of life and productivity.
A common pattern is dynamic linking for development and static linking for production-ready releases.
We considered doing both, but it turned out that the GUI toolkit we use was really, really not designed to be statically linked, so we stopped trying.
Re: What it means that Ubuntu is using Rust
#89Earlier quoted context omitted.
> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge. Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).
That's an unsafe ABI.
A safe ABI would be cool, for sure, but in the market (specifically addressing your prediction) I don't know if it's really that big a priority for adoption. The market is obviously fine with an unsafe ABI, seeing how C/C++ is already dominant. Rust with an unsafe ABI might then not be as big an improvement as we would like, but it's still an improvement, and I feel like you're underestimating the benefits of safe Rust code as an application-level frontline of security, even linked to unsafe C code.
Re: What it means that Ubuntu is using Rust
#90Earlier quoted context omitted.
for developer turnaround time, it is huge. we explicitly do not statically link Ardour because as developers we are in the edit-compile-debug cycle all day every day, and speeding up the link step (which dynamic linking does dramatically, especially with parallel linkers like lld) is a gigantic improvement to our quality of life and productivity.
A common pattern is dynamic linking for development and static linking for production-ready releases.
Yes, that's a good way to do it.