brson

> As with Swift, I haven’t been able to find conclusive evidence nor credit given to suggest that there was any influence from Scala on Rust …

Scala was a significant influence on Rust. Niko did his dissertation in Scala, and several other team members were fans. Let it be known!

Congrats on another great release, Nim team.

Oh great. Keep us updated.

Yes, thank you for the suggestion. I agree that's a good candidate and will note it on thread.

We no longer use buildbot for our CI.

We have a "meta CI" system called bors/homu that integrates with other CI, currently Travis and AppVeyor. bors works with any service that can post a result to a GitHub PR.

So the plan for supporting further architectures is to create a small custom runner that builds, tests and posts to the PR. That code does not exist yet, but if it appeared there are likely several upcoming architectures that could make use of it.

With that tool, we could allow contributors to set up their own integration bots and hook into our CI.

Honestly, it's extremely taxing to maintain this pace without everything falling apart. The size of the team employed by Mozilla is quite modest. Firefox, which has a similar release schedule, has an entire team dedicated to just getting the releases out (though Firefox is yet the significantly larger product). We have no entire people, but employ some very rigorous testing.

I think it is unlikely we will make FreeBSD tier 1 any time soon. The project is stretched beyond its limits with its platform support commitments, and FreeBSD is historically difficult for us to support.

The next tier 1 is going to be ARM, probably for both Android and Linux, and then I personally don't see any others on the horizon. I actually see our tiers being redefined soon to be more graduated, and not have so many tier 2 commitments (we're happy to build artifacts for obscure platforms, less happy to be on the hook for guaranteeing obscure platforms continue to build - not saying FreeBSD specifically is 'obscure').

That said, the differences between tier 1 and tier 2 are not so great. If a platform has testing on CI then it is pretty close to tier 1, even if it's technically tier 2. The problem here is that testing the FreeBSD targets requires running FreeBSD in some way and that has been hard for our CI to do. Anything that can be crossed from Linux is easy, everything else is a painful special case. So with FreeBSD we do the the cross-building, but not the cross-testing. So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests.

There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.

rustbuild can optionally build from vendored (in-tree) source of all cargo dependencies, where it does not touch the network, and that's how we expect packagers to build Rust. I believe Debian has their own bootstrap lineage where they bootstrap from Debian's own prior builds, and rustbuild supports this mode; but they also have a fallback for rebootstrapping, with the corresponding policy exceptions.

If you are interested, here's a draft Debian Rust packaging policy: https://internals.rust-lang.org/t/debian-rust-packaging-poli.... It is not about packaging Rust itself though but the challenges of packaging software written in Rust.

Yes, the Makefiles were an abomination. Nobody could understand them. The reason the makefiles are so heavily macroized like they are is because of cross-compile bootstrapping, where the build rules are the same in many configurations, with slight differences. Effectively, large swaths of the makefiles were parameterized over 4 different values.

rustbuild is actually pure-Rust. The entire Rust build is written in Rust (Rust is bootstrapped all the way down!). The python scripts are a slim wrapper that downloads the bootstrap compiler to get into the Rust world.

Graydon has been on Swift for a while, and there are a few other prominent Rust contributors there as well. I hope they are enjoying themselves and make good things.

If anybody is looking for a Rust job, they in fact do exist, and are growing. This Week in Rust lists 5 this week [1], and 5 is more than zero!

[1]: https://this-week-in-rust.org/blog/2017/01/17/this-week-in-r...

And stack probes are one corner case of stack overflow. Rust protects against stack overflow in most cases, on all platforms, in every case on Windows, and is intended and designed to protect against all stack overflow, but it has a bug due to missing features in LLVM that nobody has taken the time to fix.

There's little evidence for a "dark cloud" on the horizon because of Rust nightlies, besides people complaining of dark clouds. I'd suggest providing evidence of problems with nightlies and filing bugs about things that need to be stabilized.

Dependence on the nightly channel has been one of the biggest risks in Rust. The problem is not solved yet, but it will be. The Rust stable / nightly split is disimilar to the Python 2 / 3 transition in important ways. The notion that 'nightly Rust is the only Rust' is premature, and Rustaceans should be cautious about encouraging that notion.

It's undeniable that there is a significant amount of Rust software still reliant on unstable features, but I have not seen any numbers that would put it in perspective. Having consistent measurements of nightly vs stable adoption would help a lot, inform any conversation, and efforts to move off nightly.

So I think it's premature to say that 'nightly Rust is the only Rust', The article suggests that people are using nightly as the de-facto recommended toolchain, without evidence (though I'm sure somebody has recommended nightly be default). I'd encourage people not to recommend nightly and for Rust library developers to aim for their crates to be compatible with stable. I personally don't have the same sense as the author that Rust application or library developers are using nightly more than they have in the past. Rather I know that developers of key nightly-only libraries are actively involved in ecosystem migration off of nightly.

One of the biggest difference between the 2 / 3 split is that stable is generally compatible with nightly, and is intended to catch up with nightly, whereas Python 2 is not such a strict subset of Python 3 and its development is done. That is, nightly is intended to be a staging ground for stable; Python 3 does not have that same relationship to Python 2.

