Debian, Rust, and librsvg

Posted Nov 14, 2018 15:57 UTC (Wed) by glaubitz (subscriber, #96452)
In reply to: Debian, Rust, and librsvg by josh
Parent article: Debian, Rust, and librsvg

>> Adding a new frontend means you get a second, independent implementation of the language which is always of advantage.

> Not at all, no. A second, independent implementation is only interesting if it provides features the primary implementation *cannot*, and still keeps up with the primary implementation. I'd much rather see rustc itself add the necessary portability and provide the same functionality everywhere.

Well, then we have a different opinion on that. I think it's definitely valuable to have a second, independent implementation of the language. This would also help with standardization.

> As far as I can tell, the *only* justification for mrustc (an implementation which only works for code already verified as correct by rustc) is for diverse double-compilation; nobody is seriously proposing using mrustc for other purposes.

There is nothing though that speaks against using mrustc for other purposes. Most upstream projects which are using Rust are not using the latest features of the language all the time, so I guess many projects will build just fine with mrustc.

>> All these usecases are being excluded from Rust because there is only one non-portable variant of the Rust compiler.
> "non-portable" is hyperbole; it can already target many architectures, including 14 of Debian's architectures.

Ignoring the fact that it's currently broken again on multiple Debian release architectures in Debian experimental.

Don't you think it's a bit of the burden for the Rust maintainers in Debian if they constantly have to fix these issues over and over again because Rust upstream doesn't provide an LTS variant of the language? And what's the point having to constantly update and fix compiler regressions when many upstream projects aren't using the latest features anyway.

I sometimes have the impression that Rust is primarily developed for the language's own sake instead of providing a useful language for projects to adopt.

> But no, all those usecases are only missing from Rust because nobody has done the work. Those architectures could have an LLVM target, and a Rust target, if a group of developers contributed them *and committed to ongoing maintenance*. Or if someone was sufficiently motivated to produce a GCC backend, they could.

Well, I know of two very important upstream projects that have contemplated using Rust code in their projects but have discarded the idea because of the issues I mentioned.

>> It's simply a missed opportunity to make Rust more successful. I don't understand why Rust upstream isn't interested in that.

> I really don't think Rust upstream is bemoaning the loss of potential popularity to be had there. Such decisions are tradeoffs, and it's not unreasonable to consider what would be traded off in exchange.

Well, after my post to debian-devel-announce, I received exactly this feedback from two very important upstream projects. So, I think I really have a valid point.

> However, speaking as a part of Rust upstream: patches and commitments to ongoing maintenance welcome.

Yes, I'm aware of that and I have done that.

(Log in to post comments)

Debian, Rust, and librsvg

Posted Nov 14, 2018 16:18 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> so I guess many projects will build just fine with mrustc.

mrustc ignores lifetimes completely, assuming that they are correct. Granted, for released code, this is probably fine, but I certainly wouldn't want to apply a patch to a project without checking with rustc first.

Debian, Rust, and librsvg

Posted Nov 14, 2018 16:30 UTC (Wed) by glaubitz (subscriber, #96452) [Link]

> mrustc ignores lifetimes completely, assuming that they are correct. Granted, for released code, this is probably fine, but I certainly wouldn't want to apply a patch to a project without checking with rustc first.

Yes, I'm aware of that. But I wouldn't use mrustc for developing code either. Just for building release code.

Debian, Rust, and librsvg

Posted Nov 14, 2018 16:36 UTC (Wed) by josh (subscriber, #17465) [Link]

I wouldn't use it for that either, especially if code might vary across architectures. And if you follow dependencies down to the leaves of the dependency tree, you'll often find some code that does.

Also worth noting: mrustc currently has far less portability than Rust, and I don't see any signs of changing that.

Debian, Rust, and librsvg

Posted Nov 16, 2018 14:18 UTC (Fri) by glaubitz (subscriber, #96452) [Link]

> Also worth noting: mrustc currently has far less portability than Rust, and I don't see any signs of changing that.

Did you even try mrustc yourself or are you just guessing? It took me 5 minutes to make it build on m68k.

mrustc generates C code out of Rust code. How should it be **not** portable?

Debian, Rust, and librsvg

Posted Nov 16, 2018 21:13 UTC (Fri) by josh (subscriber, #17465) [Link]

Rust has its own conditional compilation mechanisms and target-specific mechanisms, as well as many other ways it needs to know about the details of the target platform. Going by way of C does not automatically make it perfectly portable. Quoting https://github.com/thepowersgang/mrustc/blob/master/READM... :

> - Supported Targets:
> - x86-64 linux
> - (incomplete) x86 windows
> - (incomplete) x86-64 windows

I based my comment on that. This isn't about the host platform of mrustc, it's about what the generated code targets, and using C as an intermediate language does not automatically make code portable.

Debian, Rust, and librsvg

Posted Nov 14, 2018 16:28 UTC (Wed) by josh (subscriber, #17465) [Link]

> I think it's definitely valuable to have a second, independent implementation of the language. This would also help with standardization.

Only if it manages to keep up. And even then, I'd expect it to generate ecosystem issues of its own due to implementation-specific quirks and bugs.

The primary implementation is Open Source; the value of having multiple independent implementations seems low compared to the cost. (The value of having multiple backends, on the other hand, seems quite reasonable for the cost.)

> Most upstream projects which are using Rust are not using the latest features of the language all the time, so I guess many projects will build just fine with mrustc.

mrustc doesn't implement borrow checking. It'd be a *bad* idea to use it for that purpose. It primarily exists so that it's possible to independently compile rustc (which is written in rust) and prove that there aren't any "trusting trust" attacks.

> Don't you think it's a bit of the burden for the Rust maintainers in Debian if they constantly have to fix these issues over and over again because Rust upstream doesn't provide an LTS variant of the language?

No. "LTS" or not, Rust will not stop having ongoing development. And while an "LTS variant" has been discussed, that will not affect this type of issue; LTS only really works for a specific subset of users who don't care about incorporating new upstream packages regularly, not the broader ecosystem. Architectures that want to be supported will still need to work with upstream to keep them working, and in particular to make sure they're actively tested.

But in any case, I think this comes back to the question raised elsewhere both in the debian-devel thread and in this thread: who is going to do the work? This isn't something where people interested in an architecture can offload work to others and expect it to get done.

It's not reasonable to look at an actively developed project like Rust and say "slow down, wait up". Rust *will* provide guidance, mentorship, and a welcoming environment where people can contribute. But it won't slow down or wait up.

> Well, after my post to debian-devel-announce, I received exactly this feedback from two very important upstream projects.

Namely?

> Yes, I'm aware of that and I have done that.

So you'd be interested and willing to help get the architectures you care about elevated to a higher support tier in Rust upstream, with the work and infrastructure that would entail?