nrc

Many of the features of such crates are making their way to the standard library, so things will definitely improve. Figuring out what is best has taken some time and Rust has not wanted to prematurely commit.

Nope, try blocks are a new (unstable) feature

My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.

To be clear, there are not use cases in the std lib. The use case is as an intermediate representation for the compiler, and that is no motivation for inclusion in the language (in the same way that we don't have vtables or register allocation in the surface syntax)

No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.

We'd like anyone who is interested in Rust to fill out the survey, even if you've stopped using Rust or have never used Rust (and of course if you're a Rust user, however much or little you use it).

I'm sorry you've had that experience. We are working hard to be better open source citizens in many ways, including better communication on issues, etc.

This should work (it's my goto test case). You have to put the cursor in the erroring code to see the possible fix icon in the margin. If you don't see it please file an issue with the project you're trying this in and I'll investigate.

We're literally hacking on this right now. It should be part of the early June stable release.

It should yes, if it doesn't then its a bug that I should fix...

Syntax highlighting is (usually) done by the editor, not the server in the LS protocol. The changes sent from editor to server are pretty minimal, and so the whole thing is pretty quick. The overhead, never caused us any problems.

Indeed, the RLS uses that protocol to communicate with IDEs.

The compiler will not enforce more style in the future, that will be done by Rustfmt, a separate and optional tool. In fact, it is likely that the compiler lints which enforce style will move out of the compiler and in to Rustfmt at some point in the future.

Major points: donations are used for projects working on things like web literacy, rather than on large engineering projects like Firefox. The more Mozilla get from donations, the less dependent on Google/Yahoo they have to be and thus they can be more independent - even fairly small absolute amounts will 'push the needle' here.

Minor point: I strongly contest that Mozilla is a wasteful company - salaries are low by large-tech-firm standards and spending (on travel, equipment, etc.) is fairly frugal. I have never heard of employees having almost work to do - it is nearly always the opposite. Travel is nearly always for coordinated team work since many employees and volunteers work remotely. For a (relatively) small budget, Mozilla produce an awful lot of results - the entire company is run on vastly less than the marketing budget (!) for Chrome, for example (sorry, can't find a source though).

There is syntax highlighting for Vim, Emacs, and Sublime Text editors. GitHub does syntax highlighting for Rust repos and in Gists. There is support for Rust in the Pygments syntax highlighting library (which is used by a bunch of tools). Several community members have worked on IDE support for various IDEs (e.g., http://plugins.jetbrains.com/plugin/7438). Post-1.0 (i.e., next year) we plan to really focus on excellent tool support, so expect lots of cool stuff then.

With structs, pretty much the only difference is the syntax. Enums are probably where the biggest differences are from C, as far as data types go.

In Rust, we are quite strict about the syntax used for destructuring matching the syntax used for instantiation. There is a name in the tuple-struct declaration, therefore you must use the name when pattern matching (even though it is redundant).

Featherweight Java (http://www.fos.kuis.kyoto-u.ac.jp/~igarashi/papers/fj.html) was a seminal paper which showed type soundness for Java. The formal syntax was a subset of Java subset and preserved the interesting features in the semantics (as opposed to encoding a language in an extension of the lambda calculus, which is an alternative style of formalisation). So, "featherweight flavour" refers to formal type systems work which follows this style of formalisation.

All array indexing is bounds checked, so those kind of errors are prevented. We're still working on the story around overflow checking

I actually used enumerate in an earlier version of this post, but in the case I used it didn't work (pointed out to me on /r/rust). I'm going to go into enumerate and other iterator functions in future posts, so left it out for now. I agree this is a better formulation.

It was a design decision made long ago and seems to have stuck (although is slightly less extreme than it used to be). I also used to hate the abbreviation, but I find you get used to it quickly and after a few weeks it doesn't impact readability at all.

To clarify, current Firefox does support Windows XP, as long as it is up to date, which means service pack 3. If you are still using an _unpatched_ version of Windows XP, well, you're on your own.

I think you underestimate what can be done with bad hardware if the motivation is there - FirefoxOS phones are really bottom end hardware and the UI (app opening, or changing screens, for example) is built using CSS transitions etc. They are just as smooth as native transitions on much more powerful hardware. With a good implementation and a good understanding of exactly when you hit the fast path optimisations you can do wonders.

The problem is not with web technology, but with the implementation and use of web technology. Of course, since this is mostly out of the hands of app developers, this doesn't help much. But I think it is important to be blaming the right culprits.

(Hopefully we are not too far off bringing these optimisations to Firefox on Android at least, for now they exist only for Firefox OS).

For Firefox at least, this is probably because you are not using DirectWrite - that in turn is probably because you are not getting D3D10 (you are probably using D3D9 or no hardware acceleration), the usual cause of this is due to out of date drivers or black-listed hardware. You can check what hardware acceleration you get in the graphics section of about:support.

If you are not getting HWA, you can try forcing it on by setting 'layers.acceleration.force-enabled' to true in about:config (I would do that in a throw away profile though because it might crash Firefox; that overrides the black list).

The translate z trick does not work in general. It works right now in Chrome (and probably Safari). It does not work in Firefox, it may not work in Chrome in the future. (Because you are trying to trick the browser by gaming it's heuristics, those heuristics might change).

That hardware rendering is smoother is also not true in general, just some cases, which the browser will try to guess for you.