Mailinglist Archive: opensuse-factory (745 mails)

< Previous Next >
Re: [opensuse-factory] Rust (was: Tumbleweed - Review of the week 2018/03)
On Mon, 2018-01-22 at 16:36 +0100, John Paul Adrian Glaubitz wrote:
On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
I'm not sure we're understanding each other here -- my point was
the *only* Rust project which has this policy for compiling new
is the Rust compiler. No other Rust project requires this. That's
what I
meant by "exception, not the rule". So I agree with what you wrote,
it doesn't have much to do with what I was trying to say, which is
the following quote ...

So, you say it's guaranteed that only the Rust compiler will only
ever use
particular code that will be deprecated in release N+1 or only
in release N-1?

I did build test it myself. I tried building Rust 1.22 with Rust 1.20
which failed with actual compiler errors, not just a warning that I
to use the proper version. And I think it's absolutely not unlikely
Rust project X will run into such a problem as well. What keeps Rust
project X from using certain language features that were only
added or removed?

The problem with Rust is simply the lack of stabilization. It's
insane that they think it's ok to break compatibility in minor
and it blows my mind that so many people find that acceptable.

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.

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.

What you are referring is a different issue:

* I create a source S, that compile in Rust R and behaves like B, but I
require that my new version S+1 will also compile for the old version
of R.

That is simply ... uhm ... like no. No one can guarantee this. A new
version of your code, if use specific features enabled in one version
of Rust, will not compile in a old version of Rust that do not provide
this feature at all.

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

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

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?

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

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread