Announcing Rust 1.14

Given the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT from wasm to one of them), so there'll be no need to wait for all browsers to have implemented it, it just won't live up to its performance on all platforms.

I think you are being too pessimistic about the speed of mass adoption.

On the desktop: Firefox, Chrome and Edge auto-update.

On mobile: Android 4.4+ (over 80% and rising fast) auto-updates its webview component. iOS receives yearly updates that are applied by a very large majority - though Apple's browser development does seem to have stagnated a bit.

So it seems to me that non-updating browsers are going extinct, and that we won't be dealing with another IE6 anytime soon. We're living in the future! :-)

Why is 80% the magic number? 5% would reach more than 100 million people. That's enough to keep a team busy and a product growing while the competition sits on its butt waiting for the next 75%.

There is a shim so you don't need to wait for all the browsers to implement wasm

Rust is indeed known for memory safety and zero cost abstractions. But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax.

With such a type system, it is possible to encode the invariants of your application in types (using generics and algebraic data types). Then you can get very close to "if it compiles, it works".

JS, in particular, is the opposite. I am never really convinced that any JS I have written is "correct". It works, until one day it doesn't. This is such a problem that there have been multiple attempts to retrofit type-systems on top of it.

Rust needn't be the only language that brings strong typing to the frontend (Elm has been around for years now). But I think the prospect of speed and correctness both front and back is pretty exciting.

Are you saying because it can do A it can't do B?

Are A and B mutually exclusive per se or is that just an unfounded assumption?

I use Rust for web 1 year already and I can say it's awesome. Try.

memory safety isn't the only advantage.

0 cost abstractions do matter a bit. In general abstractions let you do high level programming in lower level languages.

The type system matters a lot.

I used to do a lot of scripting. One thing I really missed was having a good static type system. These days I miss ADT enums in all languages.

Scripting is already moving in the direction of being more type safe (typescript, python type annotations), which is awesome, but I'd love to use something like Rust in that sphere.

I love JS (pretty unpopular opinion here on HN) and I love Rust also and I'm not convinced using Rust on front-end tasks would have any benefits. Yet, I strongly disagree with you on this point :

> Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint

Rust's type system is wonderful, and it's a real productivity boost. Fortunately people at Facebook developed an equivalent for JavaScript [1] because living without it would be really hard for me now. Furthermore, Rust offers a lot of syntactic sugar that makes it feel like a really high level language (compared to C, Go or even JavaScript pre-ES6 for instance).

>it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend

It's indeed one of Rust selling point (especially for people coming from a C background) but it's not the only one. My favorite being the data-race free parallelism. I don't know the current status of multi threading in wasm, but being able to take advantage of all the cores of mobile devices could really help front-end frameworks.

[1]: http://flowtype.org, it's not inspired by Rust but inspired by OCaml, which also inspired Rust.

If you don't like it, you don't have to use it. The beauty of WebAssembly is that it can be targeted by so many other things. Finally, we can let JS sink or swim on its own, without being propped by an artificial monopoly on the web frontend scripting...

I'm not 100% sure if I tried it in any of my apps, but I think I did, and can't recall it not working. I'll try again soon and will tell you if it works.

Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.

> just as everyone "rallies" around EventMachine in Ruby.

You can't really compare things this way. Very few people even use EventMachine, as it has significant issues.

You can't just show that rotor and tokio are two different libraries; you've claimed that there's significant ecosystem fragementation. That's a very different claim. The same goes for the other three sets of links below: that you can find a bunch of GitHub repositories does not mean that there's actual fragmentation. Writing a memcached or Redis client is a good way to learn a language, even: I've known two people who independently did so for memcached + Rust, tossed them up on github, and that's it. (one of those is one of the links you've provided above, even.)

> Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations.

Because it's synchronous. Once tokio has an actual 0.1 release of the full stack, which is to happen any day now, you'll see more consolidation.

> until a single solution is blessed by the Rust team.

Two of three of tokio's core team members are Rust core team members. We had a full talk on it at RustConf, and it was mentioned in the keynote. Mozilla has sponsored development of it in places.

  > their respective languages refused to bless them as 
  > "official."

Tokio is literally developed by 1) the Rust developers and 2) contractors paid by Mozilla to work on Tokio. It's as official as Cargo is. :P

The "Rust team" isn't picking winners, but they do happen to be contributing to and creating the leading solutions. There is a lot of energy around futures and tokio, very early on in the story of Rust. Sure, Rust has already been around for a while, but 1.0 was only last year.

If you like Rust, and you want to use it for network and server related tasks, get involved. Write the redis, memcache, HTTP clients of your dreams. Rally the people who've solved those problems in Rust (and elsewhere) in the past.

Please try to state your concerns (or better yet, ask questions) in a more thoughtful manner.

> Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official."

At least in the case of Twisted, it probably didn't help that for a long time it was GPL licensed with all community contributions requiring copyright assignment to the lead developer.

> When?

Tokio was only released along with futures like 3 months ago? It takes time to rebuild software on top of that. It definitely took me time to port from directly using MIO to using tokio.

After evaluating others options, I do believe tokio will be the default for most people.

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).

> You say it like it's a good thing.

Why wouldn't it be? Let people experiment. As long as there's a standard, go-to library for applications that need to "just-work", I don't see any reason not to explore new ideas and find potentially better solutions for the future.

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?

I'm pretty sure he did know what you meant, and offered a serious response. I think he's suggesting that perhaps the aesthetics of the ellipsis is what prevented it from being selected.

More because Option is not really intended to handle errors while Result and ? are.

Thanks, that makes perfect sense. I haven't followed the internal discussion at all.

It sounds like there are some that would like to move Rust in the direction of becoming more Haskell/ML-like (which is to say more purely functional) rather than the current balance between imperative and functional? Is there any internal tension in that regard?

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.

c) a bad practice since it will make your program crash is a node has no parent.

if the node always having a parent is a invariant of your application, you should use `expect` with a clear error message when the invariant is broken.

if your node can have no parents then you want to handle this case explicitly with a `if let Some(parent) = node.parent() {` pattern.

What does proper error handling look like when I want to use the same "invalid node" error for most of those unwrap calls?

Because while you may not care at first, you will later, and Rust will help you out then.

You're not ignoring errors with unwrap(): if there is an error, the program will print out a stack trace and exit. If you have some operation that could potentially fail but you know it won't (like if you are sure that node has a parent) what do you do? If the operation actually does return an error, it means what you thought to be true was wrong, and in some cases that means something has gone seriously wrong, and your program should immediately stop so you can debug it. You can try to handle the error yourself, using try! or the ? operator, but unless you plan to be able to recover from that error, or you want to output a more end-user-friendly error message than a stack trace, what's the point?

This is the same in rust. Panics end at thread boundaries. So you'd have some event loop with threads / coroutines doing stuff and if they panic you handle it at the top level.

There are errors, and there are errors.

The kind of error that you'd handle high up the stack is, say, a general I/O error reading a file.

But when you look up an item in a collection (or a node in a DOM tree), and it is not found, the only place where you can sensibly handle that is right where the lookup happens, usually.

In a language that doesn't follow this philosophy, what you get instead are random NullPointerExceptions etc. If you go and look at a random C# or Java project on GitHub and check its tracker, you will see that - surprise, surprise! - that is exactly the type of error that shows up most.

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

Harder to parse is one thing, but if it could match the output of config.guess, and/or allow to skip the "unknown" part so that the triples match what's used for GCC prefixes and clang's --target, that would be way nicer.

https://github.com/rust-lang/rust/issues/33147