On 01/22/2018 05:06 PM, Alberto Planas Dominguez wrote:
Sorry but I think that you have a missunderstanding here (or is me the one that do not get your point)
Rust is really stable as a language. But the stability guarantee provided by Rust needs to be understanding as this:
* 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.
There is a process of deprecation, and there is a process of optional enablement of new features, and this section can require the removal of some lines in future versions of the compiler, when this change is enabled by default.
Deprecation is fine when you do it gradually. It's too fast when you do it between minor releases.
Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
I really do not get your point. Cargo is like make, is not (and will never be) a full feature package manager. Is true that there is an overlap: cargo can download from crates.io, but is not the way to install anything into the system. This is responsibility of the OS. Is only a helper to the developer, during the development process.
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.
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?
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.
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. C++ or Fortran are much more careful when making such changes in order to not break existing code bases. Simply because you cannot expect all your users to constantly update their codebase just because they are updating their toolchain. And you didn't even address the problem that Rust upstream effectively doesn't care about anything besides x86/x86_64. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org