I can understand why this is on HN, but as you say this is old news to most of us in Rust. For those not in the know, Graydon left Mozilla for a startup in 2013, and IIRC began at Apple in... 2015?

Really? Why is that?

Some employers do not like employees doing things on the side without permission.

While I wouldn't say that it wasn't a systems language, I would say that it was far more focused on higher level coding than the current rust is. Which is fine IMO...the world can benefit from a new safe low level language far more than it needs a new application-level language. But for someone who really liked the early ideas of rust, swift makes a lot of sense as a substitute.

So, OCaml?

I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax provides a theoretical adoption benefit, so I think he was willing to deal with that.

Or possibly French sentences...

(As an aside: Surely the capitalized version of snake_case is Snake_Case, not SnakeCase. Very few languages are consistent here.)

Pattern matching for function heads is magical. Thus sayeth the Erlang fanboi.

This allows you to easily create special logic for corner cases and is generally extremely useful.

  gcd(a, 0) = a
  gcd(a, b) = gcd(b, a mod b)

  gcd(A, 0) -> A;
  gcd(A, B) -> gcd(B, A rem B).

I think part of the problem is that they rely too much on SourceKit, which is a rather indirect and slow way to provide basic features like syntax highlighting and auto completion. These should be built into Xcode itself. As it is now, SourceKit has to do substantial work in a short amount of time which results in frequent crashes.

The compeller's error messages could use some improvement too, I don't consider 'BAD_EXEC' to be a descriptive error at all.

Those are bugs, please report them: https://bugs.swift.org

Apple will obviously improve its Mac tools. What Swift needs is great, and even better, tools for other platforms. Will Apple keep Swift wide open if it Google gives it first class support on Android, for example?

https://swift.org/blog/bridging-pch/

It's definitely a better language than C# after that

(EDIT: Am I incorrect that they are deprecating the things I need in Firefox, am I incorrect that I don't trust them, or am I wrong to have hope for a good outcome?)

(I am a Mozilla employee working on Rust.)

You are incorrect that Rust is coupled to Mozilla.

XUL support isn't removed yet, and the bugs and requests for feedback are open and out there. It's also possible to implement new WebExtension APIs (WebExtension Experiments) and inject them as an add-on, in order to test replacement APIs.

Most of the major addon authors have engaged there, and many already have a WebExtension port. (For those that had Chrome versions, that should be no surprise - the APIs are essentially compatible)

And there doesn't seem to be signs of awareness of the risks of destroying an add-ons platform in the Mozilla team's public representations, or in their reactions to bugs reported by some fairly significant add-on authors considering rewriting to the new API.

It's very well understood that some kinds of very invasive add-ons may no longer be possible, and Mozilla is very well aware of that - to some extent it's very much intentional as it's an essential step to improve the quality on browser upgrades and prevent the continuous breakage that exists now, as well as get some things like Sandboxing working at all. The requirements of the most popular add-ons are tracked, and bugs are filed for the missing parts. But it's not because one popular add-on author whines that he should be allowed some random invasive API hooks, that it will be added. (cough DownThemAll cough)

It's silly to claim the add-on platform will die out when in reality we now have an extension system that works across all major browsers. At least one of those browsers has a (now essentially compatible) add-on collection that has been gradually dwarfing Firefox's. Arguments that add-ons are competitive advantage for Firefox have had no base in reality for the last few years. XUL add-ons and the idea that an addon should interact directly with browser internals have been a stone around Firefox' neck in terms of quality and reliability, and I'll gladly cut the noose.

Maybe. We'll see. All I know is that if I could get a menu bar and tree style tabs in Chrome, I'd have switched 5 years ago.

Right, so the only reason why you use Firefox is that you're being held hostage by add-ons. Isn't that terrible? We'd rather make a browser you actually WANT to use and if that requires pouring gasoline over the add-on ecosystem and setting the thing on fire, I'll be first in line to bring the matches.

Chrome is almost unusable in its current form. It's like a toy; it becomes completely unwieldy after opening a few dozen tabs. It doesn't scale to my browsing usage. I only use it for development. I also don't like its text selection algorithm, being a selection reader.

If Firefox approaches Chrome's toy-like non-scaling nature, and retains all its other disadvantages, then I'll look and see what other options I have.

(I've had to troubleshoot issues with Firefoxes being subtly broken due to how DTA injects into the network stack. That made for a rather biased reading of the above thread.)

The only thing Mozilla does in regards to Rust is pay the core developers. Apart from no longer paying them, there isn't much Mozilla can do to influence Rust - it's a community driven project.