
Announcing Rust 1.14 - steveklabnik
https://blog.rust-lang.org/2016/12/22/Rust-1.14.html
======
adwhit
Write your Rust app. Compile to a binary on the backend, wasm on the frontend,
using asyncio to communicate transparently between the two. Update the DOM
directly from wasm, with 60fps rendering from Servo's WebRender. Totally
typesafe and lightening fast.

It could all be so beautiful.

~~~
15155
> using asyncio

Don't hold your breath.

Unfortunately, the community seems to be going the way of Ruby/Python/C++:
massive fragmentation.

~~~
timClicks
Rust is a magnet for creative, intelligent people. There are bound to be lots
of implementations for things like low-level I/O because lots of people want
to explore the relationship between the OS, the application and the hardware.
That is different than fragmentation in the sense you're implying.

The Rust community is pretty unified, esp. as its communication channels are
well defined. For asyncio, I am pretty sure that Tokio will be the tool for
most applications.

~~~
15155
> That is different than fragmentation in the sense you're implying.

It is! But there are a mass of completely incompatible, overwhelmingly popular
libraries.

> For asyncio, I am pretty sure that Tokio will be the tool for most
> applications.

When?

~~~
kibwen
Tokio is already eating the ecosystem, voluntarily. The authors of the only
other two competitors, Rotor and GJ, told me at Rust Belt Rust that they're
planning on deprecating their projects and throwing in with Tokio (perhaps
largely thanks to the fact that the Rust/Mio devs asked them both for their
input during the design of Tokio).

------
oblio
I have a question for Rust users: let's say I'd want to write a system tool
that has to run on multiple platforms (Windows/Linux/Mac) and that would
integrate with all sorts of command line utilities.

I'm interested in using Rust, but would Rust be a good fit for this? The tool
would be long lived so I'd want a statically typed language with a modern type
system and as many safety guarantees as possible. But I'd also want a high
level programming language and also libraries that would help with that
integration (launching processes, capturing output, monitoring progress,
parsing output: text, JSON, XML, etc., etc.). I'd also want a tool that runs
quickly but I figure there's no point in mentioning that in a thread about a
language that compiles to native code and that has no garbage collector :)

~~~
nekohacker
Rust sounds perfect for what you want to do. It takes a bit of practice to get
used to its parsing, since it's extremely safe, but when you get things
running, they run very well. As for cross-platform capabilities, it has fairly
mature support across all the mainstream OS platforms, and developing support
for others such as ARM. Check out this page ([https://forge.rust-
lang.org/platform-support.html](https://forge.rust-lang.org/platform-
support.html)) for more information on Rust's platform support.

~~~
stymaar
I totally agree.

@oblio you should have a look at the “24 days of Rust” blog series[1] which
covers a lot of aspect of the Rust ecosystem (serialization, error handling,
path management, configuration handling etc.)

