Mailinglist Archive: opensuse-factory (745 mails)

< Previous Next >
Re: [opensuse-factory] Rust
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread