
Rust creator Graydon Hoare is now at Apple working on Swift - flount
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170123/003899.html
======
brson
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.

~~~
kibwen
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?

~~~
nnethercote
> under no uncertain circumstances are they allowed to submit code

Really? Why is that?

~~~
fruitco
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.

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

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

~~~
sfilargi
> 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?

~~~
darksaints
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.

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

~~~
macintux
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.

~~~
chwind
what is a function head?

~~~
ZephyrP
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.

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

~~~
monocularvision
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.

~~~
AsyncAwait
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.

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

Those are bugs, please report them:
[https://bugs.swift.org](https://bugs.swift.org)

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

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

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

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

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

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

~~~
Haldir
Afaik anders ist still at Microsoft doing typescript

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

~~~
zamalek
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.

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

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

~~~
barrkel
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.

~~~
gcp
_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.

~~~
barrkel
_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.

~~~
gcp
_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.

~~~
barrkel
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.

