The same old arguments...

Posted Dec 7, 2025 4:58 UTC (Sun) by josh (subscriber, #17465)
In reply to: The same old arguments... by mirabilos
Parent article: Eventual Rust in CPython

> But they should!

> This is how we get hobbyist OSes… like Minix and then Linux.

> This is how we get hobbyist architectures, too.

No, it's not. We get hobbyist OSes (and other hobbyist projects) because the people working on them put in the work to make them happen, not because they can press other developers into service to make changes work on a target they were not seeking to work on.

Getting others to commit to *keep your OS or architecture working for you* is a very, very big ask. The correct answer in almost all cases is "no, the developers of that OS or architecture need to do all the work to maintain it".

> And then Rust cannot even use LLVM proper, only its own patched version.

This is incorrect misinformation. Rust builds just fine with standard LLVM. The only patches it carries in its branch of LLVM are the same kinds of bugfixes and backports that other users of LLVM carry.

> For a language that doesn’t even support dynamic linking?

C++ generics don't support dynamic linking either, and the only reason C++ is vaguely considered to "support" dynamic linking is when interfaces pointedly avoid them. Even then, it's been through a few rounds of ABI breakage. That's not something we're looking to put our users through, for a feature that most people don't require. It's a useful feature, by all means, and I expect that we'll support it eventually, using a model similar to what Swift did. But it's not a dealbreaker, and it's never likely to be the default, just something that extends the set of things supported over a library ABI boundary to beyond what C supports.

The same old arguments...

Posted Dec 7, 2025 8:09 UTC (Sun) by ssmith32 (subscriber, #72404) [Link]

Even more to the point: we got Linux because a big OS with many users _did not_ support every use case.

In fact, I would say the lack of support for niche platforms encourages hobby projects..

The same old arguments...

Posted Dec 7, 2025 9:39 UTC (Sun) by Sesse (subscriber, #53779) [Link] (5 responses)

> C++ generics don't support dynamic linking either

This is only true for a pretty narrow definition of “support”. It is true that _someone_ has to monomorphize the generic before it can be linked (since the only real experience AFAIK is either a VM or type erasure?); but that's true whether we're talking static or dynamic linking. Lots of C++ dynamic libraries expose functions involving these specializations; e.g., std::string is a generic (std::basic_string<char>) and libstdc++.so exposes a lot of functions related to it. In practice, you can upgrade libstdc++ pretty freely without anything related to vector, string, map, etc. breaking—but you can't easily change their internals, since they become effectively part of the ABI (like so many other things in C).

The same old arguments...

Posted Dec 7, 2025 18:43 UTC (Sun) by JoeBuck (guest, #2330) [Link] (4 responses)

Right; I expect that at some point the most commonly used generics in the standard library will have their implementations frozen enough so that a stable ABI can be produced and dynamic linking can be supported in Rust in more cases. This was done for C++ long ago.

The same old arguments...

Posted Dec 7, 2025 18:58 UTC (Sun) by josh (subscriber, #17465) [Link] (3 responses)

I doubt we'll ever stabilize the internal layout of anything more complicated than `Result` or `Option` (and even for those, doing so means giving up on any further opportunities for niche optimization, the mechanism by which types like `Option<&T>` is the same size as `&T`).

For something like `Vec` or `HashMap`, the most likely path to stabilization is an opaque pointer plus a vtable of methods.

The same old arguments...

Posted Dec 7, 2025 23:40 UTC (Sun) by JoeBuck (guest, #2330) [Link] (2 responses)

That would be crazily inefficient for Vec<i32> or other vector of atomic type. If the call is not inlined, the structure could be frozen, as it is for std::vector<int> in C++ when libstdc++ is in use. Likewise for string slice arguments.

The same old arguments...

Posted Dec 7, 2025 23:43 UTC (Sun) by josh (subscriber, #17465) [Link] (1 responses)

We could nail down slices easily enough. It might potentially be reasonable to give *some* direct access to `Vec`, since the triple of pointer, length, and capacity is the obvious implementation; that would allow efficient and vectorized access to the data. However, for instance, reallocation would likely still require a vtable call.

The same old arguments...

Posted Dec 9, 2025 19:41 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

After careful consideration, I don't think Vec needs vtables for reallocation, because those vtables really should attach to Allocator instead of Vec. But we do need some ABI glue that currently does not exist:

* In the case of Vec<T> a/k/a Vec<T, Global>, Global is a well-known ZST that can be statically dispatched. No need for a vtable. This is the most common case, so ideally it should not be pessimized in order to support other cases (especially seeing as the global allocator can be replaced). The foreign code will need to call into Rust's global allocation routines, but you have to do that even in the (default) case where Global delegates to System, so that's unavoidable.
* In the case of Vec<T, A> where A is a ZST or never dropped, the ABI needs glue code to coerce the whole thing into Vec<T, &'static dyn Allocator>, and then the vtable logic lives in Allocator where it belongs. I'm assuming, of course, that we can also nail down the ABI of &dyn Trait, which is a whole other kettle of fish. But at least dyn Trait is explicitly designed to support dynamic dispatch - most of the technical choices have already been made.
* In the case of Vec<T, &'a A>, it's the same story but with a lifetime parameter. Not sure how well that translates over the ABI, but at least lifetimes add no extra gunk at runtime.
* In the general case, the Vec might own an allocator, which might not be a ZST. That coercion is more complicated because now the Vec itself is of unknown size (it directly contains the allocator's fields). I would be inclined to declare that as unsupported or at least out of scope for language-level support, in the interests of not overly pessimizing Vec<T, Global> to support a niche corner case. Probably it could still be supported at the library level by decoupling the ownership of the Allocator from the Vec, and instead passing Vec<T, &'a dyn Allocator>. But that conversion is complicated and unsafe, so maybe some kind of glue code would be helpful here as well. Or maybe this version of Vec really does need a vtable.

The same old arguments...

Posted Dec 7, 2025 20:56 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (2 responses)

> We get hobbyist OSes (and other hobbyist projects) because the
> people working on them put in the work to make them happen

Yes. But that only works if the upstreams accept such work and don’t not only put too many hurdles in for hobbyists and raise complexity but also actively throw sticks and stones into their paths and extort “protection” money (money to merge the patches).

The same old arguments...

Posted Dec 7, 2025 23:45 UTC (Sun) by josh (subscriber, #17465) [Link]

Certainly there's no call to make it intentionally harder. But resources like CI systems and maintainer time do have a cost. Framing that as "protection money" is disingenuous.

The same old arguments...

Posted Dec 8, 2025 22:56 UTC (Mon) by intelfx (subscriber, #130118) [Link]

> Yes. But that only works if the upstreams accept such work and don’t not only put too many hurdles in for hobbyists and raise complexity but also actively throw sticks and stones into their paths and extort “protection” money (money to merge the patches).

As I'm sure you are aware, in FOSS, every project has the fundamental moral right to "self-determinate": to decide what, if any, level of formal or informal support and guarantees it wishes to make.

You normally hear about this in context of projects having the moral right to provide no guarantees and no support: the proverbial "as is". However, this works both ways. If a project, such as Rust, wishes to hold themselves to a higher standard — such as requiring all code to pass CI before declaring a target is supported — **YOU CANNOT STOP THEM FROM DOING SO**.

Calling this "extorting protection money" is so disingenuous and hostile that you should honestly be ashamed of saying that.

The same old arguments...

Posted Dec 12, 2025 18:25 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

Getting others to commit to *keep your OS or architecture working for you* is a very, very big ask.

As someone who wants to keep the software I maintain working on minority hardware and software, I certainly won't use Rust in its current state for it. And reading some of the opinions expressed in the present discussion makes me happy that our project does not depend on CPython.

The same old arguments...

Posted Dec 12, 2025 20:22 UTC (Fri) by mirabilos (subscriber, #84359) [Link]

Thanks, that’s a statement that’s nice to read.

----

I’m also always surprised how ⓐ people go from “please merge my patches and just try to not actively break my arch” to “forcing others to commit to keep your OS or architecture working for you”, and ⓑ why that would even be onerous.

I mean, I’m not in the habit of writing shitty code that fails on other CPUs or (unixoid, mostly, as the things I write tend to target unixoid) OSes.