4 ms·

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 oppos

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

ddevault 6y ago
>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.
- RcouF1uZ4gsC 6y ago
  > 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.
  - ddevault 6y ago
    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.
  - PuercoPop 6y ago
    > 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.
- CDSlice 6y ago
  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.html 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.
2pEXgD0fZ5cF 6y ago
> 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?
- brundolf 6y ago
  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.

ddevault 6y ago

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

RcouF1uZ4gsC 6y ago
> 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.
- ddevault 6y ago
  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.
- PuercoPop 6y ago
  > 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.
CDSlice 6y ago
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.html 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.

2pEXgD0fZ5cF 6y ago

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

brundolf 6y ago
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.