[1] [https://siciarz.net/24-days-of-rust-working-
json/](https://siciarz.net/24-days-of-rust-working-json/)

------
corndoge
Love Rust. That said, I have not figured out the following, and I'm sure that
there has to be a canonical solution for this:

I have a Rust application that depends on 1 crate from crates.io. I want to
build it on an embedded device over serial that has no networking
capabilities. Does Cargo have an 'offline mode' or something that I can use to
say "I don't want to depend on the Internet to build this, just fetch this
version of the crate and keep it?" Because I have not been able to find
anything like that. I'm sure there's a good solution for it because Rust is
billed as a systems language.

~~~
steveklabnik
[http://doc.crates.io/faq.html#how-can-cargo-work-
offline](http://doc.crates.io/faq.html#how-can-cargo-work-offline) is a TL;DR.
You'll possibly also want to look at [https://github.com/alexcrichton/cargo-
vendor](https://github.com/alexcrichton/cargo-vendor) and
[https://github.com/alexcrichton/cargo-local-
registry](https://github.com/alexcrichton/cargo-local-registry)

~~~
corndoge
I read the first and last link, had not seen the second. Looks like what I
need, thank you. Surprised that Rust seems to expect people to have Internet
access to build.

~~~
steveklabnik
As the FAQ says, it only expects it when it needs to get something from the
internet, which is a pretty reasonable default. I am biased, though ;)

~~~
flukus
Is this similar to nuget, if your familiar with that? Ie, do you have "pinned"
versions in a project and only need to access the internet when a package is
missing?

~~~
steveklabnik
I haven't used nuget a whole ton, but yes, that sounds like it. Basically, you
have two files: Cargo.toml and Cargo.lock. The toml file declares what version
ranges you want to use, then after a successful build, the exact versions used
were put into the lockfile. After that, nothing will hit the network or change
up versions until you either modify the version ranges in the toml file or use
the command-line interface to ask to upgrade.

------
anuragsoni
Great to see Rustup reach 1.0 release. I like how easy it makes to test out
different versions of rust and its toolchains.

I like the '..' addition for structs. It definitely improved the pattern
matching over structs.

    
    
      let p = Point { x: 0, y: 1, z: 2 };
      match p {
        Point { x, .. } => println!("x is {}", x),
      }
    

Congrats to the Rust Team for another good release!!

~~~
cannam
There must be some interesting reason why ".." and not the more common "..."
\- I wonder what?

~~~
swsieber
Reading through, they treat a range (like 1 .. 10 ) as pattern matching 1 2 3
4 5 6 7 8 9 10, with .. representing 2 3 4 5 6 7 8 9.

In that light, it actually makes sense.

~~~
anuragsoni
Minor correction, to match a range the syntax would be

    
    
      1 ... 10

------
Perceptes
Congratulations and thank you to the Rust team! As always, I've updated my
Rust Docker image[0] for 1.14 (both the latest and 1.14.0 tags) for anyone who
has Docker installed and wants to try Rust out quickly. Although with how easy
Rust is to install via Rustup now, the value of this image is diminished
somewhat. :}

[0]
[https://hub.docker.com/r/jimmycuadra/rust/](https://hub.docker.com/r/jimmycuadra/rust/)

------
libria
> experimental support for WebAssembly as a target, wasm32-unknown-emscripten
> [...] check out Tim’s example of the classic TodoMVC project.

On one hand this is really cool and potential for client-side Rust. On the
other hand:

    
    
        let id = node.parent().unwrap().parent().unwrap().data_get("id").unwrap().parse::<usize>().unwrap();
    

Eh, no thanks. :) If I could get a macro or shorthand for that, I'd welcome
all the other benefits of a large scale client-side platform with strong
typing.

~~~
bbatha
When the carrier trait lands this becomes:

    
    
        let id = node.parent()?
                     .parent()?
                     .data_get("id")?
                     .parse::<usize>()
                     .ok()?;
    

I'd also expect that someone will write higher level libraries so that you
aren't doing raw DOM manipulation. A rust vdom wasm library would probably be
blazing fast.

~~~
topspin
Even without the ? sugar I don't see what's so offensive about this; the least
little formatting effort produces:

    
    
        let id = node.parent().unwrap()
                     .parent().unwrap()
                     .data_get("id").unwrap()
                     .parse::<usize>().unwrap();
    

If there is something horrible about that I don't see it.

~~~
oblio
> If there is something horrible about that I don't see it.

Isn't unwrap():

a) boilerplate

b) repetitive?

~~~
steveklabnik
It's boilerplate in a certain sense. Those are all points where what you've
written might not work. Rust makes you deal with possible problems _somehow_.
Specifically, this is a replacement for null. If you legitimately don't care,
then it can feel boilerplate-y, but it also lets you start by not having to
care, and then searching for unwrap and replacing it with better handling.

In other words, it's boilerplate here because this particular operation has
many possible failure modes, and Rust is pointing those out to you.

It's repetitive in this particular instance, but doesn't have to be in
general.

------
the_duke
Anyone know if macros 1.1 will be in 1.15?

~~~
steveklabnik
That is the plan, yes. It's not in the beta yet, but will be backported.

(For those of you who don't pay super close attention to Rust development,
that means libraries like Serde and Diesel will be as convenient to use on
stable as they are on nightly, today.)

~~~
Perceptes
Is this the first time a feature stabilization has been made to a version that
has already moved into the beta phase? My understanding was that beta was
pretty much frozen except for bug fixes.

~~~
steveklabnik
Yes. It's a perfect storm of coincidences, basically. It's a combination of
timing + a tiny feature.

Let's take a step back. Macros 1.1 is RFC 1681: [https://github.com/rust-
lang/rfcs/blob/master/text/1681-macr...](https://github.com/rust-
lang/rfcs/blob/master/text/1681-macros-1.1.md)

See the section saying "The initial implementation of librustc_macro is
proposed to be incredibly bare bones:" it really is very, very small. So it
landed, and while there was some questions that came up, people migrated to
it, and it works well.

22 days ago, it was to be reviewed: [https://github.com/rust-
lang/rust/issues/35900#issuecomment-...](https://github.com/rust-
lang/rust/issues/35900#issuecomment-264022584)

However, two things happened: one, the Mozilla all-hands in Hawaii, which
shook things up, but secondly, that meant a lot of people, including one of
the reviewers, took PTO around that time, to actually see some of the islands.
That includes someone who was on the reviewers list. So in general, "oh hey
this is waiting on one person who forgot to check a box but isn't reachable
now" is awkward.

Luckily, in this case, we know that it was just forgetting to check the box;
Felix did not have any objections that we were aware of. So we decided to sign
off for him, and put it into FCP. This happened so that FCP technically passed
the deadline for 1.15, but given how important it is to ship, we're planning
on nominating it for a backport, and don't anticipate complaints.

So: tiny feature, code wise. Big win for being stable. Procedural mishap
involving awkward scheduling. All these things played into it. Make sense?

~~~
Perceptes
Seems totally reasonable. I was just curious if anything like this had
happened before. Can't wait for 1.15!

~~~
the_white_oak
Yes, it did. Cargo had a bunch of features released ahead of time, see
[https://github.com/rust-lang/cargo/issues/3282](https://github.com/rust-
lang/cargo/issues/3282).

------
wyldfire
I'm psyched to try wasm. Are there any crates which provide interfaces to
things like a canvas object?

~~~
steveklabnik
There were some experiments long ago:
[https://www.reddit.com/r/rust/comments/2yfsi9/rust_to_js_wit...](https://www.reddit.com/r/rust/comments/2yfsi9/rust_to_js_with_emscripten/?st=ix0spbxl&sh=13e1e707)

but it looks like SDL2 has an official port: [https://github.com/emscripten-
ports/SDL2](https://github.com/emscripten-ports/SDL2)

So you'd use regular Rust SDL2 libraries, and it Just Works (hopefully...)

------
EugeneOZ
"feature request": please announce what is new in beta also. Maybe I'm not
alone on beta and if I would knew about web-assembly in beta, I'd test it 6
weeks ago :)

~~~
steveklabnik
We used to do this, but it made release announcements feel redundant, and part
of the beta process is making sure that we don't need to back anything out, so
we can't even 100% guarantee that beta is absolutely going to have whatever
feature.

------
dorfsmay
Any plan to integrate rusti (or another REPL) in the basic tool kit, the way
cargo is part of it?

~~~
steveklabnik
If one comes along, it's very possible. rusti describes itself as experimental
still, as far as I know.

------
andrewchambers
Why the heck do all the platforms have 'unknown' in them? It seems stupid.

> mips-unknown-linux-gnu > wasm32-unknown-emscripten > arm-unknown-linux-
> musleabi

What value does that garbage add to it?

~~~
Manishearth
That's how target triples work.

[http://wiki.osdev.org/Target_Triplet](http://wiki.osdev.org/Target_Triplet)

The "unknown" is the vendor field. Most linux OSes don't have a "vendor".

Target triples are of the form arch-vendor-kernel, and the -kernel is
sometimes in the form -kernel-abi)

So you can have x86_64-pc-windows-gnu or x86_64-pc-windows-msvc or
x86_64-apple-darwin with the vendor field set.

Most of the OSes with non-unknown vendors already have Rust binaries, so most
new platforms will be unknown.

~~~
stymaar
Thank you !

Maybe this could be documented somewhere on the rustup doc so new users like
me aren't puzzled by this strange “unknown” everywhere. Or maybe it is, and I
just didn't find it because I was too lazy to look explicitly for it …

