It would be nice if Debian ran tests for platforms in the intersection of their “officially supported” sets (basically x86 and x86_64 Linux), but I don’t know how flexible Debian packages can be in that regard.
Debian still runs all the tests, they just don’t fail the build if tests fail any more. Another change is that Debian used to diligently report all test failures upstream, but they no longer do, because upstream doesn’t care. They now only report failures only if they have fixes as well.
I can see why in a project as young as Rust maintaining different distributions’ forked build and test scripts for the compiler could be prioritized lower than e.g. language-level improvements.
Yes, Rust CI runs tests on x86_64. Hence lots of breakages on other Debian architectures.
I agree with you on the priority, but I am of the opinion that you can’t have it both ways. Either Rust should address test failures on other architectures, or Rust should stop claiming C level portability. Rust portability is “almost” there, but not there yet because other architectures are not maintained well.
This is one of those things where it doesn’t matter what the “official” stance but what the popular interpretation of that stance is. Certainly a number of people are writing Rust replacements for old C bastions, like grep or the coreutils. This along with the RIIR meme spreads the idea that Rust is a viable replacement for C in all situations, including portability.
If the RESF wants to be clearer about how Rust isn’t ready to replace C yet, they need to be clearer that it’s not ready instead of being silent on the point about portability claims and saying they never said that.
This is one of those things where it doesn’t matter what the “official” stance but what the popular interpretation of that stance is. Certainly a number of people are writing Rust replacements for old C bastions, like grep or the coreutils. This along with the RIIR meme spreads the idea that Rust is a viable replacement for C in all situations, including portability.
If the RESF wants to be clearer about how Rust isn’t ready to replace C yet, they need to be clearer that it’s not ready instead of being silent on the point about portability claims and saying they never said that.
I realize you’re probably just going to go bitch about me on IRC again, but your comment smells like a load of bullshit to me. Rust’s supported platform list looks like a pretty good indicator to me of what the platform support looks like. In fact, it looks like the exact opposite of “silence.”
saying they never said that.
I actually didn’t say that. I asked where we claimed C level portability. If we were doing such a thing, I’d want to know about it so we can correct it. Which is exactly the thing you’re blabbering on about. But no. Instead, I get RESF thrown in my face.
We do not demand that Rust run on “every possible platform”. It must eventually work without unnecessary compromises on widely-used hardware and software platforms.
So I guess the current situation with failing tests is entirely intentional but not well-known. Well, it should be better known.
I agree that Rust needs a better multi-architecture story - as someone who does embedded development, I’ll play with Rust but I’d be very wary of using it “for real” - but lack of serious support for non-x86 [EDIT: non-Windows/-Linux/-Mac] is pretty well-documented.
[EDITed in response to sanxiyn’s clarification, thanks!]
Rust is still rough around the edge. Another example is that Rust currently lacks any kind of support for symbol visibility. “Why is the C++ visibility support so useful?” from https://gcc.gnu.org/wiki/Visibility applies to Rust as well.
A bunch of Debian’s officially supported architectures appear on Rust’s supported platform list under the “Tier 2” heading, i.e. the upstream project doesn’t run tests on these platforms so it doesn’t make sense for Debian to run those tests either.
It would be nice if Debian ran tests for platforms in the intersection of their “officially supported” sets (basically x86 and x86_64 Linux), but I don’t know how flexible Debian packages can be in that regard.
Debian still runs all the tests, they just don’t fail the build if tests fail any more. Another change is that Debian used to diligently report all test failures upstream, but they no longer do, because upstream doesn’t care. They now only report failures only if they have fixes as well.
Rust itself runs tests in CI on every pull request that are required to pass. For example, https://travis-ci.org/rust-lang/rust/builds/410084149
I can see why in a project as young as Rust maintaining different distributions’ forked build and test scripts for the compiler could be prioritized lower than e.g. language-level improvements.
Yes, Rust CI runs tests on x86_64. Hence lots of breakages on other Debian architectures.
I agree with you on the priority, but I am of the opinion that you can’t have it both ways. Either Rust should address test failures on other architectures, or Rust should stop claiming C level portability. Rust portability is “almost” there, but not there yet because other architectures are not maintained well.
Can you please point out where Rust “claims C level portability”?
This is one of those things where it doesn’t matter what the “official” stance but what the popular interpretation of that stance is. Certainly a number of people are writing Rust replacements for old C bastions, like grep or the coreutils. This along with the RIIR meme spreads the idea that Rust is a viable replacement for C in all situations, including portability.
If the RESF wants to be clearer about how Rust isn’t ready to replace C yet, they need to be clearer that it’s not ready instead of being silent on the point about portability claims and saying they never said that.
I realize you’re probably just going to go bitch about me on IRC again, but your comment smells like a load of bullshit to me. Rust’s supported platform list looks like a pretty good indicator to me of what the platform support looks like. In fact, it looks like the exact opposite of “silence.”
I actually didn’t say that. I asked where we claimed C level portability. If we were doing such a thing, I’d want to know about it so we can correct it. Which is exactly the thing you’re blabbering on about. But no. Instead, I get RESF thrown in my face.
Lose, lose. Thanks for playing.
Aha, I also see this:
So I guess the current situation with failing tests is entirely intentional but not well-known. Well, it should be better known.
I agree that Rust needs a better multi-architecture story - as someone who does embedded development, I’ll play with Rust but I’d be very wary of using it “for real” - but lack of serious support for non-x86 [EDIT: non-Windows/-Linux/-Mac] is pretty well-documented.
[EDITed in response to sanxiyn’s clarification, thanks!]
Rust Platform Support page is pretty clear. x86 is Tier-1, anything else is not.
Rust is still rough around the edge. Another example is that Rust currently lacks any kind of support for symbol visibility. “Why is the C++ visibility support so useful?” from https://gcc.gnu.org/wiki/Visibility applies to Rust as well.