Comment by CDSlice | Hacker News Reader

Comment by CDSlice | Hacker News Reader

I fundamentally disagree with the sentiment in this article. Rust does not have a culture of "move fast and break things", if anything it suffers from the opposite problem where language additions for things like const generics or async can take a long time to be stabilized because once they are they can't be changed. This is also why the standard library is so small, since it is subject to the same stability requirments as the language once something gets added to the standard library it can't be removed unless it is unsound.

Rust does have one current implementation, but there are efforts to get another one written in C added to GCC. There is also mrustc which is written in C++ and does not have a dependency on LLVM and can be very useful in bootstrapping rustc anywhere that has a C++ compiler.

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.

I'm not going to argue that a formally verified C program is going to be worse than a Rust program, let alone that writing a program in Rust will instantly solve every security problem you have, but considuring how many memory safety bugs regularly cause security issues I think that writing new programs in Rust and putting the effort in to carefully rewrite C/C++ programs into Rust is a net benifit to security and certainly better than starting a new project in C or C++.

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

This sentiment of "Just use what is most popular!" is pretty common, and it always makes me sad especially on a site like this. Not supporting operating systems outside of the absolute mainstream also sends the signal of a lack of interest in developing new things.

I'd argue that valuing portability and making it as easy as possible in general comes with more benefits than just "supporting those unpopular platforms I don't care about", typically the users of those platform will come forward and do work if only you welcome them. Not focusing on niche systems in particular I can understand, but what speaks against making the porting easier for the willing?

There has to be a cutoff somewhere. The crux of this debate is the subjectivity around what counts as "niche".

When it comes to workstations or web servers, what the GP said is true: everything outside of Windows/Mac/Linux x86/arch64 (and maybe BSD) is extremely niche. When it comes to the space of all systems where C runs, that probably isn't the case. When it comes to the space of all systems that Rust (and packages that depend on Rust) should support (for some definition of "should")? Who knows.

There are two questions:

a) What kinds of systems should be targeted (by Rust itself and also downstream packages/distros)? Hardware from the past ten years? Twenty years? Forty years? Embedded devices? Industrial control systems? Mainframes? Obsolete workstations from companies that have been dead for decades and are only used because one other piece of crucial software requires them?

b) What percentage of the devices in those spheres are actually unsupported right now? If you told me that purely in terms of number of devices, Windows/Mac/Linux x86/arch64 covers 90% of the devices in the world, I would believe you. I would also believe you if you told me those only covered 40% of the devices in the world. I genuinely don't know. And this question has to be asked in the context of the answers to (a). Our subjective impressions of "how wide of an impact this has" are at the heart of the argument; we don't have a common truth. I think a lot of the emotions being seen are by people for whom it feels like their entire world is excluded. That alone isn't a basis for project scoping, though it's worth listening to.

Traditionally C's mantra has been that it runs on anything with an instruction-set (maybe inconsistently, but there will be something available!). That's cool! But if that's the bar for a new systems language, we will never ever get a new systems language because C has half a century's head-start. We can debate whether a specific package or distro was premature to require Rust, which is highly dependent on their target market of users (and not really the responsibility of the Rust community itself!), but no matter what, Rust itself is going to have a cutoff, and that alone isn't a valid reason to dismiss it.

> The crux of this debate is the subjectivity around what counts as "niche".

Once you get down from the obvious large players people tend to consider what they do mainstream enough and what they don't do too niche.

>When it comes to workstations or web servers, what the GP said is true: everything outside of Windows/Mac/Linux x86/arch64 (and maybe BSD) is extremely niche

Say the same again about embedded devices and the Netflix network backend if you dare. Also, some compiling toolchains for consoles based on BSD os'es.

Embedded devices are MUCH more than the 90% of the world. Not eveything is a cumputer.

Add routers, switches, and mobile devices and now your "90%" goes out of the window.

If you read the whole thing, my main point was exactly the fact that that percentage is so relative/subjective/difficult to quantify.

> Not supporting operating systems outside of the absolute mainstream also sends the signal of a lack of interest in developing new things.

Tier 2 support is still support, and there are a lot of tier 2 targets. Seriously, look at the list:

https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

There's nothing wrong with saying, "Look, I'll do everything I can to help you, but you're using a PowerPC on a $5000 FPGA board that I don't have, so the things I'll be able to do for you may be somewhat limited." It's super common to see kernel developers responding to bug reports stating that they need more traces from people with the affected hardware configuration. How is this any different?

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

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

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.

Reply on news.ycombinator.com