Announcing Rust 1.3 | Hacker News Reader

Announcing Rust 1.3

blog.rust-lang.org

205 pointssteveklabnik38 comments

Lots of great little things in this release (my favorite is probably https://github.com/rust-lang/rust/pull/26926, hooray for removing external dependencies (come oooooon LLD...)), but what I'm really excited about is the upcoming 1.4 release.

For the past few cycles we've been speaking to production users of Rust and determining what features were keeping them on nightly builds rather than stable releases, and have been gradually stabilizing those APIs and features. Rust 1.4 (due October 29) will be the first release with the aforementioned stable items. So if your company is currently using Rust in production and you've been tracking the nightly builds, instead of updating to 1.5-nightly today I heartily encourage you to upgrade to 1.4-beta instead and help us test the next release. If you have any trouble, let us know at rust-community@googlegroups.com (or at the email address in my HN profile) and we'll look into getting what you need stabilized in time for Rust 1.5. :)

Is there a list of features in 1.4?

No nicely-compiled list that I know of. Though now that 1.4 is in beta we won't be adding any features to it (unless there's something unspeakably urgent, that is), so conceivably we could come up with a changelog right this moment. For the moment you may be best served by perusing the installments of This Week In Rust (http://this-week-in-rust.org/) for the past six weeks.

Not yet, but a big stabilization PR was: https://github.com/rust-lang/rust/pull/28339

How is rust on Windows these days? The last time I looked at it (pre-1.0) I believe it still needed external libraries from MinGW or something? I could be totally wrong, I don't keep tabs on the progress other than when it is posted about here.

From the more detailed release notes:

"Porting Rust on Windows from the GNU toolchain to MSVC continues (https://github.com/rust-lang/rust/pull/26569, https://github.com/rust-lang/rust/pull/26741, https://github.com/rust-lang/rust/pull/26741, https://github.com/rust-lang/rust/pull/27210). It is still not recommended for use in 1.3, though should be fully-functional in the 64-bit 1.4 beta (https://static.rust-lang.org/dist/rust-beta-x86_64-pc-window...)."

https://github.com/rust-lang/rust/blob/master/RELEASES.md#mi...

Thanks. I saw the mention of Windows XP and was a little confused about that, seems a little strange to spend resources on an old and unsupported platform imho.

Still 12% market share!

http://netmarketshare.com/operating-system-market-share.aspx...

I've written a few IT Scripts in Rust to do simple things like modify DNS files, set file permissions, back up dir's.

The only change between the Windows/Linux was modifying the paths from " / " to " \\ ". I could just git clone, and pass all tests out of the box.

This is also my experience moving a code base from Linux x86_64 to ARMv7.

None of these we're dipping heavily into unsafe code, so ymmv.

You shouldn't have to change the path separators; Windows supports '/' as well, if you're working with paths. If there's something else you're doing, you might benefit from something like http://doc.rust-lang.org/std/path/constant.MAIN_SEPARATOR.ht...

I'm been pleasantly surprised at how good rust is for build-scripts and the like.

I've started using the build.rs capabilities of Cargo recently and between the solid implementation of Process(including pipes) and general robust-ness it's been refreshing.

There's been a lot of work on integrating with Windows's native MSVC toolchain. In 1.4 (which is in beta today) this is fully supported for 64-bit. You can get it here:

https://static.rust-lang.org/dist/rust-beta-x86_64-pc-window...

Note, this requires Visual Studio 2013 or 2015.

Pretty solid, I've been using it for quite a few weeks with no issues.

Welcome improvements! I guess I'll be able to compile all my code on stable 1.4 judging by https://github.com/rust-lang/rust/pull/28339.

I almost thought the Windows XP support was meant as a joke. Seriously, why invest any effort for that? Isn't it in like its second year of not being supported by Microsoft anymore? Is a large portion of your contributors from China?

Quite a large number of users on XP, yes. As has been said many times, if we judge by usage, Firefox would drop desktop Linux support before dropping Windows XP support. And we all want Rust code to make Firefox better, don't we?

(Not that this decision was just because of Firefox, mind you. Users ask for it.)

    >  Is a large portion of your contributors from China?

I don't know about a 'large portion' exactly, but yes, there is a lot of attention, interest, usage, and contributors from China.

Interestingly, a lot of emerging languages are seeing huge interest from China, though we often don't realize it over in the West. Go is another example of a language with an enormous Chinese backing.

>> Go is another example of a language with an enormous Chinese backing.

Is that simply because of the larger population, or is it actually more popular among developers in percentages? If the later, any idea why?

All of my sources are secondary, so I can't answer for certain. That said, we ought to expect any emerging market with a large population and a burgeoning tech industry to be represented to some degree (India being another example).

If Rust doesn't work on Windows XP then generally Firefox can't use Rust, because Windows XP support is a requirement for Firefox.

Its frequently requested by users. Like or not XP is still with us, and likely will be for a while -_-'

The argument frequently used is if supported platforms were decided by userbase size there would be no reason to support FreeBSD or Linux.

Linux on servers has been in the mainstream for a while now.

I hope Firefox isn't running on most of those.

The impression I got is that Rust isn't marketed as "a great language to build a new rendering engine for Firefox". It positions itself as "a great system language". If your system language doesn't run on machines hosting performance-critical software, that's a problem.

There are more Firefox users on Win XP than Linux. It would make more sense for FF to drop Linux support before WinXP.

Installations != # of Users

Although, servers have billions of users. ~Everyone on the Internet is a user of Linux servers.

Windows XP is still used widely in the wild. It's still not considered a first-class platform (we don't gate breaking changes on it), various bits of the stdlib are unavailable, and the compiler itself will never function on XP, but getting rudimentary support for cross-compiling code to XP is not an undue burden on the development team.

Windows XP marketshare is three times bigger than OS X and twelve times bigger than GNU/Linux. Why the Rusts development team would not put effort where it can get a good share of end-users?

Sort-of not supported, it can still get unofficial-official security updates until 2019.

Nice to see them plugging along.

I don't know where it is on the stabilization timeline but it would be nice to see the ability to move a heap value out of a Box<T> without using the stable APIs.

I've a few use cases where another languages is calling Rust and I want to return an allocated struct over FFI but std::mem::transmute(Box<T>) has a size mismatch and std::boxed::from_raw/into_raw are unstable.

Take a short snippet of your code pastebin it, bring your question to #rust and we'll help you quickly.

FYI, Box::into_raw will be stable in Rust 1.4, next release.

Nice! That's what I was wondering :)

> std::mem::transmute(Box<T>) has a size mismatch

This sounds like trying to fit a fat pointer in a regular one. into_raw won't help with that.

Who is allocating, Rust or the other language?

Rust is both allocating and deallocating. With the case of using Rust like a library we don't know the lifetime(since it's owned by the calling language) so rather than stuffing it in a 'static context and use some sort if ID for lookup in the API I'd rather just return the raw struct.

Yeah, in that case, just waiting for the next release is best. You can do some `transmute` shenanigans in the meantime, but since it's coming so soon, might as well just wait.

Rustonomicon - great!

Reply on news.ycombinator.com