Comment by ddevault | Hacker News Reader

Comment by ddevault | Hacker News Reader

Parent Full thread

>I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.

This is towing the party line, and the party line basically amounts to "fuck you" to anyone else. I addressed this directly in the article. T2 platforms are a nightmare to bootstrap and maintain. "Putting the work in" is a huge amount of work, because Rust is an extremely complicated and huge machine. These arguments are mainly made by people who have never actually tried to bootstrap rust on a T2 or T3 platform. Take it from someone who has: it SUCKS. I lack the vocabulary to adequately describe the suckage, and I have a pretty colorful vocabulary.

Yes, you can get working POWER9 and RISC-V hardware, and even find it in use in the field. And they've had working C toolchains for several years.

Why would you need to bootstrap Rust on a T2 platform? You already have a rustc build for that platform, can't you just use it? It may be buggy yes, but if you have a built compiler you should already be a good deal of the way to having a working compiler since you can "just" run the tests and see which ones break. Descriptions of what actual problems you ran into would be greatly appreciated, especially since riscv64-musl isn't a target mentioned at all in https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and I do want to know what makes it so hard to get a platform from T2 to T1.

I also resent the insults that I am blindly "towing the party line", I truly don't believe that with the market share POWER9 and RISCV have it is worth putting in the effort of supporting them unless you are a "true beliver" in them, in which case you can put the work in yourself if you want to. If this is unreasonably hard (which it does appear to be since you weren't able to make any progress in a week) it would be much better to hear what actually made it so hard instead of whining that the Rust devs won't support your esoteric platform for you.

I like to build things from source, but I'd also like to hear more details about the problems encountered.

The whole tiers thing is first of all a chicken and egg problem. Which probably could be solved faster by keeping Drew invested. I also constantly have to fiddle with rust's lack of support for T2 (armv7-linux-musleabihf in the past and aarch64-linux-musl now, having given up on the former) and I agree that this aspect sucks and hinders adoption. And furthermore it defies one of rust's main goals, security: With something like ME/PSP having unrestricted access to whatever they want, why bother that much about memory safety?

Drew is an Alpine maintainer. Alpine, which you might know as probably the most-used server-side Linux distribution in the world right now, bootstraps everything in its repositories, just like every major Linux distribution on the planet.

> Alpine, which you might know as probably the most-used server-side Linux distribution in the world right now

[citation needed]

> I do want to know what makes it so hard to get a platform from T2 to T1

Basically tier-1 targets must have tests run on CI for every merged commit. If anybody have a way to do that for their interest platforms, that's a huge step in making it to tier-1 platform support.

> T2 platforms are a nightmare to bootstrap and maintain.

Yep. And devoting more resources to this, IMO, does not have the payoff of devoting more resources to making the language better or improving Rust on T1 platforms.

I think C, for example, was held back by support for esoteric platforms, such that the language doesn’t even say that a byte is 8 bits, or what the encoding for a string is. It gives great flexibility, but it has huge costs.

Maintaining T2 platforms doesn't need to be a lot of work unless you make it so. Rust made that choice by being extraordinarily complicated, which I don't feel compelled to forgive it for.

There are a lot of platforms which aren't as stupid as "bytes aren't 8 bits" and are still useful to support. Rust supports TWO architectures with anything other than broken promises.

> doesn’t even say that a byte is 8 bits

That is likely due to the fact the historically that wasnt the meaning of the word. There is a reason the RFC for IP uses octet to refer to 8 bit bytes. Another example of an old document that doesnt use byte to refer to 8 bit bytes is the Common Lisp standard.

So even though the current definition of byte is 8-bits the fact that the C standard uses the old definitiom is most likely because it is a document that can be traced back to an era were there was more diversity in the hardware architectures in common use.

Reply on news.ycombinator.com