Rust creator Graydon Hoare is now at Apple working on Swift | Hacker News Reader

Rust creator Graydon Hoare is now at Apple working on Swift

lists.swift.org

211 pointsflount65 comments

Graydon has been on Swift for a while, and there are a few other prominent Rust contributors there as well. I hope they are enjoying themselves and make good things.

Indeed, Huon Wilson and Alexis Beingessner are both at Apple now, and happily they remain active in the Rust community as well (though under no uncertain circumstances are they allowed to submit code).

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?

> under no uncertain circumstances are they allowed to submit code

Really? Why is that?

I don't know for sure, but I'd imagine their job contract with Apple forbids them to do that.

I have heard rumors that someone (I have no idea who) has been fired from Apple for contributing to Rust without permission a while back.

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

If an employer tries to dictate to me what I do in my personal time, that is a signal for me to leave quickly.

Many big tech companies have strict rules regarding which open source projects their employees can contribute to (e.g. AIUI Googlers have to clear every individual code contribution with their legal department, or else have the lawyers give them blanket access to contribute to a particular project), and Apple's policy is notoriously more strict than most (though I don't even know if Apple employees are allowed to confirm or deny this, thanks to NDAs).

It's interesting, and I think it makes sense to me. I started playing with Rust around 0.6 and the focus of the language seemed very different from today. It seemed there was a lot of focus on the more ML-ish aspects of its roots, such as the module system. The language also had a convincing future story for both green threads and garbage collection.

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.

> It seemed there was a lot of focus on the more ML-ish aspects of its roots, such as the module system. The language also had a convincing future story for both green threads and garbage collection.

So, OCaml?

Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism.

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.

I think this is the first time I see anyone like the OCaml syntax.

I think I like Reason's syntax better, but can't say I dislike Ocaml's.

And I believe Reason's syntax was inspired by Rust, so we've come full circle. :P

I've not looked at OCaml, but when I discovered that ML's pattern matching works for function heads, I immediately became more interested.

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

what is a function head?

In some languages, a function can be defined multiple times with different signatures (multiple 'heads'). It will try each clause until it finds one that matches, allowing you to filter or change course on the basis of the value or characteristics of the arguments.

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

Pattern matching can be used in the parameter list of function's definition.

If you look at the Wikipedia article for Greatest Common Divisor, you see this:

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

That, in effect, is what pattern matching + function heads gives you. You can copy that function directly into ML or Erlang, modulo a couple tiny bits of syntax.

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

As I recall, early Rust versions used lowercase for non-built-in type names, too, which I found unnerving. I'm glad they changed that, though I wish they'd also moved to use camelCase for non-type identifiers.

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

Using any capital letters in code is an instant point away from a language IMO. Having to press Shift sucks.

The weirdest OCaml syntax (to me) is the way that that exceptions are essentially reversed camel case mixed with snake case (e.g `Not_found`, `Division_by_zero`). I assume that this was to try to imitate the structure of English sentences, but it feels bizarre to me when I see it in code.

> the structure of English sentences

Or possibly French sentences...

Good point, I forgot that OCaml is French. On a related note, I've heard that might be related to why the common style is to prefix the colon used for type annotations with a space, whereas in some other languages with that syntax (e.g. Rust and Scala), it's more common to see no space before the colon.

early rust looked a lot like an ocaml/erlang hybrid. green threads and immutability were the entire concurrency story for a long time, in my recollection. it wasn't until later that rust started to look like a safer c++

Swift is a nice language. What's really missing is better non-Mac support. Tools, libraries, etc. It'll become a Top 10 language (by popularity) once it becomes a real option for Linux and Windows.

Once an official compiler comes to Windows, I'm all on board.

Better Mac support would be nice too. Using Swift in a larger code base in Xcode often results in long compile times, auto completion and code syntax highlighting failures and other terribleness.

Agreed!

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.

> I don't consider 'BAD_EXEC' to be a descriptive error at all.

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

Are you the Slava who wrote Factor programming language? Apple hiring all the good language designers around the world dammit!

Isn't it a given that it's on the way? You're complaining about known issues.

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?

Known issues since day one. I agree it's a given these things are on the way but when?

Mhmm. Really with all those things, i'd give it a serious try for my game development side projects. Currently using html5 for some, libgdx (java) for others.

Hopefully the recently announced precompiled bridging headers will help with compile time (for mixed-language products at least):

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

What's missing is built in concurrency/parallelism model

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

It's the most pragmatic move he could have made if he wants to disseminate Rust's ideas. Having the backing of the largest public company in the world does give you some fire power.

That's like Microsoft was grabbing all the good Borland-Developers for .Net - Does anyone remember that? ;)

His fork of the Swift repo dates back to August 29, 2016. Maybe he was hired to replace Chris Lattner?

Lattner was in charge of all dev tools, managing ~200 people. Hoare wasn't hired to take his job.

They also have Anders Hejlsberg who was the lead architect for C# right? Those are some tough names

Afaik anders ist still at Microsoft doing typescript

Bring some Rust goodness to Swift :) Also, really old news on HN

Apparently, static code analysis was part of the Swift goals. Though, the language has evolved too far without it and drastic changes may be needed.

My frustration with Mozilla deprecating everything I need in Firefox has made it impossible for me to trust them as stewards of a language. Hopefully this contributes to a decoupling of Rust from Mozilla.

(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?)

Can you share some specifics? What exactly have they deprecated?

XUL and the entire extensions framework based upon it.

XUL-based add-ons are being deprecated, and Firefox is adopting the same extension mechanism as Chrome (but with more extension points). That means that add-ons that make more or less drastic changes to the UI will need to be updated, rewritten or abandoned. This is being done before replacements of equivalent capability have been added to the new API. 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.

This is being done before replacements of equivalent capability have been added to the new API

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.

Interesting. Can you provide some links to the DTA situation?

Start here, I guess: https://mail.mozilla.org/pipermail/dev-addons/2016-December/...

(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 characteristic unique to firefox is a customizable UI, everything else can be done by existing browsers.

afaik, firefox is an "existing browser"

Arguments that add-ons are competitive advantage for Firefox have had no base in reality for the last few years.

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.

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.

There's no hostage situation. I'm not chafing against Firefox; I'd like it to be more responsive and less janky - it's a lot more janky than Chrome, there's a lot more variance in pauses for whatever reason. That's my primary problem with it. I'm not yearning to be free, given what Chrome is.

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 agree that the add-on situation is unfortunate, however I fail to see how it maps to something like Rust.

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.

Rust is a community project that Mozilla contributes heavily to, rather than the other way around. The sets of people working on those decisions for Firefox and the people guiding Rust's development are disjoint, and all major changes to Rust must go through our consensus-based, community-driven process, so even if Mozilla _were_ to try to declare that Rust should do something against the wishes of the community, they couldn't. It wouldn't work.

(I am a Mozilla employee working on Rust.)

Is there a page or blog post somewhere that describes Rust's origin story?

I gave a talk for the ACM about it: https://www.youtube.com/watch?v=79PSagCD_AY

Thanks for the link!

No problem. Happy to elaborate if you have questions.

Graydon stepped down as lead in 2013 from rust, so I don't see how that would have any bearing, and as brson said, Graydon has been on Swift for a while now.

Hoare left Mozilla over 3 years ago.

You are incorrect in the assumptions that Mozilla is the steward of Rust (and therefore that you would need to trust them in that role), and that Rust has not already been decoupled from Mozilla.

You are incorrect that Mozilla is a steward of Rust.

You are incorrect that Rust is coupled to Mozilla.

Reply on news.ycombinator.com