"we're going to try bring Arti to a production-quality client implementation over the next year and a half"

"Eventually, once our Rust implementation of Tor is a good replacement for our C implementation, we will stop adding new features to the C implementation, and eventually drop support for it entirely."

is being rewritten in 😀

@bugaevc and people still struggle to see that Rust is going to replace C and C++, slowly.

@bugaevc Horrible news. Rust can still not be compiled with any compiler that can be trusted to produce sane bytecode. C on the other hand can be. Rust is basically a worthless commodity around trend languages as long as there is no proper GCC frontend. LLVM is trash and can not be trusted.

@Alexmitter sorry, what does bytecode have to do with it?

And what about rustc's new GCC backend?

@bugaevc Everything really, the language can have all the fancy save features if it is compiled into highly untrustable pseudo bytecode then executed by a low level virtual machine.

And sure, there is work for a GCC backed by a single company and a few people, the rust peoples idiotic refusal to have a damn language standard is not making their life easier either. Its still a amateur trend language and it shows.

@bugaevc What does that mean for their reproducible builds? Also surprised they trust unverifiable binaries from Mozilla.

@js rustc is fully capable of building reproducible binaries; rustc itself has been reproducible in Debian at some point, but has apparently since regressed.

What makes you think they trust unverified binaries from Mozilla?

@bugaevc Well since you can’t bootstrap rustc without binaries from Mozilla, you also can’t verify the binaries from Mozilla without using the binaries from Mozilla.

@js you mean binaries from the Rust Foundation, not Mozilla. And sure you can bootstrap rustc:

You can either bootstrap it from rustboot (the prehistoric Rust compiler in OCaml), or with mrustc, or, once the upcoming GCC Rust works good enough, with that.

(And yes, I have done that — bootstrapped rustc via mrustc — myself.)

@bugaevc Bootstrapping via the old OCaml compiler is something that is only possible in theory - I know people who tried and it failed. But it’s great to hear that mrustc can now bootstrap!

Personally I’m hoping for gccrs. That is the point where Rust becomes a viable option for me, but not before.

@js well, it's not exactly a new thing, it has been able to bootstrap rustc for years. This is the announcement:

Yeah, I'm closely watching gccrs too, and wishing them all the luck.

@bugaevc I think the problem with mrustc was that it only was able to bootstrap quite old versions of rustc. Basically it managed to bootstrap and then bitrot.

@js huh? it's being constantly updated to support newer versions of Rust and rustc. The original announcement was about building 1.19, since then it was updated to build 1.29 and 1.39. So, not that old, and no bitrotting in sight.

That being said, the current version of Rust is 1.53, so you'll need to build 15 releases or so of rustc after you build 1.39 with mrustc.

@bugaevc 15 releases is SIGNIFICANTLY behind. That’s more than 2 full days of compiling non-stop on a modern machine! That completely invalidates your claim “they keep it updated”. Obviously they don’t.

@js obviously they keep updating it (you can check commit history for yourself); but they always lag behind Rust releases. 1.39 support was only achieved a few months ago. If they continue at the same pace, they'll have 1.49 working in like a year, but by that time Rust 1.6x will be out, so they'll still be behind.

Yes, doing full bootstrap is slow. Good thing is you don't have to do it each time on each machine, e.g. the Tor project, or each distro shipping rustc, only has to do it once.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!