Announcing Rust 1.15

[Posted February 2, 2017 by ris]

The Rust team has released version 1.15 of the Rust programming language, which adds a custom derive feature. "These kinds of libraries are extremely powerful, but rely on custom derive for ergonomics. While these libraries worked on Rust stable previously, they were not as nice to use, so much so that we often heard from users “I only use nightly because of Serde and Diesel.” The use of custom derive is one of the most widely used nightly-only features. As such, RFC 1681 was opened in July of last year to support this use-case. The RFC was merged in August, underwent a lot of development and testing, and now reaches stable today!"

(Log in to post comments)

Posted Feb 3, 2017 13:17 UTC (Fri) by cesarb (subscriber, #6266) [Link]

On related news, since Firefox 54 compiling with Rust is no longer optional: https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

Announcing Rust 1.15

Posted Feb 4, 2017 7:01 UTC (Sat) by glaubitz (subscriber, #96452) [Link]

Which is why we should prevent Firefox 54 from entering Debian.

Announcing Rust 1.15

Posted Feb 4, 2017 12:12 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Why would Firefox 54 enter Debian in the first place? It's not going to be an ESR.

Announcing Rust 1.15

Posted Feb 4, 2017 12:25 UTC (Sat) by glaubitz (subscriber, #96452) [Link]

Debian has both the ESR and non-ESR versions of Firefox. The former lives in unstable only.

Debian

Posted Feb 3, 2017 15:14 UTC (Fri) by miquels (subscriber, #59247) [Link]

Will Rust 1.15 make it into the next debian release (debian 9 aka stretch) ?

Debian

Posted Feb 3, 2017 15:37 UTC (Fri) by glaubitz (subscriber, #96452) [Link]

No. Debian Stretch has already been frozen and it's not very likely that Rust is going to gain any traction within Debian until upstream has sorted out their portability issues.

Debian

Posted Feb 3, 2017 23:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

What portability issues? CPU architectures? Standard libraries?

Debian

Posted Feb 3, 2017 23:37 UTC (Fri) by josh (subscriber, #17465) [Link]

CPU architectures (other than x86_64, i686, and arm64).

Debian

Posted Feb 4, 2017 20:25 UTC (Sat) by flussence (subscriber, #85566) [Link]

Rust itself is even further limited by depending on LLVM - it has a much wider range of supported platforms than Rust, but that's still a subset of what current Firefox can run on. (someone out there apparently keeps it working on IA64...)

Debian

Posted Feb 4, 2017 15:20 UTC (Sat) by phg (subscriber, #96794) [Link]

> What portability issues? CPU architectures? Standard libraries?

Issues like this: https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

Appears to be resolved

Posted Feb 7, 2017 3:15 UTC (Tue) by liam (subscriber, #84133) [Link]

https://bugzilla.mozilla.org/show_bug.cgi?id=1284816#c38

Some clarifications about Rust platform support and CI.

The coverage improvements Rust has promised to this point to support Firefox on Linux are implemented: mips, ppc, and s90x builds of rustc [1][2]. If there is more needed or expected from the Rust team at this time, I am not aware, and would like to discuss it (ideally not on this bug).

[1]: https://github.com/rust-lang/rust/issues/36006
[2]: https://github.com/rust-lang/rust/issues/36015

Today we don't test Rust on non-x86 Linux targets, but there is a PR open to add an ARM target tested via qemu [3].

[3]: https://github.com/rust-lang/rust/pull/39400

There are no plans presently to increase coverage beyond that.

Appears to be resolved

Posted Feb 7, 2017 6:51 UTC (Tue) by glaubitz (subscriber, #96452) [Link]

> The coverage improvements Rust has promised to this point to support Firefox on Linux are implemented: mips, ppc, and s90x builds of rustc [1][2]. If there is more needed or expected from the Rust team at this time, I am not aware, and would like to discuss it (ideally not on this bug).

That's at least an improvement albeit not as good as Google's CI system.

> Today we don't test Rust on non-x86 Linux targets, but there is a PR open to add an ARM target tested via qemu [3].

I don't understand why you think testing on QEMU is a reasonable idea. It isn't. QEMU is not guaranteed to behave like real hardware, so it should not be relied on if you care about the results.

If you have working CI for the architectures mentioned, why not run the testsuite on these targets as well?

Appears to be resolved

Posted Feb 7, 2017 15:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Are there any good sufficiently large cloud providers of ARM-based instances?

Appears to be resolved

Posted Feb 7, 2017 17:41 UTC (Tue) by MattJD (subscriber, #91390) [Link]

Maybe https://www.runabove.com/armcloud.xml ?

Thanks for giving me the idea to implement that now :)

Appears to be resolved

Posted Feb 7, 2017 17:43 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

https://www.linaro.cloud/

ARM cloud

Posted Feb 8, 2017 11:41 UTC (Wed) by geuder (subscriber, #62854) [Link]

There is www.scaleway.com , they have 32 bit ARM. They are open with their source code (management client source, image building source, kernel configuration source are on github). But I find them less open with their communication, it's been a lot of silence recently.

So I can only speculate, and my speculation does not predict a bright future for their ARM support.

Appears to be resolved

Posted Feb 8, 2017 0:06 UTC (Wed) by liam (subscriber, #84133) [Link]

> > Today we don't test Rust on non-x86 Linux targets, but there is a PR open to add an ARM target tested via qemu [3].
> I don't understand why you think testing on QEMU is a reasonable idea. It isn't. QEMU is not guaranteed to behave like real hardware, so it should not be relied on if you care about the results.
> If you have working CI for the architectures mentioned, why not run the testsuite on these targets as well?

I'm not making this claim, but, if i were, I'd say "it's better than nothing"(TM). I'd certainly feel better about my code if it compiled on at least one "instance" of an arch that I'm interested in.
I, however, wouldn't release those as generic $arch binaries.
On the Mozilla side of things, i think they have extremely limited CI resources when it comes to non-x86/arm hardware, so, i think these are considered tier 3.

Appears to be resolved

Posted Feb 13, 2017 10:55 UTC (Mon) by glaubitz (subscriber, #96452) [Link]

> I'm not making this claim, but, if i were, I'd say "it's better than nothing"(TM).

"Better than nothing" is much worse than what Firefox had before Rust.

> I'd certainly feel better about my code if it compiled on at least one "instance" of an arch that I'm interested in.

Well, ARM32 is one of the most popular targets that Linux runs on. So, I would make sure it's better than just "Better than nothing".

> On the Mozilla side of things, i think they have extremely limited CI resources when it comes to non-x86/arm hardware, so, i think these are considered tier 3.

If they don't have the resources, maybe they should reconsider making their own systems programming language.

The Linux kernel supports close to 30 architectures. If you want to be able to seriously compete with C/C++ (which they do), you should at least be able to support half of that. Golang supports far more targets than Rust and they don't even claim to be language that should be used to replace C/C++.

Debian

Posted Feb 14, 2017 17:59 UTC (Tue) by mmeehan (subscriber, #72524) [Link]

Why is lack of some degree of portability a barrier to Debian hosting? Won't the packages simply be unavailable on the unsupported architectures, and available for supported architectures?

What is the minimum set of supported architectures required to have your package distributed as part of Debian?

Debian

Posted Feb 15, 2017 12:34 UTC (Wed) by Jonno (subscriber, #49613) [Link]

> What is the minimum set of supported architectures required to have your package distributed as part of Debian?
Any one out of i386, amd64, armel, armhf, arm64, mips, mipsel, mips64el, ppc64el, and s390x. And obviously a Debian developer who is both interested in the package and has a machine on which it works...

Now the package will receive a lot more love if it works on most architectures, but that is not strictly speaking a *requirement*.

Debian

Posted Feb 3, 2017 17:09 UTC (Fri) by rillian (subscriber, #11344) [Link]

There was some discussion as to whether Debian could accept the 1.15 release candidate in time to migrate during the soft freeze, and then make an exception for the update to the release, but this was decided against.

There's also a proposal to package the `rustup` tool, which installs and maintains upstream binaries, but it looks like that didn't happen either.

As I understand Debian's stability policy, I think Rust will be another case like node or active python packages, where one has use a non-debian source software development on top of Debian stable.

Debian, Architectures

Posted Feb 6, 2017 9:05 UTC (Mon) by debacle (subscriber, #7114) [Link]

> I think Rust will be another case like node or active python packages, where one has use a non-debian source software development on top of Debian stable.

This depends very much on use case and preferences. I'm using Python heavily, but only libraries, that are in Debian. The situation with Node.js continues to be difficult, but in the last months, literally hundreds of node packages, sometimes only some bytes of source code, have been packaged for Debian. I expect the situation to be better for Rust than for Node.js, but maybe not as good as in the Python or Perl cases.

The main problem for Rust is it's limitation to few architectures. I would love to use Rust in my company for embedded software, but we use armel and armhf, both not supported by Rust. That is why I not even start to look deeper into Rust - with this restriction it would be a waste of time.

Debian, Architectures

Posted Feb 6, 2017 11:01 UTC (Mon) by peter-b (subscriber, #66996) [Link]

Just to be clear, when you say "armhf" and "armel", I assume you're referring to ARM < v7, right?

As far as I'm aware there's already a growing number of people using Rust to compile armv7hf applications without any problems.

Debian, Architectures

Posted Feb 6, 2017 13:25 UTC (Mon) by pabs (subscriber, #43278) [Link]

Debian armhf is ARMv7 like all the other armhf distro ports out there. Debian armel is ARMv4t.

https://wiki.debian.org/ArmPorts