(Edit: I stated this awkwardly. In this comparison nightly=Python 2, stable=Python 3. The point stands that the relationships between the two branches are different between the two languages. Nightly development feeds into Stable, Python 2 doesn't feed into Python 3, it is not under active development.)

Because of this relationship there's still reason to have confidence this dependency on nightly will shrink over time. But not disappear. We would always expect some people to depend on nightly. That is its intended purpose - as a breeding ground for future features.

Some of the biggest features keeping people off stable Rust are coming, and their biggest users are actively migrating. In the near future there will be fewer reasons to use nightly, not more. And beyond that the reasons to stick to nightly will evolve as Rust evolves. The next demographic of users who will be stuck on nightly will be embedded developers, and that contingent will increase over time. But even as that group increases, the group that is freed up to use stable Rust will grow also. And slowly the stable ecosystem will coalesce for all classes of users and all types of code.

Though I don't believe it's happening to the extent the author does, I'd rather not see Rustaceans who care about Rust's future to adopt a nighly-first mindset. More things will get more stable, faster, by working together. But regardless of people's dispositions to the stable / nightly split, more of the ecosystem is going to work on stable over time - that is how the Rust feature pipeline works - and eventually stable Rust will be the only Rust.

I still expect it to all work out ok.

As I member of the Rust team, I personally would like Rust to be a suitable replacement for fortran, and I suspect most Rust core contributors would feel the same. Rust already has competitive performance so it feels like a small step to be able to fit into fortran's niche. I don't know the particular multidimensional array discussion you experienced, but evolving a language takes slow time, and meanwhile people experiment with what is possible out-of-tree, like with the ndarray library, which seems to be well respected.

Right now there is a focus on SIMD in Rust, which is crucial for this domain, so there is progress being made.

We want rust to be successful and that means being adopted and used.

It has nothing to do with management and justifying investing in rust. We are fortunate that Mozilla invests in rust to use rust and is currently very happy doing so.

They are not.

Yes, metapackages are intended to be a general cargo feature, available to all. I suspect the design has not progressed far enough to definitively answer your question about conflict resolution, but I'd imagine you have to override that dep explicitly to fix it.

Congratulations, servo team. This is an exciting milestone. Getting all these eyes on servo is going to accelerate development even more.

Eventually, yes.

Try `rustup target add aarch64-apple-ios` and see how far you get. It's a tier 2 platform so it usually has builds available. But the iOS targets are some of the least tested for Rust. I have no idea if they work!

The process for adding tier 2 platforms isn't well defined but is closely related to ease of automation. If it can be done in a Docker container then it is simple to build std and ship it. Right now we're enthusiastic about this level of support - we can provide builds of std for lots of things. As long as somebody cares just enough to keep std building, which is pretty easy to do.

Whether those builds work at all is a different matter! We don't run tests on most tier 2 platforms. It's a big commitment to do so, even more to keep the tree green.

Personally, I really want to say that in time Rust will have perfect test and build automation on all platforms that matter even a little bit. All platforms are on a slow treadmill to perfection. They all come with maintenance burden, but the more successful the project is the more maintenance (and perfection) we can afford. Hm, I hope that's how it works...

This question comes up a lot, and we've debated it a fair bit.

There are a few key arguments for keeping them separate from my perspective:

First, they have distinct audiences. Cargo is a tool for building Rust programs no matter how you obtained the compiler. rustup is a tool fundamentally for installing the official Rust binaries. So if Cargo contained rustup, that would be a large chunk of features that have an very unclear role when Cargo is distributed by Linux distributions, and would probably need to simply be compiled out.

That last point about compiling out rustup also points to the fact that Cargo's and rustup's features are completely orthogonal. There's no technical reason to combine them.

Of course, the practical reason to combine them is that one tool is conceptually simpler than two. Even I have found myself accidentally typing `cargo update nightly`, `rustup build`, etc.

Finally, releases of Cargo today are paired with releases of rustc. Distributing the Rust installer with Cargo would necessarily change that relationship. That is, there would be one global Cargo that is used with every revision of rustc. This isn't necessarily a bad way to arrange the tools, but it is a big change from today that would require significant effort to move to.

I do recommend using rustup to all Rust developers now, despite still having reservations about its done-ness, and not being ready to commit to putting it on the main website (I guess that's something of a contradiction).

This blog post marks the beginning of the phase where we will seriously try not to break things on upgrade - I consider it 'in production' now.

Even now I think it provides the best installation experience and I have much higher confidence in its reliability than the older multirust shell script.

That said, if you are on Windows you might want to be more cautious. Just this week I broke rustup's networking on Windows, and there are periodic reports of intermittent self update failures (though these don't cause data corruption).

https://github.com/rust-lang-nursery/rustup.rs is the repo.

The setup tool and the tool itself are the same binary. The rustup install is basically copying rustup-init.exe to `~/.cargo/bin/rustup.exe`.

Both Rust and emscripten do produce notably large output. On the Rust side it's true that the emscripten port won't use jemalloc, but instead the emscripten malloc (which presumably is better tuned for its environment). Also the wasm format's main design goal is to reduce binary size.

I've been told that the LLVM branch I linked to is 'the most wrong branch you possibly could have linked to'.

This is the right one: https://github.com/rust-lang/llvm/tree/rust-llvm-2016-03-13

Patches are mostly backported from upstream or optimizations.

Today Rust only has a [few patches to LLVM](https://github.com/rust-lang/llvm/tree/rust). One is for Android stack overflow detection using a mechanism that upstream isn't fond of (split stacks), the other an optimization not required for correctness.

The Android patch can be eliminated someday with stack probes (though it's not clear upstream wants those either).

Emscripten support though - at least in the short term - is going to bring in the [emscripten LLVM 'fastcomp' backend](https://github.com/kripken/emscripten-fastcomp) that translates LLVM IR to JS. This patch has no hope of being upstreamed and will impose significant maintenance burden on both Rust and Emscripten as long as its in tree. This solution should be short-lived though as we will transition to either the upstream LLVM->wasm backend or a new Rust MIR->wasm backend.

So I think the answer to your question is 'no'.

This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share.

The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.

Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on.

[1]: https://internals.rust-lang.org/t/need-help-with-emscripten-...