On Mon, 2018-01-22 at 18:08 +0100, John Paul Adrian Glaubitz wrote:
On 01/22/2018 05:06 PM, Alberto Planas Dominguez wrote:
* I create a source S, that compile in Rust R and behaves like B
Rust guarantee that S, when compiled in R+1, R+2 .. R+n will compile, and the result will behave like B.
This is not the experience I made. I had sources that built with R-1 but not with R or R+1.
In that case a bug report needs to be submited. After 1.0, this is not supposed the happend. Is this happening in a public project? (sorry if the name of this project was announced before, I joined late) As a mater of fact there are some changes that were not backward compatible, but those were bugs that affected the soundness of the compiler, and the usage was not very common. In any case I am not aware of any project that was hit by those changes.
Firefox makes extensive use of cargo's feature to download packages from crate.io. I don't know why you think it's not a package manager.
For example, you cannot uninstall packages with cargo. Also was never recommended to install anything in the system. Is more similar to pip, gem, maven, go get, they can be used to fetch code that is needed during the development phase. But also is like `make`, because orchestrate the compilation.
Cargo is a living code, that is attached to the Rust version. There is a relation between both, so generaly an update of one require the update of the other. What is wrong with that?
I didn't say anything about that, did I?
Right. No, you didn't. My intention was extrapolate this example with the observation that Rust N needs Rust N-1 to compile but do not work for N-2. I didn't make my point clear, so lets forget about cargo as an example.
What keeps project X from using certain features of Rust? I have seen projects which would only build with Rust Nightly.
That is a decision of the developer. I can agree that some code that depends on Nightly are not good candidates to be package in the OS (like Rocket). But this do not make any 'wrong thing' in the Rust side. Is the developer who decide that the unestable feature that is provided with nightly is OK for the project. Eventually this feature will live in stable (or not), and in any case is responsibility of the developer to change the code to adjust with the new shape of this feature. But once is there, this program (in this exact version) will compile in any future Rust.
You can always say it's the developer's fault. However, that doesn't really help you in this case when you're a distribution maintainer, you're still in the situation that you cannot upgrade package X without updating the compiler or breaking package Y.
I understand, but your argument is not fair. If a developer use unstable features for version X, this code will compile very narrow window of compilers, and there is not guarantee that this feature that live in nightly will reach beta or stable. This make, by definition, this software unsuitable for packaging. But if a package use a version of Rust that is stable, this package will compile when you update in OBS the version of Rust.
You have the same problem with C++, but in a different speed. I can use GNU options, or C++17 in my new version of the project, that of course will not copile in gcc 4.6.
Different speed is a huge understatement, a seriously huge understatement.
Well C++03, C++11, C++14, C++17. You are right, but is not fair to compare a language that is 35 y.o (from 1983) with one that is from 2015.
C++ or Fortran are much more careful when making such changes in order to not break existing code bases.
And so is Rust. Changes that can affect the guarantee of back- compatibility are evaluated against crates.io. This procude data of the impact of the change.
Simply because you cannot expect all your users to constantly update their codebase just because they are updating their toolchain.
I can see that is a problem that if I want the last version of exa or ripgrep, and this version use features included in 1.24, I will need to update the compiler. But is not expected that this update will break any codebase that use Rust stable. This is a side effect of a young ecosystem, that will fade out eventually. Also the epoch RFC will help here. But this doesn't mean that Rust is constantly breaking your code.
And you didn't even address the problem that Rust upstream effectively doesn't care about anything besides x86/x86_64.
Sure. Clearly FF is not running on ARM on Android. I think that you have another missunderstanding on Tier 2 concept here [1] [1] https://forge.rust-lang.org/platform-support.html -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org