I'm really looking forward to when rustup.rs is stable (atleast for Linux)! I'm trying to push Rust at work, and it's one of those polishy things that would help.
Unfortunately, last time I checked development (on issues blocking the initial stable release) seemed to have slowed as of late, but I should be helping out instead of whining - the Rust community is doing great work!
Summer is definitely a slow time for us, lots of folks taking well-deserved vacations and lots of effort being diverted into organizing our three Rust conferences taking place this year, which I might as well plug while I'm at it:
Does the general admission ticket cover both day 1 and day 2 for Rust Belt Rust? Sorry for hijacking. I have issue with getting response from organizers from other conferences in the past so thought I would just leave an ask here.
I've been using it on my Mac since the post about it on here a few months ago and I've had no issues at all, though I haven't tried to do anything strange/difficult with it.
God that's a horribly confusing way to report that bug. Why not something like?
#include <stdio.h>
int main (void)
{
signed char one = 1;
unsigned char coerced_to_positive_255 = -1;
printf ("%d\n", one > coerced_to_positive_255);
return 0;
}
In the last comment [1] on the bug, it's mentioned the release in which the fix was released. From its page [2] you can see all the details of it, including its diffs.
I looked at that, and eventually found a reference to the Launchpad bug in this 500KB patch[0]. It says:
+ * Fixes included in the 4.2.4 upstream release (compared to 4.2.3-3ubuntu7):
+ - Fix LP: #256797, wrong-code on ia32, taken from the gcc-4_2-branch.
Which makes it sound like the problem was in GCC, not the Ubuntu package. I was under the impression that the bug was caused by an Ubuntu-specific patch, from dikaiosune's comment. Am I missing something?
Edit: Ah, so the fix was added in 4.2.4-1ubuntu1, not 4.2.4-1ubuntu3. Which narrows the actual source changes to something inside this other 500KB patch[1]. From here I looked at the upstream changes using GitHub compare[2] (warning, big page). I ran a one liner in the JS console to expand all the "…" buttons next to the commit messages so I could search for relevant text, which lead me to this commit[3], which seems to be the actual code changes to fix that particular bug. That finally lead me to the bug in GCC's bug tracker[4].
I don't know if I have just been very lucky with the open source projects I've collaborated with, but this journey to find where a bug was actually fixed seems completely insane to me. Is all this info passed down from maintainer to maintainer just via folklore? Crazy.
Oh, I almost forgot about what I actually wanted to know. This looks like a GCC bug that wasn't caused by Ubuntu specific patches, so I don't know what dikaiosune wanted to say.
With MIR, yes, the idea is that compile time should improve. One of those tracking bugs is to make sure that it doesn't regress before turning it on by default.
With incremental compilation, you should see compiles after the first improve; you'll need to compile a lot less code for each change. Right now, the entire crate is recompiled, but afterwards, just the portion that changed will need to be.
My understanding of compilers is somewhat limited, but I'm curious how the compiler can detect "just the portion that changed", given that Rust does heavy inlining.
Indeed, inlining is an obstacle for such fine-grained incremental recompilation as Rust envisions. However, when compiling in debug mode (which is the default) Rust (or rather LLVM) does not do all that much inlining, and considering that people compile in debug mode much more often than they compile in release mode this should present a large time savings to the average developer use case.
(Note also that MIR should generate somewhat faster debug binaries than current trans (by virtue of doing "obvious" optimizations in the frontend, rather than asking LLVM to chew on it), so if there are people out there who currently make release builds during development because their debug builds are too doggone slow, then this should help alleviate that.)
AFAICT, the idea is to track and hash items like function signatures and bodies, map them to the object files produced by LLVM, and to recompile them when the hashes change.
Also is there an ETA on syntax extensions being stabilized ? This and incremental compilation are my personal milestones that Rust (core language/compiler) went over the initial growing pains (lack of tooling I can deal with)
For a project I have in mind I'm looking for a way to reflect on the code and generate both serialization and RPC API from code based on conventions/traits/annotations - I guess I could do it with syntex but that looks hacky and slow (two passes). In general I'm not in a rush to start that project and these two things seem like the last big missing peaces of the compiler/language - I'm waiting on those before I start pitching rust to my coworkers.
Looking at it - it seems like a serialization framework ala .NET ISerializable, while that's a part of what I need I also need a way to dump code metadata out to some file (like JSON) at compile time and then use that data to auto generate the client API to access the data (but that would be done outside of rust). And since I can constrain my models serialization part wouldn't benefit much from a framework - most of the complexity would be in extracting the metadata and validating model constraints. I'm not sure if Serde helps with those I can't tell from github ?
In a way, Serde itself is all about extracting the metadata of a type and handling validation issues. However this is metadata is currently not exposed to end users. It's something I've thought about doing, but I haven't had a driving use case to help come up with a proper API for it. I don't think it'd be that hard to implement once we actually have a clear idea on what we want.
The code Serde generates though typically optimizes down into nearly the same code as a hand written serializer and deserializer. On my laptop, serde_json [1] serializes a particular micro-benchmark [2] that serializes as fast as a hand rolled serializer (416MB/s vs 414MB/s). In comparison, rapidjson serializes the same structure in 432MB/s. I didn't write a hand written deserializer, but serde_json is comparable to rapidjson (193MB/s vs 182MB/s).
So it may be fast enough that you might be able to just implement whatever you want by just using Serde directly without having to generate parsers.
Cool, thanks. We have some ideas for a solution to these kinds of cases that might come a lot sooner than general syntax extensions, but it's still shaking out.
For me, quickcheck! It's possible to live with a quickcheck feature that only works on nightly but it would be nicer if it were integrated like cargo test; cargo quickcheck.
Congratulations on the release! `cdylib` targets should prove very helpful for embedding, and compilation from a recent stable version will make it much easier to package.
The bootstrap problem is exactly why rust isn't in the Fedora repos right now, so I am very excited about this. Also, dylib will likely end up being preferred for distribution packaging (especially Fedora which HEAVILY discourages static linking, though there's no longer a strict no-static linking policy).
It's too bad that Rust went to all this language design effort to allow inlining (including when passing a closure to a function, which is really impressive!) only to have distros undo it for some policy that ends up harming their users more than it helps.
Static linking has benefits, but from a distribution standpoint it makes handling security updates (which people expect to be done correctly and in a timely manner) a HUGE pain in the ass.
You want to go statically link your internal rust binary that you are pushing out to hundreds or thousands of nodes and you need the extra performance? Go for it, you can handle rebuilding it every time there is a security update (and last I checked dylib's allow both static and dynamic linking against them, so you have that option). But if you want to include your binary in a distribution package repository it really should be dynamically linked, tracking what dependencies everything has and forcing rebuilds and updates for EVERY SINGLE BINARY that uses them is wasteful and a pain to manage.
Computers are good at tracking dependencies. It seems silly particularly in this case because Rust is harder to use than a garbage-collected high-level language exactly because it is trying to squeeze out these last optimizations, and then we turn those optimizations off because it's... what, too hard to automate rebuilding some binaries? It's as if they mandated you write your apps in Python because they didn't want to spend time compiling C apps.
While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur.
To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself.
However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.o...
Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.
You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set.
Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life.
As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
This draft document[1] suggests that Fedora will use the "rebuild all packages" option for packaging Go programs, since it's unlikely to support dynamic linking in the traditional fashion any time soon.
Not much of a choice for Go, but Rust does give the option for dynamic linking so I suspect the Fedora project will take advantage of it. There is no tooling in Koji to support mass rebuilds when dependencies are updated like this, which is why in rawhide when you are about to make an soname bump you are supposed to notify anyone who depends on the package of the change so they can bump the release of their packages afterwards.
I can't say anything about the build tooling other releases use (I only have real experience with Koji and a limited look at OpenSUSE's OBS), but I don't think (m)any support "rebuild all that depends on this package" without manual intervention. It's really a crappy situation to be put in by language designers who value their use case over all else, and while, again, I think static linking can have a place it really doesn't belong in distribution repositories if it can be helped.
Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install multiple toolchains in parallel.
In the repos directly? No, probably not. rbenv and pyenv aren't in the repos either, I'm not aware of any specific policy against it but it introduces some hesitance to provide software in the repos that can be used to then install software that may conflict with software managed by the package manager itself. rubygems, setuptools/pip and cargo as examples only typically handle installation of libraries and are generally "well behaved" citizens that put files in specific locations and don't install or manage new versions of the underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your path and potentially cause conflicts that could end up with people filing bugs that are closed "not our problem, we support this one specific environment that's in the repos".
Someone is welcome to try, feel free to open a thread on the fedora-devel mailing list and see what anyone else thinks. But even if rustup doesn't make it into the official repos I don't see why someone couldn't put it up on COPR.
Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really nice to be able to point to one command in the documentation that would work whether installed directly by the developer or provided by a distro.
Debian specifically provides it's own alternatives system to handle symlinks in a global manner, but nothing for directory-specific ones. I'm not sure about Fedora. With `rustup` replacing `multirust`, it would be useful to point to a common command that in turn would call the distro-provided facility for global links.
Also, congratulations on 1.10! Looking forward to servo.apk in the coming weeks as well.
As an addendum, there's nothing preventing anyone from packaging multiple versions of Rust assuming it properly supports it (for example installing to /usr/bin as rustc1.10, then we can symlink /usr/bin/rustc to the most recent one) - and if Rust releases a 2.0 at some point it is likely that there will be multiple versions available for a release or two while programs are modified to be compatible with the newer release. However, as Rust is fairly commited to semver I don't see much use in this UNTIL there is a new major release.
> Rust is implemented in Rust, which means that to build a copy of Rust, you need a copy of Rust. This is commonly referred to as ‘bootstrapping’. Historically, we would do this by “snapshotting” a specific version of the compiler, and always bootstrapping from that
So, does that mean that Rust (has/will have) issues regarding binary blobs in pure free software Linux distributions?
https://en.wikipedia.org/wiki/Binary_blob: "In the context of free and open-source software, a binary blob is a closed-source binary-only piece of software without publicly available source code."
All versions of the Rust compiler are open-source and have publicly-available source code, so they aren't binary blobs.
In a certain sense, yes. But in reality, no. There's both rustc and cargo packages in Debian unstable, for example. In my understanding, distros are willing to accept a single initial blob. They use that to build the initial package, and then build their own packages from that forever after.
I know, I was just saying. By the same token, Go has the same problem (you need to use an old version of the compiler to build the current version). Though, I kinda wish that the problem was solved the same way that GCC solves it (you write a simple compiler in Assembly and then use it to bootstrap the full GCC toolchain which you then use to compile an optimised version of the GCC toolchain). Requiring an older binary of the compiler is an annoyance (and AFAICS would make porting harder).
gcc does the exact same thing and is packaged in most distros, so no.
"Binary blob" in the context of free software is generally a blob which does not have open code behind it. This is not the case with Rust or GCC, the bootstrapping binary can be obtained -- in theory from a long chain of sources, in practice by compiling the source from a previous bootstrapping binary.
What amazes me, is all this cool stuff but a Rust process still can't return an exit code [0] without using a workaround.
I actually use Rust in production, and have generally found it very good - compared to the well discussed difficulties with CPP. I will continue to do so, but I think that the edges really need covering off properly before it'll be treated as a serious competitor to CPP (and equally often, Go).
This is true! Perhaps my comment was a bit in haste, however there's a lot of caveats with "exits" rather than returns which complicate the matter, for example in Java System.exit can fail (and finizalizers may or may not be run).
On top of that you have to type System.exit all the time, which is quite annoying
Congratulations! Are there any plans to support bootstrap from source? Currently any install requires a binary Rust compiler.
I like the way how Nim handles the bootstrap. It's always easy, and it also eases ports to other platforms significantly since everthing is coded in C.
Wasn't the old bootstrap basically just pointing to specific commits to rust rather than tagged prior releases? I remember the servo repo doing something like that and maybe the Rust one as well (cloned it but have yet to build rust on my system from source!)
Well, Servo is a bit different, given that it's not a rust compiler, so there's no 'bootstrapping' component.
Until Servo stops using nightly features (which may not be ever, given that they are part of how we test new features!), they'll need to stick with a nightly build. We made an exception for the compiler when compiling itself, but won't make any more.
Unfortunately, last time I checked development (on issues blocking the initial stable release) seemed to have slowed as of late, but I should be helping out instead of whining - the Rust community is doing great work!