While compilation time is a well known Rust pain point, Rust error messages are really one of the best part of the language.

Complicated error messages are clearly no a common occurrence unless you rely heavily on meta-programming tricks, and that is not common in Rust, unlike C++.

And the intention is to improve those too. It's hard, and I would prefer crate writers show more restrain than they do, but we have to meet users where they are.

You can already write kernel modules in Rust too.

The point is to integrate the Rust language to the Linux infrastructure so you can merge rust drivers to the official code base.

I'm not sure you can compare the code base of you first program in Go, that is probably small and straightforward, with something as huge and complex as Firefox.

Fair point! (But also I will say the relative smallness of my projects in other languages has proved no defense against code breakage w/ time :-)

The only real charset we should call ASCII is the 7-bit original standard. The 8-bits charsets are ASCII extensions.

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

But the square brackets used in array access nest, so the parsing is never ambiguous.

The reason > needs braces is that without them, if you're parsing and so far you've seen these characters:

  let y: RectangularArray<i32, X, 2>

You don't know if that final > is ending the argument list, or is a greater-than operator, with the rest of an expression coming after it.

But if it was square brackets, then a closing square bracket on its own can only ever be the end of the list:

  let y: RectangularArray[i32, X, 2]

Because if it was closing an array access, there would have to have been an opening square bracket:

  let y: RectangularArray[i32, X, a[1]

In case anyone ever stumbles across this thread, a couple of posts about this:

https://keleshev.com/parsing-ambiguity-type-argument-v-less-...

https://soc.me/languages/stop-using-for-generics

That's what I originally thought about, but the thing is `]` in and of itself is not an operator while `>` is, so

    foo<bar, qux>corge>

"is" valid syntax while

    foo[bar, qux]corge]

is not. The former requires some sort of disambiguation, while the latter is not. Put an other way, in terms of syntax `[]` always parses the same way (with `[` is infix and `]` terminates it), there can be ambiguity between indexing and generics but it doesn't really matter for the original parsing.

For `<>` however, the parsing itself can be ambiguous as `>` could either be the terminator of an earlier `<` or it could be the infix `>` operator. That is where the issue lies, you can't know how to build the AST without either explicit disambiguation, or infinite lookaheads.

You have to be aware of this but most of the time this is not a problem. Most of the useless checks are optimized out, and if you suffer bound check performance somewhere in the program, and you know what you are doing, you can do unchecked indexing using an unsafe block with `get_unchecked()` .

Servo is a complete experimental standalone web engine. It only use the Javascript engine from Firefox (Spidermonkey).

Firefox is only using some parts of Servo : the graphic renderer (WebRender) and the CSS engine (Stylo).

It is not.

Go alone is easier than Rust. But since Rust has no GC, it is easier to embed, especially with a language with a Garbage collector like Python.

I guess you are talking about https://air.mozilla.org/bay-area-rust-meetup-february-2016/

In this case the bug was only for a small subset of the Firefox users (Firefox without x264 support).

It doesn't seems impossible to me they missed this specific case.