Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What it means that Ubuntu is using Rust

smallcultfollowing.com

Post reply on HN
Print view View original

141–150 of 312 posts

Re: What it means that Ubuntu is using Rust

#141

Post by josefx »

MindSpunk wrote: post #138
pizlonator wrote: post #30

Earlier quoted context omitted.

That's an unsafe ABI.

What is a safe ABI? An ABI can't control whether one or both parties either end of the interface are honest. You can't have safe dynamic linking, dynamic linking requires you to trust the library you load with no ability to verify.

> An ABI can't control whether one or both parties either end of the interface are honest.

You are aware that Rust already fails that without dynamic linking? The wrapper around the C getenv functionality was originally considered safe, despite every bit of documentation on getenv calling out thread safety issues.

Re: What it means that Ubuntu is using Rust

#142

Post by jabl »

staticassertion wrote: post #127
rlpb wrote: post #126

Earlier quoted context omitted.

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.

Oh, well yeah, statically linked binaries have that downside. I guess I don't think that's a big deal, but I could maybe imagine on some devices that are heavily constrained that it could be? IDK. Compression is insanely effective.

If Rust and static linking were to become much more popular, Linux distros could adopt some rsync/zsync like binary diff protocol for updates instead of pulling entire packages from scratch.

Re: What it means that Ubuntu is using Rust

#143

Post by merb »

pizlonator wrote: post #69
duped wrote: post #63

Earlier quoted context omitted.

How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.

> How could a safe dynamic linking API ever work? Fil-C solves it. I think Swift solves it, too. So it's solvable. No fundamental reason, that I know of, why Rust or any other safe language can't also have some kind of story here. > I think you're moving the goalposts significantly here. No. I'm describing a problem worth solving. Also, I think a major chasm for Rust to cross is how defensive the community gets. It's…

Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.

Re: What it means that Ubuntu is using Rust

#144

Post by hombre_fatal »

bigstrat2003 wrote: post #140
moomin wrote: post #104

.NET has a _huge_ platform library and you know what? It’s a pleasure. So many things are just the standard way of doing things. When things are done weirdly, you can usually get a majority in favour of standardising it. Yes, there’s always a couple of people who really push the boat out…

Yeah, IMO the small standard library in Rust is a big mistake, one of the few the language has made. When push comes to shove the stdlib is the only thing you can count on always being there. It's incredibly valuable to have more tools in the stdlib even if they aren't the best versions out there (for example, even if I normally use requests in Python urllib2 has saved my bacon before), and it doesn't hurt anything t…

On the other hand, a worse implementation in the stdlib can make it harder for the community to crystalize the best third-party option since the stdlib solution doesn't have to "compete in the arena".

Go has some of these.

Maybe a good middle-ground is something like Rust's regex crate where the best third-party solution gets blessed into a first-party package, but it is still versioned separately from the language.

Re: What it means that Ubuntu is using Rust

#145

Post by choeger »

pizlonator wrote: post #13

Here'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.

That would be great, but Rust relies on compile-time monomorphization for efficiency (very much like C++, if you consider templates polymorphic functions/classes).

This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider the usage of the "shape" of all parameters of a function.

Re: What it means that Ubuntu is using Rust

#146

Post by tonyedgecombe »

rhdunn wrote: post #87
pjmlp wrote: post #70

Earlier quoted context omitted.

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.

>Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.

DCOM is Distributed COM not Dynamic COM[1].

COM does have an interface for dynamic dispatch called IDispatch[2] which is used for scripting languages like VBScript or JScript. It isn't required for Visual Basic though. VB is compiled and supports early binding to interfaces.

[1] https://en.wikipedia.org/wiki/Distributed_Component_Object_M...

[2] https://en.wikipedia.org/wiki/IDispatch

Re: What it means that Ubuntu is using Rust

#147

Post by jabl »

ninkendo wrote: post #73
duped wrote: post #63

Earlier 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…

> You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/

> It would be very hard to accomplish.

Since Rust cares very much about zero-overhead abstractions and performance, I would guess if something like this were to be implemented, it would have to be via some optional (crate/module/function?) attributes, and the default would remain the existing monomorphization style of code generation.

Re: What it means that Ubuntu is using Rust

#148

Post by jabl »

bigstrat2003 wrote: post #140
moomin wrote: post #104

.NET has a _huge_ platform library and you know what? It’s a pleasure. So many things are just the standard way of doing things. When things are done weirdly, you can usually get a majority in favour of standardising it. Yes, there’s always a couple of people who really push the boat out…

Yeah, IMO the small standard library in Rust is a big mistake, one of the few the language has made. When push comes to shove the stdlib is the only thing you can count on always being there. It's incredibly valuable to have more tools in the stdlib even if they aren't the best versions out there (for example, even if I normally use requests in Python urllib2 has saved my bacon before), and it doesn't hurt anything t…

I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib.

With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it.

Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see.

But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?

Re: What it means that Ubuntu is using Rust

#149

Post by hamandcheese »

rlpb wrote: post #126
staticassertion wrote: post #124

Earlier quoted context omitted.

How much overhead is that? Also, why would that have much overhead? Things deduplicate in memory.

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.

NixOS "suffers" from this. It's really not that bad if you have solid bandwidth. For me it's more than worth the trade off. With a solid connection a major upgrade is still just a couple minutes.

Re: What it means that Ubuntu is using Rust

#150

Post by rlpb »

hamandcheese wrote: post #149
rlpb wrote: post #126

Earlier quoted context omitted.

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.

NixOS "suffers" from this. It's really not that bad if you have solid bandwidth. For me it's more than worth the trade off. With a solid connection a major upgrade is still just a couple minutes.

A couple of minutes at the moment that is, with dynamic linking everywhere. What will it become when everything is statically linked?
Post reply on HN