Four-Letter Technologies
unfortunately the barbecue place i think is closed is that part of the atp tradition yeah usually my my editing reward barbecue places are typically only open from thursday through sunday that's just like a barbecue cultural thing i don't know why what uh so usually my thursday tradition is i i edit the show somewhere around noon hopefully i'm done or at least i'm almost done i take a barbecue break that's my reward to myself for a solid morning of work but no more of that right oh what am i gonna eat
yeah i don't know i don't know oh god i can't i can't make this myself i can't like a lot of the stuff that i eat i can make myself i can't make this myself you got your own coffee roaster it's only a matter of time for your own smoker in the backyard yeah that's true so tonight we have a special episode for you and we are not really going to be covering the coronavirus and all of that terrible news
But we're hoping that with this show and hopefully future shows, we'll be able to give you a little break from worrying because, gosh knows, I'm doing enough for everyone.
So with that in mind, we actually have something extremely special planned.
And I wish I could say that we planned it specifically during a pandemic, but thankfully we didn't.
But nevertheless, here we are.
And instead of some cutesy, funny intro, we're just going to get right to it and say hello again to Chris Lattner.
Hi, guys.
It's great to be back.
Well, thank you.
Thank you for coming.
And we are very excited to have you.
And I figure we could start by just asking, what are you up to, man?
Lots of things, aside from sheltering in place.
Staying very busy.
I started a new job at Sci-5 a couple of months ago, just under two months ago now.
And so I'm learning a lot of new things, and I'm exploring new areas, also staying in touch with a lot of other familiar things.
Just generally keeping really busy.
Actually, this weekend, I finished a package shed, which is a little hut-looking thing that has a tiny roof on it that keeps packages from getting rained on.
Marco just made a house for his garbage.
Very similar.
Yeah.
Does yours also keep raccoons out?
No, it doesn't.
But the kids like playing it.
So last time we talked to you was like three years ago.
And I think we talked to you like right after you left Apple.
Since we last talked, you went to Tesla.
Then you left Tesla and went to Google.
Then you left Google and went to Sci-5.
Can you give us whatever kind of summary you feel comfortable with?
Explain that journey to us.
Okay, so how should I say this?
Let's start with Tesla.
The journey into Tesla was a big adventure, one that I knew was fraught with peril and opportunity.
The Tesla Autopilot team had been through several leaders and they each had short time horizons.
And my mental thought process going into this is that
You know, success over the long term wasn't highly probable, but I bet I would have a lot of really interesting life experiences, learn a lot, and then have some more stories, which I do, that I don't really want to share.
The exit was Elon and I had specific differences of opinion about leadership and
decided that we could not get along together.
And then he and I decided to part ways.
The entire autopilot team is very challenging, but also really awesome and really exciting team.
That's a very specifically weird dynamic.
And Tesla is a very fascinating place.
I always wonder for people who have experiences in, you know, jobs, important companies during exciting times, so on and so forth, very often, like most of them, you know, like you will not want to talk about specifics because like, whatever, move on, you move on, you learn something.
You don't want to dish a bunch of dirt or whatever.
But I do always wonder if there comes a time where we'll, we've referred to this a lot on the show, where they'll be like, oh, everyone's retired and it's, you know, 50 years after all their careers happened and they want to write about
Here's what really happened.
Like, here's what it was like in the early days making the iPhone.
A couple of people have had books like that, like Ken Kushan.
Do you ever think about sometime in your old age when, you know, you're retired and the world has moved on and we're all using our holographic AR glasses, phones or whatever.
Would you like write like a tech memoir?
Like, here's what it was like to be at these important companies during these important times.
And here are my experiences.
Or do you just have no interest in ever, you know, sharing that information?
Yeah.
I have no objection to sharing that.
I think that for me, it's just a question of time.
It's also a question of talent.
I don't know that I'd be any good at writing such a thing.
It would probably turn out really dry and boring.
They have people for that, though.
I suppose.
I guess, I mean, I can tell you things that I liked and disliked about Tesla, if that's what you're asking me.
I know it was more of a meta question of like – because you don't want to talk about it like when you're still in your career because you don't want to burn any bridges and so on and so forth.
But like if the job that you had was of historical significance and I think many of your jobs have been, it's –
It's the type of information that is valuable to history and useful for people in the future to know what was it like.
If you could read Andy Grove's book or whatever about Intel in the early days or you want to read about the creation of the transistor or the creation of Unix or what it was like to make C or the early days of the Google search engine.
I think a lot of your experience already falls into the category of being worthy of being recorded from your personal perspective.
When you're retired sometime, you're going to be saying, oh, I don't have time.
Someday, I don't know if this is true.
Maybe you think this is not true.
I assume someday you will retire.
Now I'm starting to question that of saying maybe you're just going to drop dead in front of the keyboard someday.
I think that's quite possible.
Assuming you ever do retire, I think we would all love to read that book.
yeah i mean i'd be very open to writing that i just need to have the spare time to actually collect the thoughts let me explain retirement to you and spare time is what you get when you stop working well i mean there's an aspect of my personality that i don't seek out the easy cushy jobs i know i know i i seek out the hard hard things that seem worthwhile all right so it's up from there so we can go to google now which is a hard thing that seemed worthwhile i guess
Yeah, well, so I guess a couple of different things.
So when I joined Google, I joined the TensorFlow team.
And actually, at the time, I had talked to Sci-5.
And I had decided that Sci-5 was too early on.
And I didn't really understand where they were going.
And it didn't seem like the right thing.
And when I was talking with Google, the pitch was pretty simple.
I was very interested in machine learning technology.
That's something I was interested in back at Apple, but wasn't able to do anything with it.
In the case of Tesla, one of the things I did was I force pivoted the technology stack off of this other machine learning framework called CAFE onto TensorFlow.
And so we moved to TensorFlow to get multi-GPU training support.
And
and other things like that.
And in the process of doing that, I learned quickly that TensorFlow is a good thing, but it was a ways away from being a great thing.
And so one of the things that attracted me to Google was that TensorFlow is an incredibly important
technology platform.
It's also very much a developer tool, which I have a lot of experience with.
The machine learning aspect, I think, was very appealing to me.
I had a good friend that said, hey, if you want to learn about machine learning technology, go to one of the best places in the world that's doing it.
And I think that was, I don't regret that at all.
And so the calculus going to Google was, you know, Google's also a legendary, amazing place to work, a lot of smart people.
I know many people that are there.
And so I was very excited about that.
And I'm also very excited that I joined and had a great, great time there and did some amazing things.
Some of the stuff you did at Google was like, yes, working on TensorFlow, but also there was a Swift angle on that as well.
It was kind of, you know, I don't know if you can tell me which was the cart and which was the horse, but like basically modifications were made to Swift that made it easier to work with machine learning stuff.
And they weren't features just for that purpose, but they happened to lend themselves that purpose.
And you happen to be doing that with Swift at Google.
So it's all...
You know, like how does that work out?
How did that connect?
Yeah, I can explain how that all went down.
So what I was hired to do, my starter job, you could say, is Google was developing this machine learning accelerator called a TPU.
There's multiple generations of TPU.
The one I was working on was the first training accelerator.
The idea of TPUs is to use custom silicon, a specifically machine learning design processor to be able to do machine learning training.
both faster than you can do with a GPU, but also, and I think more importantly, at a much bigger scale.
And they were just at the point in time where the hardware was now getting installed.
They had significant software challenges, integration challenges, programming challenges, and they wanted to launch it in cloud.
And so making a public product out of something that's not quite ready yet was a big challenge.
And so my starter project was to get cloud TPUs to market.
You can now get access to them now through Google Cloud.
They're a great product.
They're really, really awesome.
And so I started working on that.
Along the way, there's this discussion about, okay, well, how do we get machine learning technology to go to the next step, right?
So TPUs are an amazing hardware platform, but they don't really touch on the programming model, right?
Now, as part of building the TPU platform, there are many, many things about it that are quite different than the normal places that machine learning frameworks came from.
So one example of that is that they are thousands of chips.
It's like a supercomputer, petaflops of compute in many racks of machine.
And so the way you think about this and the way you want to program it is slightly different.
At the same time,
There are other trends in the industry, including a framework that was new at the time called PyTorch, which came out of the Facebook AI research group.
And PyTorch was pushing towards more dynamic, more natural language processing models, things like this, where the programming model isn't as static as TensorFlow was at the time.
And so there's a bunch of interesting discussions about, well, how do we get...
the programming model to move forward.
And it became apparent to me, you might not be surprised, that Python was not really great for this, right?
Because a lot of where the Python world was coming from is saying, because, so I should say, a lot of where TensorFlow 1 was coming from is saying, Python is a slow language.
And so because it's a slow language, what we'll do is we will use Python so that you can kind of script together some code that constructs a graph.
And then after you've constructed the graph, we'll go use C++ code to run it really fast.
Okay.
Now, this is one of the reasons that TensorFlow 1 was a very, what I call a static programming model.
It's because you create this graph and anything you can encode in the graph, you're good.
You can just use graph nodes and you can express these computations this way.
But if you can't express in the graph, you're kind of stuck.
You have to go hack TensorFlow and rebuild it yourself.
You have to go become a machine learning framework engineer and learn about compilers, all this stuff.
And that's beyond the abilities of most...
machine learning data scientist type people, right?
And as it should be.
And so what PyTorch did very early on is it said, okay, well, we'll shift to this dynamic programming model where, you know, PyTorch, if you squint and look at it the right way, it's basically the thinnest layer of Python that you can have on top of a really fast C++ runtime.
And so both PyTorch and TensorFlow of the day, we're looking at, given that Python is the way it is, how do we work around the limitations and how do we make something that is acceptable?
And even today, if you want to deploy a machine learning model, you don't deploy Python.
And so if you look at both the TensorFlow and the PyTorch standard ways of using them,
what you do is you write your training logic in Python, and then you use some deployment mechanism.
In the case of TensorFlow, it's a TensorFlow graph.
In the case of PyTorch, it's their TorchScript solution.
And then you end up loading it up into a bunch of C++ code, and then you deploy the C++ code.
And so where Swift for TensorFlow came from is this idea of saying, hey, well, if we take a more modern language, we can have better language integrated features, which I'm happy to talk about if you want to geek out about that.
You can have deployment built in.
So you don't have to have a you write it in one thing, output a different thing, bolt it together with C++ code.
You can just have one solution that scales.
And by doing this, you allow people to move faster.
You get research flowing into production faster and you get a lot of other great benefits from that.
So you're basically like writing in Swift and Swift is actually also the thing that run, but you're still calling into libraries and other languages from Swift.
Yeah.
So let me, let me dive into how Swift for TensorFlow works.
Okay.
So Swift for TensorFlow is a project with, I think, several major components.
One of the interesting things about machine learning is that you, and there's many different forms, but one of the most popular forms uses what's called backpropagation.
Right.
And so you do, when you're training, you shove a bunch of data into a model.
And as you're shoving data into the model, you're accumulating what are called gradients, which are the updates for the weights in the model.
The weights are basically the parameters that you actually, let me take a step back.
What is a machine learning model?
A machine learning model is a set of computation.
It's a function.
And the distinguishing feature of a machine learning model is that instead of it being a function where you write it all manually in code, you write the structure manually, but then you learn and train the weights.
And so I look at a machine learning model when you deploy it as it's a function that has all this trainable state behind it.
Now, where does that trainable state come from?
Well, the way machine learning training works is that you take a version of the model you want to deploy,
and you start shoving lots of data through it, and then you use what's, and I don't want to go into calculus here, but you accumulate what's called gradients.
Gradients are, you can think of it as like derivatives.
If you think about calculus one, it's, you know, you can take F and you get F prime, which is the derivative of a function.
The gradients in a machine learning case are just higher dimensional versions of that same idea.
And by using those in your machine learning training,
system, what you do is you shove a bunch of data through it.
You see, hey, I can get closer to a better answer.
If I nudge all the weights in this direction, they do it again.
You nudge all the weights, you do it again.
You nudge all the weights, you do it again.
Eventually, your training converges and you have a set of weights.
And now you can ship those weights as a binary blob and deploy the quote-unquote graph for the model, but also the weights that go with it.
Now, the way that it works is that you have to do that calculus thing.
You have to be able to compute the gradient or you have to compute the backwards version or the derivative version of a function.
So there's lots of different ways of doing this.
And so one of the contributions of Swift for TensorFlow is this idea of differentiable programming.
We joke this is one of the differentiating features, which is a terrible pun.
And so in most machine learning frameworks that exist today, the way this works is you build a graph and then you go do these graph transformations.
Well, the graph is just a data structure in memory.
You do these transformations and you get a new graph out.
Another way to do it is you do it dynamically.
And if you do it dynamically, again, it's a very runtime sort of a thing.
The problem with both approaches, because they're runtime things, is that when you make a mistake, so for example, you...
you forget to transpose a matrix or something, and they do a matrix multiply, the sizes don't line up, you get a runtime error.
And when you get the runtime error, it's difficult to reason about where it came from, depending on the exact details of the framework.
And so what Swift for TensorFlow does is it says, hey, well, what we can do is we can take this idea of
taking a function and calculating its derivative, build just that piece into the Swift language.
So this is a first-class language feature.
And by doing that, now you have a very generic language feature that could be used in many domains.
Machine learning is just one of them.
And you can get a much better user experience.
You can get a nice type-directed way of doing this so that it's extensible.
So you can say, hey, it works on
It works on float and it works on tensor, but I want to define a quaternion type.
I can go do that and make my thing also differentiable.
And that's something that doesn't really exist in modern machine learning frameworks.
What you'll see in them is that you'll see that tensor is differentiable, but the normal float type isn't.
Or there's special hacks around certain corner cases, but it's very difficult to extend these things.
And
Again, there's many different systems, and this is generalization, but by building into language, the goal and I think the reality is that you get a much better user experience.
So that's one of the features.
Now, what we did is we've designed all these features to be orthogonal from each other, and we want to upstream these things.
And so the differentiable programming work has long been a collaboration with the Swift community, and I think the team is planning on pushing it through Swift evolution soon.
And so it's been really exciting.
So for me, I write regular Swift stuff and iOS apps and things of that nature.
And I haven't really ever dabbled with machine learning.
And listening to you talk, my own ignorance is becoming ever more evident.
But nevertheless, the only thing that I was aware of that has kind of bubbled into my Swift universe, my perspective of Swift, is some of the Python interop.
And that doesn't sound like what you're talking about yet.
Is that fair to say?
That'd be the next step.
So the cool thing about the differentiable programming features is that they're very relevant to the numeric world.
And so there's a couple of different subgroups in the numeric world that are fairly narrow.
But in the case of machine learning, they're narrow, but really commercially important.
And so the inspiration for this feature and the inspiration for the design actually came from the old days.
It came from Fortran, where back in the old days, you have a bunch of numeric programming stuff.
And so a lot of the techniques were pioneered and figured out back in the Fortran days.
And then the world...
promptly forgot about them.
And so pulling those forward, making them work in a modern language, making it work with all the different constraints that are just very different was a big challenge and is a big challenge.
And building language features is hard, but it's been a really interesting project on its own.
Were you familiar with Fortran from whatever your past travels had been or did somebody say to you, oh, you should look at this weird old, I mean, I'm sure you were familiar with it, but you should look at this weird old language.
They had some good ideas and you had to like dig into it today, you know, in 2020 or 2018 or whatever.
Well, so these features weren't part of the Fortran language.
They were part of the Fortran community.
One of the interesting things about the Fortran community back in the day is that there were a lot of tools that read in Fortran code, transformed it, and then wrote it back out.
And so these are effectively source code preprocessors.
And so some of the source code preprocessors were doing this kind of stuff.
And they're widely used because, again, the Fortran world is, there's a lot of numeric people working in that world back then, but also today.
I would also like to say I was not the one that designed all the differentiable programming features in Swift.
It was a team effort and I contributed to that and I helped with some of the design points, but I will just be very honest that calculus is not my strong point and I'm very okay with that.
We are sponsored this week by Indeed.com.
Now, I'll be honest with you.
When they booked this spot a few months ago, they were going to run a regular ad.
But as the coronavirus outbreak hit, it just didn't seem right anymore.
So if your job has been affected by coronavirus, they've put together a guide to help and we'll link to it from here.
That's all for now.
So stay safe, everyone.
And thanks to Indeed.com for sponsoring our show.
So we both started to talk about the Python interop.
I'd love to hear a little more about that because I've glanced at it, but I haven't personally had any particular need to use it.
And I've only written, I don't know, a couple hundred lines of Python in my life.
So I'm vaguely familiar with Python in kind of some of its tenets, but this is all kind of outside my typical wheelhouse.
Nevertheless, I find it really fascinating, you know, the idea of extending Swift or changing Swift in order to make it interop better.
So
How did the Python interrupt stuff come to be?
I mean, it seems fairly obvious, but I'd love to hear your perspective of the journey and what was done to Swift to make that better.
I think you start from the premise.
So the premise was Swift is a good language for hopefully machine learning, right?
Which initially in the project, it was a theory.
It was not a proven fact, but yeah,
it was pretty clear that the entire world revolves around Python, right?
And so just having something better is not enough.
You need to provide a path for people to be able to move over.
You need to be able to make it so you can migrate existing code.
And you kind of have to integrate with all the, not just the machine learning technologies, but the huge ecosystem that has been built around the Python machine learning world.
And so this includes all the plotting libraries and all the analysis and data loading and slicing and dicing.
There's just a huge ecosystem out there.
And so interoperating with Python was a pretty clear goal from the beginning.
But then you ask the question of, like, what is the best way to do that?
Now, if you look at Swift, Swift already has language interoperability support for C, Objective-C, those kinds of languages, right?
And the way that works is a very expensive, very complicated integration with the Clang compiler.
And so Apple has invested a tremendous amount of money into making sure that all of its frameworks map over beautifully into Swift and all these things.
There's like a thousand attributes you can use to customize how it gets imported and all that kind of stuff.
And I think that makes sense for the C world.
But doing that for Python seemed very untenable for a couple of reasons, one of which is the complexity.
let's just say, could not pay for it.
It was not that important.
This all started as a research project.
But second of all, a major difference between Python and the C languages is that Python is fully dynamically typed.
And so in C languages, you have type signatures, you have API declarations, you have all this stuff to tie into, but in Python, you just don't have that.
And so...
Kind of going through this, what I realized quickly is that that dynamic nature of Python was both a huge curse in terms of working the way that the C importer worked, but it was also an amazing blessing because it made everything way simpler.
And so without going to how it works, I'll explain the outcome.
So right now, you can go open a Jupyter workbook, which is an online notebook environment.
It's kind of like a playground on the web.
you can go through the Python interoperability tutorial.
And if you do that, what you'll see is you'll see the syntax looks almost exactly like Python.
So this comes to, this builds on the fact that the Python expression syntax and the C expression syntax, or sorry, the Python expression syntax and the Swift expression syntaxes are very similar.
Like you use plus in both languages to add things.
You have dot notation, you have function column notation, you have parentheses and stuff like that.
It all works roughly the same way.
But in the case of Python, it quote unquote just works.
What you do is you import the Python module and now you have full access to the entire Python ecosystem and everything works.
You don't have to do type annotations.
You don't need header files.
You don't need to go change your Python code.
It just works.
And the way that works,
You might wonder about this because Python is such a dynamic, such a unique language in its own right.
The way it works is that Swift just links in the Python interpreter.
And so when you import the Python module, the Python module in the Swift Python module just links to the Python interpreter.
And so you're literally just linking in the Python interpreter.
So now you get literally everything in Python.
You can now talk to it.
And the way Python works under the covers is that Python is a relatively... I should back out of that.
I was about to say it's a relatively simple language, and that's probably not quite true.
But it's a language that is built on top of C. And it has a C API for everything.
And so there's a C API to call a function in Python.
There's a C API to do a dot access, like x.y.
And there's C APIs for all these things.
That Python module is just using Swift's existing C interop to import all those APIs and directly call into them.
It's a very beautiful thing.
And that Swift, the Python module in Swift is only something like 1,200 lines of Swift code.
It's pretty simple.
That's bananas.
I mean, there's a similar language you could do this for.
Could you make Swift interoperate with PHP just for me?
So let's talk about how this works.
So now the way this works is if you go look at that Python module, and again, it's just Swift code, so you can go take a look at it.
What you'll see is you'll see a bunch of weird boilerplate stuff that is...
there to make things work.
But at the end of the day, just calls in the C APIs.
So now, how do you provide the feel of Python code in Swift?
Well, Swift has already a fairly hackable syntax.
So you have like plus, you can override plus.
You have the ability to define new operators and things like that if you want, but you actually don't really need that because Python operators and Swift operators are roughly the same, or Swift has a superset.
But there's big problems when you start to save function calls.
And so as of Swift two and a half years ago, you didn't have a notion of a callable type.
You couldn't say, I have a value and I want the function call operator on that value to work.
That's not a thing.
Function call at the time meant either call function or call method or initialize a type.
But that was not a user extensible part of the language.
And so when starting to talk through this, you know, had many conversations with people and said, okay, well, how do we do...
Python interoperability.
We talked through, and this included with the Swift core team at the time, like, what are the best ways of doing this?
And people generally all agreed that doing a Python feature was a bad move.
We should not do that.
It turns out there are lots of dynamic languages.
There's Ruby out there.
There's PHP.
There's JavaScript.
There's lots of interesting dynamic languages out there.
And we didn't want to have, you know, a Python feature.
And so pulling this all back around...
If you go look at that, that is what led to a couple of very specific features being added to Swift, including one that just shipped in Swift 5.2, which went out yesterday as of this recording, I think.
And these features were the dynamic callable and the dynamic member lookup features.
And what those two features do is it allows any type, and we use it for Python, but you can use it in your own Swift code now.
Any type can just overload the call operator and the member lookup operator.
The member lookup operator is the x.y kind of syntax and turn it into a method call.
And now when you do x.y on a Pythony thing, it goes and does that C function that does x.y for Python and then returns the result.
And the way this whole system bakes out, which is really beautiful, is you look at Python and people say, Python has no types.
That's a thing that many people say.
And they say Swift has types, right?
And Swift having types and Python not having types mean they're incompatible, right?
Yeah.
Well, the way I look at it and the way that I can explain it is saying Python has one type.
That one type is implicit, and so you never utter it generally in Python.
But there is a type, and Python has a little object model and has a little data representation.
And it's very beautiful and consistent in its own way internally.
And I actually have a lot of respect for the internals of how Python works.
And so when you import that into Swift, it is the Python object type.
And so there's one type in Swift that is all the Python stuff.
And it's all completely dynamic within that type.
And so if you have a Python object and you say mypythonobject.x, what that does is it fires off that C API call and it returns a new Python object.
And then you say parentheses 42 and it does a function call on that Python object.
And
What this means is you're true to Python through and through because if in Python you get some crazy runtime error, well, hey, you'll get crazy runtime error here too.
It's the same model now in your Swift code.
Now, one of the things that I didn't really anticipate but has worked out really well, and this comes back to this idea of you get beautiful designs if you build simple things that compose correctly.
is that in Python, you can have a Python array, you can have Python integers, you can have Python, all the Python things.
Well, Swift also has integers.
It also has arrays.
And so one of the really interesting things about Python interoperability when you embed it into Swift is you get, I think, perhaps the world's
most beautiful progressive typing system for Python, where you can say, hey, I have a Python dictionary of Python strings to Python arrays.
Or you can say, I have a Swift dictionary of Python strings to Python arrays.
Or you can say, I have a Swift dictionary of Swift strings to Python arrays.
And you can type
statically or dynamically as much as you want at any level because it all interoperates correctly in the same type system.
It's a really, really interesting and very beautiful thing.
And the fact that it just works kind of blows people's minds.
Now, coming back to PHP, well, so that Python module in Swift is 1,200 lines of code.
PHP has its own interpreter.
You could build exactly the same kind of a thing talking to PHP.
That's by design.
That's one of the nice things about the language features being very orthogonal.
And then the question is, how good does it feel?
I'm not a PHP expert, thankfully.
But if the basic grammar structure of PHP is similar to the basic grammar structure of Swift, it will work out really nicely.
If you were talking to Objective-C or something like that, it would be somewhat less beautiful.
But the system setup, so you could talk to small talky languages, you could talk to
many different kinds of things, and I think it's pretty cool.
See, everyone, you heard it here first.
I think most people are going to look at this proposal as like, you have a sewage treatment plan over here, and you have a nice, fresh, clean ocean over here.
Let's build a canal to connect the two.
Well, I mean, if you go back and you look at... So the Python interoperability, all the language features are in Swift now.
This is a done deal.
If you go back and you look at the...
Gosh, when was that?
That must have been December 2017-ish, something like that.
That's when we were talking about, on the Swift forums, adding dynamic member lookup to Swift.
And the threads, there are many mega threads on this, and it was hugely controversial.
And the arguments against it at the time, or one of the major arguments against it at the time, was like, hey, if you allow people to overload operator dot, which is kind of what this is,
they're going to misuse it.
And then nobody's going to be able to reason about anything because everybody will use it for all the things and they'll horribly pollute all the code base everywhere.
And you're not gonna be able to reason about anything.
Right.
I mean, can't you make that argument about almost every Swift feature?
Bingo.
That's exactly right.
And so you can, you can make that argument about any feature in any language.
You can misuse anything.
And, um, if you just use integers for everything, well, you know, that's not going to be great for your numeric code either, but you could do it theoretically.
Um,
And so I think that the feature and the argument has stood the test of time where we've had it for, I think, a couple of years now.
People have done really interesting things.
There's definitely JavaScript interoperability things for marching through JSON files that use this.
And it's enabled some really beautiful and expressive APIs.
But I haven't seen people going overboard and using it for everything.
It's kind of the same argument as, oh, my God, because you allow emojis and your identifiers, everything's going to be pile of poop, right?
Oh, so you've been looking at my code.
This is kind of like the destiny of any community built up around a language with a particular set of features, right?
So Swift was born as a language with...
uh that preferred to be to have errors uh caught at compile time rather than run time and it therefore attracted a community of people who value that as a as an attribute in their language so you come in a couple years later and say you know what what about there's some cases where you won't tell until you make the call whether there's an error and they're like wait a second
That's not what I signed up for.
I came here for a language where you couldn't do that.
When I have something dot something and the compiler says it's good, it's good, right?
If I wanted the other thing, I would go to Objective-C and be sending messages to nil.
I'm here in Swift.
I'm a fan of Swift.
I'm on the Swift forums.
And so you kind of coming down from the mountain and saying, but what if dynamic callable, but what if integration with languages that aren't like that?
And it was like, well, interoperability is fine, but don't
Yeah.
Because if you are attracted to Swift and are a super fan of Swift, you're not going to do that willy-nilly.
You're not going to say, hey, here's this cool library for doing this thing in Swift.
And by the way, everything's dynamic.
And dot means nothing.
And you can write any method after the dot and I'll dynamically create it on the fly.
People don't do that.
Or if they did that, their library wouldn't become popular.
Yeah, nobody would use it.
Yeah, so people aren't dying to do it.
And it has never been the culture of Swift.
So even though that feature exists, I don't think it's even an attractive nuisance at this point.
Yeah.
I mean, another really interesting to me objection at the time was people would say things along the lines of interoperability with Python makes sense for the machine learning community.
But if you do this, then people will just leave the code in Python and they won't ever move it to a beautiful Swift API because it will look like Python.
And that's not a Swifty design.
And this is true.
I mean, the Python integrated
If you use NumPy, which is a very popular Python library for numerical programming in Swift, it does not look like a natural Swift API.
The naming conventions and the keyword arguments get used differently and all that kind of stuff.
Sounds familiar.
Yeah, so exactly.
This is also like Objective-C, right?
Where at least if you don't do all the work to annotate your APIs, you get something that doesn't look at all like Swift.
What I said at the time, which I still believe, is two things.
One is, hey, well, interoperability is the first thing that gives you the ability to define wrappers.
And so if you want to use some yucky external code, and it's yucky for whatever reason, being able to wrap it up without having to drop to a different completely foreign universe is really useful because then you can define a Swift API that wraps the underlying thing.
The other thing is that...
Because it doesn't feel natural, people want to do that work to create those wrappers.
But when you start doing that, you start to realize, well, actually, that Python API I'm calling into is just a Python wrapper on top of C anyways, in many cases.
And so instead of wrapping the Python, maybe I should wrap the C. And again, what you allow people to do is over time, the community can
go build amazing new plotting libraries and data analysis libraries and things like this.
Um, but you just allow each individual person to make decisions that make sense to them and you're never blocked.
Like it's very pragmatic.
You can always get stuff done, but then if you have lots of spare time, you want to go design the world's best plotting library, you can do that.
And, um, and so now that feeling a natural thing actually kind of helps with that, I think.
Yeah.
This is an interesting test case, because in the case of Objective-C and Swift, you know, a lot of the similar problems, but the big difference is there was a sort of command and control structure that basically dictated Swift is a thing that we're doing.
And until you hear otherwise, this is the future.
So get on board the train and pretty soon you basically have.
no choice like you know there's there's a dictator involved in that dictator being apple like if you're going to develop for apple platforms it's going to be in swift eventually so get used to it over the course of many years and you know in the world of python and machine learning i imagine there is no dictatorial force like that so even though the same thing could happen it's certainly not going to happen with the same speed but all the same tools apply all the same techniques all the same sort of what you're saying about but it has to happen at the rate of you know cats being herded and not at the rate of
you know the dictator saying this is going to happen over the course of the next few years unless something goes terribly wrong so get on that train so it's it'll be interesting to see how how if that goes faster or slower or like if it never actually happens or if swift is just another player in a big soup of languages but uh how do you feel about not being able to just mandate it as as was possible in the apple days
Well, so we could talk about Swift for TensorFlow more in a second, but let me push back on you, John, because you're right that Apple could have done that, but they didn't.
So until Swift UI, there's never been a thing that you could only do in Swift.
Yeah, I know.
That's a multi-year plan.
Well, but even with SwiftUI, you can still build UIs without using it, and lots of people still use UIKit.
So what I'm saying is, for years, Apple did not do that.
There was no arm-twisting, thou shalt use Swift.
It was always a...
Well, so there's not arm twisting.
There's a little bit of arm grabbing.
Like at a certain point on your second year at WWDC and all the slides are in Swift.
Like that's the type of thing where it's like, you know, they control the platform and they're clearly saying like, oh, everything's available in both languages.
Like the year Swift was introduced, every slide had both Objective-C and Swift.
I'm presumably dictated from on high.
And for the years that followed, Objective-C slowly disappeared from all the slides at WWDC and Swift became the only thing.
And then pretty soon the default was Swift for a new project in Xcode.
And that's what I'm talking about.
Like, that there is a large... Yeah, I agree with you there.
A large, not-so-invisible hand pushing in one clear direction...
It wasn't like, yeah, they didn't come down and just say, we're changing this overnight.
Because you couldn't.
You had to make sure, hey, is this Swift thing going to work out?
Do people like it?
There's lots of unknowns.
But the direction has always been clear.
That's why I said, in the absence of anything else, this is going to happen.
Whether you like it or not, because there are still people like, oh, I like Objective-C better, and whatever.
But whether you like it or not, if the majority of the community does not scream bloody murder, and Swift works out fine, which it seems to, we're going to get to the point very quickly when
a couple years down the line, oh, here's a new API that you can't use from Objective-C.
And by the time that happens, it's almost a non-event.
I mean, some people grumbled about SwiftUI, but Swift had been so clearly the message from Apple for so many years that I think by this point, if you weren't on board with that change, like, I don't know if you've been beaten down by the overwhelming tide of Swift on Apple platforms, or you just got used to it, or...
learn to love it or left to go to a different platform right whereas like i said in machine learning you can have enthusiasm for swift but it's really up to the individual people as you said to say is this what i want to do do i want to make a wrapper for this do i mind that there's python in between do i find the swift thing benefits me in any way or do i just want to do it in python or do i like the swift so much that i'm gonna you know disintermediate the python and go right from swift to c for my new library and that's up to the individual and
I mean, I suppose there's a cultural influence as well.
I'm not involved in the machine learning community, but if they have big conferences and the same type of thing here is, you know, let me show a demo of this cool thing I did in machine learning.
And just so happens that all their demo and slides and code is in Swift.
That sends a message, especially if it's something cool, but it's sort of on a case by case basis up to the individuals.
Well, so I think that, I mean, to agree with you and then disagree with you, I think you're right that the machine learning community is definitely not top-down controlled.
And even if somebody were to do that, you would have a thousand people all doing different things anyways, because there isn't a lot of consistency in that universe.
But the same thing is true about server development and many other segments where Swift is, what I would say, organically growing slowly over time, right?
And so I don't think that's unique to the machine learning community.
Yeah, that's true.
We talked about Switch on the server recently.
It is very similar in that Apple is not super interested in, they don't have a server platform that they're pressing on everybody.
So it's, you know, they're not a force there.
And then it's really more like machine learning where it's up to individuals.
And even if they did, if they came out and said, we think that this is the right thing to do for server, everybody would say like, okay, cool, Apple, whatever.
I'm using my Django thing or whatever.
And there's not that, to your point, there's not that top-down single leader type of thing.
But the thing I want to push back on you again is who fundamentally has the control there?
Who has the power?
So is it Apple or is it the community?
Because Apple has pushed technologies, as you know, in the past that haven't worked out.
And so if Apple started pushing it that first year, and it was kind of a soft push, like that first year in particular was a, hey, we have a thing.
We hope you like it.
We think it's great, but let us know what you think.
And if the community...
barfed all over it and said, this is terrible, we don't want anything to do with it, well, Apple would have course corrected and changed, right?
And so I think the community and the community reaction and feedback and things like that also have a huge impact on Apple's decision-making process as well.
Yeah, I mean, there's definitely a give and take there.
But, you know, that's why I was off in the qualifiers is assuming things worked out, assuming there wasn't like just open revolt in the streets or whatever.
But, you know, it can there was definitely pushback, but there was enough promise that Apple said we're going to power through the pushback.
Because, you know, certainly when Swift was introduced and for years afterwards, there were lots of complaints from people who are very experienced with Objective-C about how Swift was inadequate for their purposes and Objective-C was better and didn't understand why we were making this change.
But there was enough promise and enough people who liked it that Apple was able to make the decision to say, we're going to keep going.
This looks like, I know there's complaints, but we're going to keep going.
And so to just power through that.
I'm sure that none of the people on this call would have those complaints early on.
No, early on.
We had complaints like that three shows ago.
We'll get to that in a minute.
One of the things I love to tell people is that
pick any technology that I know and I can both love it and hate it at the same time.
Well, that's what comes from, comes from using it.
Yeah.
Yeah, exactly.
And if you can't, then you're, you're just being religious or something.
Yeah.
Or you haven't used it long enough yet.
Yeah.
And so, so, so those are the language features in the Swift for TensorFlow project.
The, there's other pieces as well.
And so one of those is the API.
Yeah.
And so Swift for TensorFlow has a big API, and that API then wraps the TensorFlow APIs.
And saying it wraps the TensorFlow APIs doesn't do justice to how cool it is.
It probably doesn't make sense to deep dive on all this stuff, given the audience, but it's really cool stuff.
It uses, again, that really powerful and very efficient...
nature that Swift gives API developers.
The next step up then is the community aspect of it.
And one of the things I'm very happy about with the Swift for TensorFlow community is that it has attracted a lot of really interesting and really smart people that have contributed a huge amount.
And one of the things that we did at Google and continues to this day is there is a roughly weekly public video chat that you can dial into and talk to the team.
And all the episodes are recorded and you can go watch all the
the technical discussions about, uh, differentiable programming or, uh, APIs for reinforcement learning and like all, all these different things.
And they're very public.
And this has been a really great thing for engaging a community and helping build and helping learn.
And particularly in the machine learning community where there's so many different people and perspectives and talents, and there isn't obviously one right way to do it because it's not a mature, mature field.
Um, I think that was very, very helpful.
You had those video calls at Apple too, though, right?
Are you kidding me?
I am kidding.
Just imagine the difference between the two companies.
You're talking about a technology and a product that you're working on developing and that you're having routine interactions with official members of Google and members of the public talking about the technology in an open forum.
It's an alien concept to the Apple way of doing things.
Yeah.
And again, I think that Apple's moving a lot.
In particular, in the Swift world, I think it's being quite progressive.
They got a blog.
It's just like a light and day difference in terms of the significance placed on such things.
And it's just a different philosophy.
And I don't think that either is right or wrong, but it's quite different.
Yeah.
Yeah.
So the project continues today.
It's an exciting project.
Just announced their new release a week ago, two weeks ago, something like that.
And so they're making really great strides, integrating new things.
One of the challenges there is that the runtime implementation that they're building on top of the classic TensorFlow runtime is not perfectly suited for their task.
moving new technology stacks and doing cool stuff.
Anyways, if you're interested in that space, it's a very vibrant and very cool project.
And it's still, I would say, a little bit ahead of its time, but the technology pieces are falling in place now and it's going to be a very exciting 2020.
So it sounds like you were super into this stuff, but then you left to go to Sci-5.
You want to explain that?
Well, that's only the second project I did at Google.
So there's another project called MLIR.
Have you heard anything about that?
I have.
Do you want to talk about that, or is that too geeky even for John Syracuse?
I remember you being super excited about SIL back in the day.
You just love intermediary language.
This is what you love.
So here's the deal with MLR without diving too deep into it.
If you work on compilers for too long, just like if you work on anything for too long, you start pattern recognizing across different systems.
You start realizing they're all the same.
Actually, what you realize is they're 50% the same and 50% different.
But because you're building a new thing, you build a new thing from scratch.
And the 50% that's the same never gets factored across the rest of the universe.
And so that's what compilers are today.
And so if you look at...
LLVM, for example, it has what's called an intermediate representation.
It's the data structure that the entire LLVM universe works on.
It has a ton of infrastructure that's been built up across now.
LLVM turns 20 years old this year, incidentally, which is kind of scary.
But
And so LLVM has a bunch of this stuff.
Then you go look at Swift.
Swift has SIL.
SIL is its compiler representation for doing high-level language optimizations and doing ARC optimizations and that kind of stuff.
And that representation has to reinvent a huge amount of basic compiler stuff.
And you go look at machine learning compilers, you go look at TensorFlow, you go look at all these different domain-specific worlds, you look at Julia and Rust, and all these different compilers are doing the same thing over and over and over and over and over again.
And so what MLIR does is the ML stands for multi-layer.
It's also designed to be reinterpreted in many ways.
If the acronym ultimately fails itself, we can say it's Moore's Law or...
mid-level or machine learning or whatever the cool thing is of the day.
Bitcoin, wait, that doesn't work.
And so what MLIR does, it says, okay, cool, let's make it so that instead of building an instance of a compiler, we build a compiler construction toolkit.
The way MLIR works is you define in a declarative specification what your IR is, what that intermediate representation is, what the type system is, what the instructions are that go into it, things like that.
And then you get a tremendous amount of infrastructure for free for doing things like testing, location tracking, so you get debugging optimized code, something LVM has never really been great at.
You get a ton of the things, multi-threaded compilation, like all these things that are actually hard
And you have to design in from the beginning to make them really great.
And most people don't think about that.
And so when you're building a new compiler, typically, just like you're building a system, you're racing the market to get your thing to work.
You're not investing in that core infrastructure.
And so MLIR allows you to do that.
And we built and started this at Google.
It's now an open source project.
It's contributed back to LLVM, so it's now an official LLVM subproject.
And one of the cool things about MLR is it's only 18 months old-ish at this point and 18 months-ish from the first white paper.
And it's already being pervasively adopted across the industry by all the big companies for lots of different things.
And it's been just an incredible growth.
And it's just really cool to see that happen.
Interesting you described it as a compiler construction toolkit.
Wasn't that basically the pitch for LLVM back in the day in a very different world, but similar idea, a bunch of libraries you can use to build a compiler?
Yeah, so the difference with LLVM is, I think, fairly big.
So I love LLVM.
Please don't misread any bad things I say about LLVM as me disliking LLVM.
LLVM is really the LLVM IR, what people think about when they talk about the core LLVM.
LLVM is a really good way to talk to CPUs.
The basic model of LLVM is C with vectors, roughly.
And so if you have a problem that looks like C with vectors, LLVM is a really good solution because you can use a large number of code generators for...
all the different popular processors and things like this.
And you could build really cool high leverage settings on top of that.
LLVM has not been very successful when you talk to accelerators.
LLVM has also been completely useless for high level language things.
It was never designed to do that.
And so the difference between MLIR and LLVM is that MLIR is designed to solve all the world's problems.
And in fact, LLVM is an instance within MLIR.
MLIR also models LLVM as well as many other things.
Are you holding out one more letter?
So you've got LLVM, what was that, low-level virtual machine or whatever, ML, which is like mid-level.
And I guess the HL is like languages like Swift.
Do we have room for one more letter in there?
I don't know.
I'm pretty good at four-letter technologies.
Okay.
We are sponsored this week by Jamf Now.
Jamf Now makes it easy to set up, manage, and secure your Apple devices.
Jamf Now is mobile device management security that helps you sleep better at night.
From enforcing passcodes and encryption to remotely locking or wiping a device, Jamf Now ensures you have the MDM security settings you need so your Apple devices and the information on them is untouchable just the way you want it.
With Jamf Now, you can set passcode requirements, place a device in lost mode, even remote lock or wipe a device as needed from anywhere.
Jamf Now helps secure devices so you can focus on your business instead.
And it's super easy to use.
There is no IT experience needed.
So our listeners, you can start securing your business today by setting up your first three devices for free.
Add more starting at just $2 a month per device.
So create your free account today at jamf.com slash ATP.
That's jamf.com slash ATP.
Thank you so much to Jamf Now for sponsoring our show.
So yeah, so Google's a great place.
I had a lot of fun there.
There's a lot of really talented people.
I love that they're ambitious and willing to swing hard to do amazing things.
And so it's really great.
But due to an unfortunate incident with the free food, you were forced to leave and go to a new company.
Well, just because something is good doesn't mean it can't be better, right?
All right.
Well, so what's your sci-fi pitch?
I mean, the downsides of Google are things like it's a gigantic company with many tentacles.
Tentacles?
Well, it's got its tentacles into everything.
It's trying to be and do everything in the industry.
I think the other bigger issue is it's just kind of becoming bureaucratic like many big companies do.
And so certain aspects of that, like the performance review system, is just a nightmare.
Yeah.
Um, and so there, there's certain aspects of that.
They're just, you know, standard big company life.
And, and with, with sci-fi, the appeal is it's a much smaller company.
You know, it's, uh, it's hundreds of people and it's not an early stage startup, but it's, um, way smaller than one of the big, the big companies, but it's really got an ambitious charter of reinventing how semiconductors are made.
And so, um,
What my team does at Sci-Fi is really rethinking how people design, build processors, but also just ASICs, accelerators in general from the beginning.
And there's a tremendous number of compiler language, lots of other familiar problems, as well as a lot of very developer tool-y kinds of problems where you're trying to enable a new kind of user to be productive and be able to do things they couldn't do before.
So it's a lot of fun.
It's really exciting.
And it's also a space where the existing tools, whether they be proprietary or open source, all have different kinds of problems.
And there's a huge opportunity, or so it seems, to make the world better.
It sounds like there's a lot of synergy with the MLR stuff you were talking about.
Any kind of industry like that, especially something about building hardware, probably has a whole bunch of software tools.
But the love and attention those software tools get for this very...
narrow market is probably not very big and so people just deal with the tools that they have from a limited number of vendors that are not nearly as friendly and as polished as the tools for something a larger platform let's say yeah that's exactly right and there's also an aspect of mlr is fundamentally transformative compiler technology in my opinion and i say that having worked on a lot of compilers
There's nothing else like it, and it really opens the door to a lot of really interesting new kinds of ways to solve old problems.
And not all the tools in this chip design space are built on state-of-the-art technology.
And so there's unique opportunities when you say, hey, let's take a thing that didn't exist until 18 months ago and apply it in a new way to a field that is...
Really, really important and has a lot of smart people working in it.
And just like the TensorFlow and the Swiffer TensorFlow projects and things like that are about building tools for data scientists, here it's about building tools for chip designers.
Does MLR have an animal mascot logo thing?
It has an abstracted cuboid M. It's a geometric design.
It's not nearly as cute as the LVM Dragon.
Yeah, a giant silver dragon.
We've got to workshop the MLR thing.
You're very enthusiastic about it, but it's no dragon.
Seriously.
And, John, did you even catch that somewhere along the way the LVM Dragon got its head installed right side up?
Yes.
I have brought this up with you many times.
I'm glad to know that that was corrected.
Yes.
So, you know, there's progress being made in all fronts.
Wow.
So to come back to sci-fi, to the best you're willing and capable of saying, who is the kind of customer that you guys are courting?
And I don't necessarily mean like name Tesla or something like that.
I'm just saying, like, what kinds of more specific problems are you looking to solve?
I understand what you were saying about, you know, making chip design better and faster and whatnot.
But how does that apply to an actual thing I can hold in my hand?
Sure.
So I think that there's a difference between what Sci-5 is about and what my role in Sci-5 is.
Sci-5 as a company has a couple of different things going on.
Are you familiar with the RISC-V instruction set and that movement?
I know that it is a thing, but I don't know much more than that.
Okay, so let me give a quick dive into that.
So RISC-V, it's an instruction set like ARM or like x86 from Intel and AMD or MIPS or PowerPC.
It's like one of those kinds of things.
So if you talk about...
The others, so you talk about MIPS, XA6 ARM, PowerPC, like all these things, they're all proprietary.
And so they're all owned by a very large company and that very large company controls its destiny.
And so this control comes from multiple, in multiple ways.
So they have a roadmap and they publish new specifications and
If you ask nicely, they will listen to you and they will consider your input, but they decide what to do about it.
But the other thing about it is that they're the guardians of all the chips.
And so you either have to buy a chip from them or you have to buy a license to make a chip using their instruction set.
And so this has been a very successful model for these companies for a really long time.
Look at what Intel has done with x86, right?
And the Wintel monopoly back in the day, or look at what Arm is doing now for cell phones, for example.
But this is not really great if you want to do something really custom or if you don't want to be locked into one particular vendor.
And there are actual instances where vendors go out of business and then your instruction set and all the software built around it are stranded.
Things like, you know, HP even had an instruction set called PA...
And they eventually abandoned it with Itanium and the whole debacle around that, which really left their server users in kind of a weird spot.
And so you could argue that building your whole world on top of a single proprietary vendor leaves you tied to their destiny, right?
I think it's true for all proprietary things.
So what RISC-V is, is RISC-V came out of Berkeley.
And it was originally a group of academics that were working on RISC instruction sets.
And they were the pioneers of RISC back in the day.
And so RISC-V is the fifth incarnation of the Berkeley Research Group's design for RISC processors.
And what they did with RISC-V, which was really...
cool and interesting is they open source and opened the entire design process for the instruction set.
And so not only is it a patent free non licensed open kind of instruction set, but there are open design processes kind of like Swift evolution for the instruction set themselves.
And so, and
you too can design your own RISC-V processor and decide to add new instructions without talking to anybody if you want.
But the community also realizes that if everybody does that, well, you get huge fragmentation.
And so it's better for people to work together in a collaborative cross-industry way to define new extensions to that.
And so RISC-5 is, I think, it's still a bit early in certain ways, but it's really eating the industry in a very interesting way.
And it's this wave that's really kind of taking over things.
Now, Sci-5 was founded by the creators of RISC-5.
And so the founders of Sci-5 were from that research group.
They had designed the RISC-5 instruction set.
And so they founded the company initially around that.
And their idea was to productize and commercialize the RISC-V design, build actual processors for it.
And they've been doing that for quite some time.
RISC-V has since evolved.
And so, yes, it is...
The RISC-V company, the leading RISC-V company.
Yes, it has some amazing RISC-V CPU designs, which you can license and put them in your own chips.
But it's also what is called now an idea-to-silicon company.
And so...
They have all the functions for chip design in-house.
And so you can walk up and say, hey, I'm going to build a toaster or a microwave and I need this and this.
And it needs to be Bluetooth enabled because of course it does.
But I don't want it to be big.
So take out this and that and the other feature and the entire stack and the entire system can be completely customized to your needs.
Yeah.
If you want to own the design because you're into owning, you know, you're an ML accelerator, machine learning accelerator company and you're building your secret sauce and that's your accelerator.
But yeah, you still need RAM interfaces and like all the other standard things that go with this PCI interface and stuff like that.
Well, you can own or customize however much you want, but Sci-5 can then bring it to market for you.
Now, Sci-Fi is not unique in that respect, but what they're doing and one of the things I'm very excited about and what my team is driving is working on all the tooling, the methodology, the cloud platforms, all this stuff to make it just better, faster, cheaper, improving turnaround time, making it so the tools work together.
There's more commonality and just making that just way better than what you get out of a bunch of existing tools that are kind of cobbled together.
So it's a really exciting time.
They're really hard problems.
It's an industry that is very mature, and there's a lot of very established, very good players, and there's a lot of great tools.
But there's also, I think, a good opportunity to look at the big space and try to understand how it all fits together and come up with new ideas.
So we'll see how it goes.
It's a long-term journey.
You mentioned the open source instruction set and the fact that companies like this can exist because RISC-V is not proprietary.
So they can build products based on it and use that as a tool set if a customer comes to them so they want a thing that does whatever.
They don't have to license an instruction set from somebody.
They can use RISC-V.
It makes me think about...
apple's usual mo well they have two different mls one the more traditional one was that uh you know they come up with something themselves and it would be their thing and they would control it and they're happy with that and everyone's great but in the modern world uh apple can't invent everything themselves um so they're
you know they had two options the old one was okay well we'll use something from a third party uh and then the newer option is we'll you know a proprietary thing from a third party and the newer option is we'll use an open thing that nobody owns in particular so example of the third party one is like we're going to put cpus in our computers we'll buy them from motorola we'll buy them from ibm whatever uh and that has been a relationship that's been a little bit fraught the open source one is we're going to build a new operating system we'll build on top of bsd we'll build on top of mock right
uh we'll build our new compiler toolchain on top of llvm which is open you know all you know and even going to the extent of building some things themselves in-house either based on open source projects like webkit from khtml or saying we're going to make a new language and also that language is going to be open source even though that was from the outside touch and go until the official word that was going to be open that's a choice that they've made but still within apple there are situations where they're still in the old pattern which is
We're using a thing.
It's super important.
We don't own it.
And it's proprietary in some form.
And one example, that would be the ARM instruction set that Apple has this license for with whoever owns the ARM stuff.
Right.
And that's, you know, they make their own ARM CPUs, a whatever, blah, blah, blah.
But they don't.
Apple does not own the ARM instruction set, nor is it open source that anybody can use for free, like RISC-V.
Uh, so depending on how the risk five thing goes, and we've been talking for a while in this program about speculating transitions of the Mac to the arm platform.
And in, in our various discussions, we have brought up the idea of like, why is everyone thinking it has to be arm or why does everyone think it has to be way from x86 or whatever?
Couldn't Apple just come up with its own instruction said, what about the inertia of arm and all this other stuff?
Uh, I can imagine a future where, uh,
risk five either has the clout or apple decides to give it the you know to hitch its wagon to that star kind of like it did with khtml which did not have a lot of cloud in the web browser community before apple sort of adopted it uh but kept it open then apple could have an instruction set that is no longer at the mercy of some company that is not apple but that is nevertheless a private company and i don't think arm is going to go out of business and honestly apple could probably buy them if they really got into a pinch but i do wonder about
You know, if if the timelines are lined up differently, we could all be using iPhones with with chips inside them that run some kind of risk five instruction set.
And it wouldn't be that that different of a world.
And I bet Apple it would fit better with the current model of Apple, which is if we don't own it totally in house, it should be open.
Well, so I don't know anything about Apple's plans in the space, so I can't comment to that, obviously.
But I think there's a couple of different factors that I would weigh into this.
So Apple's big enough they could theoretically do anything, right?
And so one of the things that impresses me about Apple is that in the face of immense resources, they're still incredibly strategic, right?
Right.
And it's very this is something that I don't think Google is quite as good at is that Google tries to do everything because they can.
Right.
And that's not always great.
I think I think Google shut down that that kite based Wi-Fi thing, didn't they?
So they're they're raining it in a little bit.
Yeah, so anyways, I don't want to speak negatively about Google.
But the thing with instruction sets is that there's a huge software ecosystem that goes with that instruction set.
And so one of the things that's interesting about RISC-V is that you could look at this and say, well, the RISC-V instruction set's not that interesting, right?
And I think the people behind RISC-V would say that's the whole idea.
It should not be interesting.
It should be very straightforward to compile for and things like this.
But the point is not that the instruction set is magic in some way.
The point is that at the state of evolution that processors are at, the instruction set isn't the most interesting piece.
It's about the software that lives on top of it.
And at any point in time, somebody could go invent their own instruction set.
That does happen, particularly in grad school.
If you're an electrical engineer and you're designing a chip, you can invent your own instruction set.
But if you do that, you have no software.
Where's the web browser?
Where's all the other things that go with this?
Where's the compiler for the C compiler?
All these things.
And so the cool thing about RIS-5 here is that you can say, I'm going to design my own CPU, but I get the software.
And that, I think, is very, very interesting and cool.
Now, coming back to Apple, Apple doesn't need that.
They could invent their own thing.
They have multiple times before.
So I don't know how they weigh all these things.
But yeah, I think for the general industry, it's a pretty big factor.
We are sponsored this week by Linode, my favorite web host.
Whether you're working on a personal project or managing your enterprise's infrastructure, Linode Cloud Hosting has the pricing, support, and scale you need to take your project to the next level.
They have 11 data centers worldwide so far, and they're always adding more.
All these are filled with enterprise-grade hardware and their next-generation network to back it all up.
So Linode Cloud Hosting delivers the server performance you expect at prices that, frankly, you don't.
I've been a Linode customer myself since long before they were sponsoring, about eight or nine years now.
That's where I host my personal server for my blog and the live stream for the show.
It's also where I host all of Overcast, and that makes up about 25 servers there.
And I've been with them this entire time, and I am so happy with Linode.
They are amazing value for the money.
You get such good specs.
You look around the industry, and for the entire time I've been with them, they have been top of the line in both performance and in value.
They really are great.
I've never found anybody who can beat them consistently on value.
And so that's why I'm there, because I spend a lot of money on servers, and I get a lot for it there.
And I wouldn't get that much for my money, or I'd have to spend a lot more pretty much than ever else I've ever seen.
And they have great support if I need it.
They have great performance.
They have all these different options.
So anything you need from basic things like their wonderful $5 a month nano plan, which gives you a gig of RAM these days.
And over time, when they're able to offer more for the money, they just upgrade their plans at the same prices.
And you can just upgrade your servers with one click to the new plans.
It's incredible.
So see for yourself.
Go to linode.com slash ATP.
And when you create a new account, use promo code ATP2020 to get a $20 credit for your next project.
Linode is so great.
I highly recommend it.
If you need servers, check out Linode cloud hosting.
Once again, linode.com slash ATP, promo code ATP2020 when creating a new account to get a $20 credit.
Thank you so much to Linode for hosting all my stuff and sponsoring our show.
So Chris, you haven't been at Apple for several years now, but you are very much a veteran of WWDC.
And you have presented at several, to the best of my recollection, if not all the ones, when you were at Apple.
So as someone who has been on the big stage, the biggest stage, in fact, at WWDC, knowing now that it's gone online only, how do you feel?
feel about that do you think it's workable what would Apple do about labs like do you have any thoughts opinions anything you'd like to discuss with regard to WWDC
Yeah, again, disclaimer, I haven't been there for years and I don't know how they think about it.
But the way I think about it is I think it's actually a huge opportunity in certain ways.
So WRC as a thing has needed to evolve anyways, in my opinion, because you've got too much demand and too little supply.
The labs, if you're one of the lucky people to get the lottery tickets and you get into the labs, it's incredibly valuable.
But what about everybody else?
Yeah.
And the talks are great, but also variable depending on the day each speaker has.
And so this gives you a chance to improve the quality of the talks and maybe relieve some of the pressure on that.
Now, the question for me is, what do they do with the keynote and other things like that, which were kind of positioned as being technical content, but they're really marketing talks.
And so how does that all work?
And I'm not sure about that.
But I think that overall the event will be great.
And maybe this will force an evolution that allows labs or the replacement for labs to be more scalable to more people.
And maybe that will be a good thing.
Now, I think that the other side of this is that this whole shelter in place, people can't talk to each other, you can't go to conferences, really impacts a lot of things, including WWDC, where the community aspects of pulling people physically together and you go have a beer with each other and you see each other once a week.
So that I don't think is really replaceable.
And I would argue that in the case of WWDC, that's already being diluted anyways, just because the community is too big for the venue.
But I think that's something that as an industry, it's going to be really interesting to see what this summer or what happens with all the events.
It's really hard for people on the event planning side of things too, dealing with the uncertainty.
One of the things we've been talking about, speaking of limited resources and supply and demand, is exactly how much of Apple employees and engineers' time WWDC takes.
We're always sort of speculating, like, does
you know does not having to do a presentation on stage live in the moment with all the rehearsals and everything does that free up any engineering resources or is it more or less about the same amount of time because now they're just going to have to be standing in front of a camera pre-recording things or whatever like how would you characterize like the amount of time you you felt like it took you and your teams to prepare for wwc did you feel like you could better spend that time doing something else or did you feel like look this is stuff we have to do anyway and you know it's good that we're doing it
I think it depends on what... So again, this seems like a huge opportunity to me because the dynamic that happens with WWDC is that there are multiple things that Apple gets out of WWDC.
One of which is having that Monday morning keynote forces all the builds to converge.
Beta 1 has to happen.
And that is an incredibly valuable forcing function for engineering management.
to have a clearly defined, easy to articulate goal that everybody understands and can rally behind.
And you just don't have the ambiguity there.
Now, the bad thing about WWDC historically is that crunch time, and it is a little bit of crunch time, as you can imagine, happens exactly the same time you're preparing the technical talks.
So you're trying to, on the one hand, have...
amazing technical content that you're preparing.
On the other hand, you're trying to fix and manage the fixing of all the bugs.
And this is very difficult to juggle.
Now, if they decided to have the keynote on day X and then have the technical talks rolled out two weeks later, you could really change that dynamic.
And maybe that would be better for the sanity of everybody.
I don't think it necessarily dramatically reduces the amount of time that it would take to produce that.
The thing that you get back, I think, is the 1,000 Apple engineers or however many it is that actually attend a week of the conference.
And so you get that back.
But I think that is probably minor when you look across all of Apple's engineering efforts at this point.
So I don't know.
I think it'll be really interesting to see what they do.
And Apple's a very strategic and very smart company and has a lot of very smart people.
I'm sure they're looking at how to turn this into a new opportunity and what new things they can do with the format and how they can delight people in new ways.
If you had to put money for or against there ever being another in-person thing like WWC again, would you say for or against?
You got to put money on it.
One dollar, one dollar bet.
Well, so this comes back to your observation about Swift, which is you do a thing and then see how it works out, right?
And so I think that if they do WWC virtually this year and it sucks, then it's probably going to go physical again.
That's not how betting works.
I don't know.
I would wager that it doesn't return to its original format.
So if it does, if there is an in-person event, I think it would be significantly different than what the historical events have been.
We'll see.
So we'll see.
I don't know.
It's been funny for me because as I found out about this news, which we all kind of expected, on the one hand, I was kind of happy because I've been lucky enough to go to many of the last WWDCs and have a ticket.
But nevertheless, it is certainly way, way, way...
too little for the amount of demand that there is, as you said, Chris.
And so on the one side, for the actual event itself, I was like, oh, you know what, that's probably for the best.
But then on the other side, and this is another thing you said a minute ago, not being able to rub shoulders with not only my two co-hosts, but a lot of the people, some of whom are within Apple that I know, and some of our mutual friends that all kind of descend on San Jose that one week in June.
I'm really going to miss that quite a bit if that doesn't ever return.
And I
It is definitely a yin and yang sort of thing that I'm very curious to see what will happen in 2021, assuming we all survive until then.
But moving along.
Well, so let's flip that question around.
What opportunity does this produce for things like AltConf?
Right.
Because there are people that are interested in pulling people together and there are a lot of interesting community events.
And maybe this is an opportunity for them to benefit and for the community to self-organize in ways that Apple perhaps wasn't super great at in the first place.
Yeah, I couldn't agree more.
And I think some of the trouble is, you know, any sort of physical self-organizing isn't happening, quite obviously.
Well, not this summer.
But I think the question is, as you project forward, I'm really curious to see what the pandemic does to human culture.
I mean, I think it's a really interesting – you think about –
I don't know, pick your time frame, two years from now, three years from now, when all the dust has settled, things have gone more or less back to normal, we have reassembled the U.S.
economy and the world economy.
What's different, right?
And 9-11, just within America, had a fairly profound impact on a lot of little things across our world.
And...
This is a global event, right?
This is a global event that's a much bigger impact.
And I think it's going to be very interesting to see how this changes the way we look at things.
It could have widespread effects on how people think about in-person meetings.
You're working from home, maybe far more socially acceptable outside of software and other industries where it's been more common.
I think it could have really interesting effects on society and culture in general.
Well, no, things have really changed if Apple starts letting people work from home.
It does happen.
It does happen.
So I feel like, Chris, in the first part of our conversation, you know, talking about your past of the last three or so years.
I keep coming back to something you said to us the last time we spoke, and this is not the only time you've said it.
You said in so many words, like you want Swift to take over the world.
And I feel like in many ways, your roles at certainly Google in particular, it is you trying to get Swift to take over the world.
So three years on from when the four of us last spoke, how do you feel that goal is coming along?
Do you feel like you've made tremendous progress, not enough progress?
Where do you feel like it lies?
Well, so I think there's different ways of interpreting this because my... Let's come back to why I believe that, right?
So my goal is never to take Swift and shove it down the throats of people who don't want it, right?
My goal is for Swift to be such an amazing thing that people want to use it, okay?
And when you look at this and you look at the machine learning community...
And when I was starting there and when I was talking with people, when we were talking about this whole Python problem and things like this, and the general sentiment was everybody uses Python.
Yeah, it's not great, but everybody uses it.
The world will never change.
And I come at that and say, hey, well, the world doesn't change unless somebody steps up to change it.
This is merely hard.
Let's work backwards from this.
Let's look at all the different problems, including the migration problem and social acceptance and da, da, da, da.
interoperability, like all of these things and solve the problems.
And if you solve the problems, then you can test the social question, right?
And in the meantime, it makes Swift a better language and there's other things that you can do there.
Now,
The thing that's weird and completely human is that people generally don't like switching technologies.
And so when you look at the Swift on the server community, to just pick one that you're more familiar with maybe, there what I'm saying is that you see people that use Swift in a different part of the world and they want to bring it with them because they like Swift.
You don't see, you know, I'm a random Node.js developer and I don't know anything about Swift.
I'm just going to start using Swift on server because I want to learn a new thing.
You generally see people pull it with them.
And when you come to language design, one of the things that was really part of the idea of Swift in the first place is building one language that can scale up and down.
One system that can, you know, write...
bootloaders in, but also feel like a scripting language.
The initial Swift programming language iBook even included this in the intro, talking about this notion of scaling from systems up to scripting and being easy to teach, but very powerful at the same time.
And if you achieve this, then what you do is you build on the natural tendency that we as humans do, which is we take a thing, we get used to it, and then we want to bring it to adjacent problems.
Because very few people work on exactly one thing ever,
Usually you're working on a thing and then you're like, okay, well, now I've set up a front end.
Well, hey, this technology is nice.
If it works for me, like if all the prerequisites are there and it is actually good for that, well, I'd rather have one set of editor bindings, one set of string APIs, one set of all the things.
And so naturally what happens with languages is you get diffusion across different fields.
And so Swift, I think, is doing that.
Yeah.
Of course, diffusion takes a lot longer than that initial iOS, the iOS growth within that community.
But I'm seeing a lot of that diffusion now.
It's really exciting.
It's really great to see.
I still think there are huge missing features and missing tons of work that is left to happen.
But as that starts happening, I think it's going to be even more exciting.
you mentioned the scripting thing and uh way down uh lower in the notes i don't think we'll have to get into much detail there's the brisk project that i uh brought to your attention a little while ago um which is like a sort of a bunch of things built uh libraries i guess on top of uh swift to make it a better high level scripting language and when i see things like that i feel like it's like a
It's like a gift because, you know, so you have this language you want it to be able to scale from, you know, systems programming at the low end all the way up to high level scripting.
And you can write a Swift script and you can, you know, put a little line at the top of the file and just run it from the command line.
But there's more to a scripting language than just being able to just write in a text file and run it, quote unquote, without compiling, even though, you know, it's being compiled behind the scenes.
something like brisk is saying here are the pain points like if I want to dash off a couple line script here's why I don't use script I don't use swift because I feel this pain point doing this is awkward and doing that's awkward and so it's basically it's obviously someone who loves swift who's writing brisk like because they're trying to like Paul Hudson yeah I think so yeah like he's bringing on his you know his suitcase his tool that he likes hey I like swift sometimes I find myself having to write scripting things
I want to use the tool that I like, but the tool that I like is just not quite well suited for it in these sorts of ways.
And so you write this kind of wrapper library as a proof of concept to say, well, if Swift is more like this and more like that file would be easier and it wouldn't have to deal with this kind of errors or types or, you know, all sorts of stuff like that.
Um, and you know, if I, I'm, I haven't kept up with this, but I'm hoping that the, you know, the Swift evolution community looks at this and says, if we're interested, if some subgroup is interested in making Swift, a better scripting or high level language, um,
look at all of those the things that are in brisk and say is this a pain point can we address this pain point in a language proper because i can't imagine the solution is actually to have a series of wrappers on top of wrappers and top of wrappers if there's some problem that makes swift ill-suited to be a scripting language as compared to other quote-unquote real scripting languages it's probably best addressed at the language level but at least that's that's what my thinking is what do you think when you see a project like that
So I'm not super up to date on what is happening with Brisk.
I think when I looked at it, it's a really cool project.
One of the things I would observe here is that what Swift has done in this case is it has turned a language design problem into an API design problem.
So Paul, for example, he's not a compiler engineer.
He's an author and he's a smart, experienced Swift programmer.
He's not a compiler engineer and he's not into making language changes, nor should he have to be.
But he's able to go and tackle this problem and solve it through API design.
That's actually pretty cool.
That's one of the things that allows Swift to scale is you get people that have an area that they're interested in and they can be effective because you've now lowered the bar for solving these problems to, quote unquote, merely designing an API.
Now that API design is really hard, as I'm sure you all know, but that really shifts the balance versus saying you have to go in and hack the language or the interpreter or things like this.
Now, as far as Swift Evolution goes, there's a tremendous amount of work.
There's a recent proposal from Nate about incorporating command line argument processing and having a really beautiful API for doing that and using property wrappers and all the latest cool things to be able to make that natural expressive fluid and such.
And so there's a lot of work, I think, tackling different pieces of these things, but they're not all...
There isn't one right answer.
It's all the different pieces have to come together.
And I just love, again, this is an example of diffusion where you have...
Paul is able to say, hey, well, there's a thing I like.
Hey, I don't like it in this way for this reason, this other thing.
So I'm going to go do it.
I'm going to go solve it.
And that's where you get languages and technologies that spread and cover an ecosystem is because people are able to do that.
And you've made it so anybody or Paul can go off and solve that problem for himself versus waiting for a compiler engineer to schedule time in their day to go care about the thing that he cares about.
Swift has always had that kind of like with the standard library being written in Swift, like that, you know, that int and string and all that stuff are not like, you know, like there are types that are also written in Swift.
Now, if you were to look at the standard library, it's some fairly terrifying Swift code in many cases.
And often that's because, you know, features that you wouldn't expect a regular Swift code.
programmer to use are essential to make stuff in the standard library work.
I'm not sure if that's been itself evolving over time so that the standard library starts looking more like normal Swift code and less like the craziest Swift code you've ever seen to make all the machinery work.
That definitely has been making progress.
It's still not there yet, but...
yeah i mean i guess i guess that you know so i still feel like there is that this slight discontinuity of like the standard library yeah it's in swift and hey you can send a patch to it in swift you don't have to be a compiler engineer like a you can more or less understand it and b you can actually fix it uh and you know without having to know c++ or any of those stuff um but then for things like brisk or other sort of api wrappers the command line parsing thing that is just more straightforward like library code and
no one's going to look at the command line parsing library in Swift and be terrified that it's doing weird, strange stuff because it's, you know, there's enough language features there that you can write, especially with property wrappers.
That's, you know, language feature that lets you make a quote unquote Swifty, whatever that means at any given point in time, a Swift, a Swift like API using language features to make it simpler, more elegant, fewer moving parts, a novel way to do a thing.
I mean,
property wrappers is really a lot of people go wild with some stuff like that but that's i think it's a natural sort of explosion of experimentation um but those are two separate worlds of like the standard library which is still a little bit intimidating but very super important and then i don't know what you call it is there a name for the things that aren't part of the standard library but you know so so let me let me pull this back together because you have a really important point right which is
So one of the original design points of Swift that has worked really well is it has this idea of progressive disclosure of complexity.
So you can make Hello World be one line of code.
It looks just like Python, right?
And then you can introduce functions.
You can introduce classes.
You can introduce variables and control flow.
You can introduce each of these things as you go.
And what Swift does is it is really designed.
It has a lot of design effort put into it.
This is one of the focuses and one of the huge contributions that Swift evolution brings.
in terms of really obsessing about the details of how things work and how they look and how they feel.
Now, that doesn't mean that Swift is a simple language.
And so Swift, on the one hand, is factored really well, I would say.
And so this progressive disclosure of complexity is a big piece.
So it's not like C++, where every mistake of the past is thrust in your face when you do simple things.
But on the other hand, it does have tremendous depth.
And so property wrappers are one of these super powerful features where, you know, you don't have to be an app developer and know what a property wrapper is, but as a library designer, you can now achieve a very fluid and expressive API because you're using this feature.
Coming back to the Python interop, same deal, right?
The people using the Python interoperability don't know how the library is implemented.
It's implemented in pure Swift.
It uses some
some cool features that are fairly esoteric, like the dynamic member lookup feature, right, which normal application developers have never used.
But the fact that you have one contiguous system where you can scale up and scale down is, I think, really powerful.
this goes all the way down to the standard library.
Now the standard library, it's, it's hardcore using every crazy feature because people care about performance and there's a lot of low level things going on in certain parts of it.
But if you go look at like the array APIs and things like this, or you look at the collection APIs and,
They're all fairly reasonable, very simple Swift code.
And that you can see in your own applications by just adding an extension to string or an extension to an array, and now you can just write normal code.
And that's basically what the code you'd see in the standard library is.
And so I think that is one of the things that is fairly unique about Swift is that because it's trying to span this big gap, both in terms of
domains of application, but also in terms of user, like, I don't know if sophistication is the right word, but the level of craziness of the individual programmer.
And because you can support that all in one system, you end up with this really interesting world where you don't hit a ceiling, right?
In Swift, if you get to the thing where arc is a problem for you, you can drop down to unsafe pointers.
And you can bang out what is effectively C code to go manipulate bits and push around pointers in a completely C-like way.
And it's complicated, but you can do it.
And the fact that you can do that in one system versus having to swap out, I think, is quite powerful and very different.
I think we asked the same question the last time we talked, and we'll see if we've made any progress in three years.
But it's the idea of Swift self-hosting, having Swift compiler written in Swift, and the natural extension of exactly what you're talking about, that Swift all the way down.
Are we any closer to that, or does that still remain not an area of active development?
We are making some progress on that.
So I think the very tip of the iceberg, there's a project by Doug Greger who is working on rewriting the driver, the command line interface to Swift.
He's writing that in Swift.
And I don't know the exact status of that, but I think that's underway.
Hilariously, like MLIR actually helps with this.
The whole sill layer could be switched over to MLIR and then you don't have to worry about that.
It's actually doing that would make Swift itself a better compiler.
I don't know that anybody's signing up to do that work.
There's a lot of different ways to do that.
It has not started in RIS, though, and that's a sad thing.
Now, there are features in Swift that are still missing, and I think that getting some of those would lead to a better compiler root in Swift.
One of the ones I'd make a shout-out for is there's a longstanding proposal that is making slow steps at every release towards building what's called an ownership model into Swift.
And ownership in this case, there are languages like Rust that allow you to use types to control how your memory gets owned and managed.
And so Rust doesn't have something like Arc, where you have dynamic memory management with reference counting.
It's all static, and it's all driven by putting tons and tons of annotations in your code.
um rust is a great language incidentally also builds on top of lvm uh and so it's it's like i'm a fan of rust but the the feeling of rust is you have to think about memory management all the time like that's part of the way you program it uh swift on the other hand is coming in from a different angle of like you don't want to have to think about memory management until you do right and so with arc
Arc allows you to more or less ignore memory management until you get to cycles, roughly, right?
Or until you get to performance.
And the Swift compiler and the stack and all the design decisions have worked really hard to make it so that you get really good performance out of the box.
But when you run up into a cliff, a performance cliff with Arc in Swift, for example, your option today is you drop down to unsafe pointers and you start writing effectively C code to deal with it.
What ownership in Swift does is it allows you to write safe code, but it gives you the ability to add new annotations into your source code to say this is owned, this is borrowed, and pass around these ownership modifiers in your code, giving you a new point in the space where instead of having to choose between safe but less performant and unsafe but as fast as you want to go, you now can say it's safe and there's extra annotations in your code.
And so, again, progressive disclosure of complexity.
This is not everybody's cup of tea, for sure.
But for people who value safety and are willing to do the extra type annotations, that really completes the triangle of this design space.
And I'm very much looking forward to that.
This is like the flip side of the brisk thing, only at the other end of the spectrum, low-level stuff.
Why isn't the kernel written in Swift?
Why aren't the low-level stuff written in Swift?
Speaking of, I assume, somewhat related topic, I recently watched, I don't know why this came across my transom, it's from the 2019 LLVM Developers Conference, the talk on ownership SSA, which is more at a compiler level to...
efficiently and correctly essentially implement ARC, as far as I can tell, with the ownership model.
But what you're talking about is a proposal where in your actual Swift code, you'd annotate ownership information, right?
That's exactly right.
So it's a language feature.
It's not a compiler internal implementation detail.
And I mean, the way I look at Rust is Rust is coming from this world of its base assumption is that everybody should think about memory management more or less all the time.
And so with that worldview, it being, I mean, you encounter ownership in Rust on the first page of most tutorials because you need to think about ownership to deal with strings.
And so if you want to print Hello World, you have to tell the compiler how to manage that string.
And so what the Swift approach is doing is saying, like, this is really powerful for the people that care about performance, but you should be able to just care about performance in the standard library and have everybody that uses the standard library or your other high-performance library.
You can care about it in that domain, but then all the clients get the benefit of it.
And you get more modularity out of that.
And you, again, get...
the ability to think about this as a performance optimization instead of the programming model that everybody must use to understand and work with your system and language and code.
So I'm really excited about that.
Somewhere between these two extremes, I'll get regular expressions someday, right?
Oh, man, you're killing me.
I'm so sad.
Someday it will be so beautiful.
But again, this is a... So all of these things come into the reality that's easy to forget, which is that Swift is only...
five years old five and a half years old now at this point from the announcement and so it's still it's still quite early days and by the time swift is 10 and it's all figured out and starts getting stodgy and old and doesn't people start complaining about no and doesn't move and isn't exciting anymore well that's when you know it's successful do you think it will be all figured out by the time it's 10 uh 10 years old yeah um
Well, so it depends on what you mean by all figured out.
I mean, I think that my hope is that by the time it's 10 years old, it's more of a library design problem than a language design problem.
I don't think that continuing to shove new language features in on an ongoing basis is a good thing.
I mean, I don't know if you're aware, but C++ 20 is coming and it has lots and lots of exciting new additions to C++.
That's a black hole for language features, C++.
Yes.
Yeah.
And I mean, there's some good things there, but there's also a lot of complexity and it's unclear exactly where that goes.
The committee is working on C++ 23 features, which are also there.
Let's just say the rate of addition is outpacing the rate of removal by
Nearly infinity.
It's like C++ is a denial of service attack on other languages.
You can't compete because you have to maintain C++ compatibility in your compiler infrastructure.
And just keeping up with the C++ features is so much effort that you don't have time to make your own languages.
You found time, but still.
I think there's a reasonable question, which is...
Clang C++ was barely possible back in 2010, right?
Is something like Clang C++, is a from scratch re-implementation of C++ possible today?
Well, I don't know because the language is a lot more complicated now than it was back then.
And, you know, anything's possible.
Humans are amazing and humanity is amazing and can achieve...
uh unpredictable things but but it's it's just way harder and there are so i'm i'm not i don't follow the c++ community and the standards and things like this but there are reasonable people who are super smart and whose identities are very much tied to the c++ community they're really um unhappy with the progression of c++ and feel like the
you know, it's kind of jumped the shark and they're taking more things than they really should take and they're not baking it long enough.
And that's also, if that's true, because again, I don't follow that closely, but if that's true, that's also very concerning because language design is hard and the decisions you make, you're stuck with almost forever.
And so I hope that they don't do that.
Yeah.
Until then, everybody can just argue about what the tasteful subset is.
Yeah, that's what we've been talking about in this show on and off through various Swift malcontents who will not be named.
Whether the same thing you just described for C2L Plus is actually true of Swift in some ways.
Oh, is it taking on things, more language features than it should?
Is it taking on things that aren't fully baked?
Is it changing too much?
I mean, I don't know if Casey, you want to chime in and try to give a summary of our ongoing debate and pithy characterization of some of our complaints about Swift.
Oh, sure.
Leave it to me.
I see how it is.
For the record, I love Swift.
No, no preface.
Go ahead.
Okay, here it is.
Make it brutal.
Make it honest.
Let's talk about the real thing.
Marco should talk about it.
Come on, Marco.
Well, honestly, I'm not that qualified to talk about it because I hardly use it still.
I'm still very much in my almost entirely Objective-C code base most of the time.
I do have some Swift code in Overcast, but it's not much.
And most of the time, I'm still writing either Objective-C or Straight-C, actually.
Just recently, stuff I've been doing has been a lot of Straight-C.
But I have this characterization that Swift is a dick.
And this is, you know, an argument as old as Swift of, you know, basically being a dick versus being usable.
And, you know, if you look at, like, you know, scripting languages, usually, as you mentioned, you know, Python earlier, you know, usually, you know, untyped or dynamically typed languages are usually much more pleasant and straightforward to use, not only for beginners, but also in contexts like scripting, where even experts just don't want to deal with certain things and just kind of want the language to just, you know,
figure it out.
You have the string representation that is the string of the character one.
You try to use it as a number, it just behaves like number one.
Fine.
That kind of thing.
Swift obviously goes way the other direction and goes towards strong typing, strict typing, correctness by compiler versus runtime stuff.
Obviously this is an old argument, but it does result in overall as people learn the language and
in many ways, even as people who already know it, use the language.
Man, Swift is such a dick sometimes.
It really does feel like it.
And I wonder, like, I mean, obviously to some degree, if what you're going for is a safe and strongly typed and compiler-checked language, to some degree of that is inevitable, how do you strike that balance and
And in the case of Swift, a lot of that falls on, I think, the tooling, not being able to do things like produce good error messages.
We see this a lot with, here we are in year one of SwiftUI, and if you mess up something in SwiftUI, the error messages that you get are ridiculous and very difficult to debug.
Obviously, this is all balances, right?
Let me call it time, because you're touching on six or seven different things.
Yeah, yeah.
Fair enough.
Let's pause and then keep going.
So there's a whole bunch of different things here.
So you're right, fundamentally, that Swift is picking a point in the design space that is not designed for, quote unquote, do what I mean, is the way I would put it.
And what I would say is that dynamically typed scripting languages are really amazing when you have, I mean, in many cases, but like, for example, you have 50 lines of code or 100 lines of code.
The whole thing fits in your head.
Maybe it's a one time you're going to use it for an afternoon and then throw it away anyways.
And so, you know, for that kind of a thing, a dynamically typed language is, I would probably say better unless you're getting something out of the library ecosystem.
Yeah.
The problem with dynamically typed scripting languages is that there are certain places where it becomes a trap because programmers at large don't always differentiate between it feels good now versus it's a good idea as I look ahead.
And so one of the things I've seen is that people start writing, it's a 50-line script.
It's not that big of a deal.
And then somebody else comes and adds a few more features and then somebody adds a few more features and it gets embedded into a
a bigger framework.
And then suddenly you have a hundred thousand lines of, of Python code.
Right.
And at some point you've passed a threshold where it stops fitting in your head.
And now the scale aspect of that has kind of put you in a place where it's harder to maintain.
It's hard to evolve and reason about it.
And I'm not picking on Python here.
Pick Python.
Let's pick on JavaScript.
I don't know.
This is a general thing.
But the ecosystems have developed good testability and unit testing solutions and things like this.
But what Swift is trying to do is it's trying to allow you to have that progressive path from something small to something big without there being a point of no return or a point where you're like, gosh, I really just want to go rewrite this all because now this technology doesn't scale for me.
No.
Yeah.
To your point, that means that when you scale all the way down, it's not really optimized for that.
And I think that is true.
But coming back to the Paul Hudson framework, Brisk, the fact that you can solve these problems in a library means that
Hey, you know, if it means that you can use the same technology stack and your libraries and interact with all your model code and you just import a I'm doing some lightweight scripting kind of API stuff, you actually get a fairly contiguous world there.
And I don't know if that's a full solution, but I think it's a really interesting piece of it.
it's hardly what you're going for is to have one language that covers everything or it covers a, you know, most needs from big to small, you know, from low level to high level from, you know, more forgiving, you know, to, to very, you know, you know, rust like, uh, uh,
Is it possible to have that in one language?
Because some of what you're talking about is, as you said, it's kind of the difference between the library and the language.
In my opinion, the API and the language are inextricably tied.
And that when people...
talk about a language, use a language, describe what's good about a language, much of the time, what they're talking about are features of its standard library or features of its ecosystem that are API-based.
I completely agree.
And so those are inextricably tied together, in my opinion.
So before you add more questions and more things, it is clearly the case that you can have one language that spans all the things.
This is proven by C.
C, you can now write a web page in WebAssembly in C, and you can obviously write low-level stuff.
People have written web servers in it.
You can use C to do all these things.
Now, you made an interesting point in the clarification, which is that doesn't mean it's good for everything.
And so there's a big difference between what you can do and what it's actually good at.
And so this gets into ecosystem, design points of the library, how the language works, friendliness, all that kind of stuff.
I think the thing about Swift that is interesting and different here, and I don't know if this will work out, honestly, right?
This is all an experiment.
Nobody knows the outcome of what things will look like in 20 years.
But Swift was designed from the beginning to try to do that.
And so a lot of other languages, a lot of other systems, like let's pick on JavaScript, a language that everybody uses and many people love.
JavaScript was designed... I think there are people who love JavaScript.
Maybe not everybody, maybe not you guys.
Here I am from the PHP waste dump looking over and making fun of JavaScript.
It makes PHP look totally consistent and designed and normal.
Well, so what I was going to say about JavaScript is, like, to me, JavaScript is one of these examples where JavaScript was designed to be an on-click handler in a web page, right?
The original idea back in the day is it was rushed together in a couple of weeks to build the prototype, and they shipped the prototype, and it was designed to be this lightweight scripting language you embed in a web page, right?
You fast forward to today, and you get diffusion and communities and the way humans work, and now people are writing web servers in it, right?
And they're writing hundreds of thousands of lines of code of JavaScript.
And JavaScript was never designed to scale that way, but people will use it for that anyways because that's how humans work, right?
And so your question is, is it possible?
Well, it's definitely possible to span all the different things.
The question is, is it good?
And I think what Swift is trying to do is it's trying to be good at all those things.
Now, it can't be optimal at every point in the design space, and I think that's okay.
The question is merely, is it useful?
If you squeeze and you are good enough at a certain space, can you build a big enough community of people that care to invest, to build the APIs that really evolve and build the frameworks and get that ecosystem virtuous circle going?
And I think that's the interesting and untested question.
And after that virtuous circle goes for a few cranks, do you end up with something that's truly beautiful or is it just like, yeah, whatever, okay, you can write web pages and see, and it's good for compatibility, but nobody would actually want to do that.
So I don't know.
We'll see.
So we talked a little bit on and off about SwiftUI.
And one of the things that I found striking about SwiftUI is, as someone who had been writing Swift for, I don't know, two or three years at that point, when I saw SwiftUI and I realized, oh my God, this DSL is actually Swift, kind of, it struck me as though it is, the DSL is just stretching Swift all the way to its breaking point.
And as per the error messages up until perhaps this last release this week,
Perhaps past its breaking point.
So I don't know how much you are willing or able to comment on Swift UI, but is that too much or is that just right?
And is that what makes Swift so beautiful that it can be tweaked and bent to be a DSL in line where in a place where I would not expect it to be?
I see both sides of Swift UI.
Um, so on the positive side, Swift UI is a very beautiful, very expressive, very nice way of building things.
Um, I think that it has gone a little bit too far in the quest to like remove commas.
So the slide looks beautiful on a slide and things like this.
I don't think that that trade-off is worth it.
And, um,
I'm not sure if you are aware, but the function builders feature that is the thing that enables all the metaprogramming in SwiftUI hasn't even been standardized.
It hasn't even gone through Swift evolution.
So technically SwiftUI is not expressable in Swift.
Think about that.
Okay, yeah, I take your point.
I take your point.
Right, so now there's continuing forces that are trying to do syntactic optimization and trying to get rid of, like, little punctuation and stuff like that.
I am very concerned about that, honestly, because the way I look at it, and again, I'm just a community member at this point, but the way I look at it is that Swift...
The analogy I would make is that Swift is like a house.
And the house has a lot of bricks that are still missing.
So things like ownership, things like concurrency, things like regular expressions, John.
These are big bricks that have fairly big impact on the language.
We know we want to build them.
There's actually very progressed white papers that explain how they should fit together.
But you need to build those.
You need to fit them together.
And if you start dumping in syntactic sugar too early...
You end up with a house that you put in all this mortar.
You add mortar in between that you normally fill in between the bricks, but now you can't fit the bricks in because you've taken syntactic space and you added language complexity.
Or when the brick falls in, you decide, oh, wow, there's a better way of achieving that syntactic thing in the first place.
And so I hope that the Swift community in general really stays focused on the key technologies that we need to build and land and make sure those are really good.
And I think that it would be good to resist the urge to add lots of syntactic sugar for things.
Now, SwiftUI, again, coming back to positive, it's a profoundly transformational system.
I think it's really Swift's coming of age within the Apple community, which people are taking it very seriously.
And suddenly it's like, clicking is like, wow, this is actually a really good thing.
And it's very beautiful how it works.
I mean, one of the profound things about Swift UI, which is a technical,
is SwiftUI really leverages the type system in Swift to make the diffing part of the functional reactive programming model it provides very efficient.
And so if you look at Dart and some of these other systems, they have very bespoke, very...
interesting systems for making it efficient, which are much more invasive than what Swift UI has done.
And Swift UI has just built random Swift type system.
And I think that is truly beautiful.
And I think that the team has done an amazing job at that.
But I'm a little bit concerned that Swift UI and the pressure and the visibility of that API means that there's a lot of pressure on the Swift language to take things that it might be better to wait for.
Is it unprecedented to add, I mean, I'm trying to think back in the history, like you mentioned, like the stuff that they're building on is not yet standardized in part of the language.
Did that happen at any other point during Swift evolution where there was some Apple feature that they shipped and the things that it, like imagine Apple shipped some kind of API that had property wrappers, but property wrappers hadn't landed in language proper yet.
Has that happened before?
So that has happened at WWDC, but never at the GM final release of Swift.
And so Apple has surprised and delighted people with features at WWDC, but then the team works very hard to actually push it through the standards process and then iterate and change the feature in response to feedback.
Because a lot of like Swift Evolution isn't just about allowing the community to know it's coming.
It's about making the features better based on the input from the community, because there's a lot of smart people that don't work at Apple.
And so, um, so if you guys, the first where it has actually shipped and it's an underbarred attribute, and I'm not exactly sure how that will work stuff out, but there's a lot of really good people working on this and they all want the right thing to happen.
And they're pushing really hard to, to pull things together and, um,
I would also say that SwiftUI very noticeably had bad error messages when it first launched and even in the first official release of it.
And so that motivated folks at Apple to put more engineering effort into improving error messages.
And that helps everybody.
That's a great thing that is a feature brought by SwiftUI that really has nothing to do with the framework itself.
So it's complicated.
I would say like these things, there's no like binary way to look at it.
It's just a complicated set of issues together.
Absolutely.
And I think coming back to what Marco was saying about Swift being challenging is that, you know, what I was doing, you know, Swift early on, you know, after year one of Swift being around in public was,
Even then, error messaging was rough.
And it got a lot better for vanilla Swift after that.
And then I think things settled down.
And renaming everything every other minute stopped happening after, what was it, Swift 2 or 3 or something?
Swift 3, I think.
And everything seemed to settle out and start to get a lot more consistent.
And that's when I think for me, even though I'd been writing Swift for a little while at that point, it stopped being constantly prickly and started being genuinely amazingly fun to work on.
And another thing that I find fun to make a terrible segue, you had mentioned functional reactive programming earlier.
And I'd asked you last time we spoke about RxSwift, you had said perfectly reasonably they hadn't really touched it or looked at it that much, but it looked neat.
One of the things that, at least from an outsider's perspective, SwiftUI is broad is combine, which is kind of Apple's take on RxSwift, if you'll permit me to say so.
Have you looked much at combine?
Are you familiar with it at all?
Does that rev your engine in any way, shape or form?
Or are you kind of whatever?
I don't care.
Well, so in the spirit of being evasive, SwiftUI was underway back when I was at Apple.
So I was actually quite aware of that.
I just didn't want to talk about it.
Sure, fair enough.
So I'm a little bit familiar with Combine.
I've never used it.
So I'm definitely not an expert on it.
So I'm happy to talk about aspects of it, and I can tell you some detailed piece if I happen to know it.
I mean, I just talked about Swift.
Yeah, so I mean, if you ask a specific question, I can try for a specific answer.
My specific question would be like, so that way, the combined way RxSwift, it's a different mindset.
It's kind of in a similar way to SwiftUI.
Compare SwiftUI to UIKit or AppKit.
It's a different way of conceptualizing and building
You know, solving a problem, the problem being I'm going to throw an interface on the screen, I'm going to get events and I'm going to do stuff in response to them.
And so Combine and RxSwift are yet another twist on, you know, how do you want to conceptualize the solution to this problem?
The problem is always the same.
I'm going to throw up a UI, people are going to click buttons and type stuff and I want to react to it.
I'm not sure how much GUI app development you've done, period, but, like, what do you think of the approach as – I mean, Casey could probably articulate it better, but this – I hate the name reactive, but this sort of reactive style, like, you know –
Does that fit your model?
If you had to write a GUI application, would you be thinking of it, conceptualizing it as a series of sources and syncs or publishers or whatever the hell they're called and combine an Rx?
Or would you think of it imperatively or does your mind work more like Swift UI?
How do you personally think about solutions in this problem space?
So I look at it as a programming model.
So if you look at programming models, other examples of that include imperative programming with for loops.
It includes generic programming.
It includes object-oriented programming.
I would say that machine learning is a programming paradigm.
If you're going to build a cat detector, machine learning is way better than writing for loops.
And so I would say combined is a programming paradigm that's really good at this reactive, whatever that means, programming model.
And I'd say it's actually very good for the things it's very good at.
And it's not just UIs.
Like, you think about...
you have a Unix app, like a script or a web server, like a classic old, like Apache or something like that.
Well, Apache has a bunch of logic for like registering signal handlers, right?
Unix signals that you can send out of bound, like asynchronous signals,
messages to your Unix process, like reload your configuration, things like that.
And so there's not really been a great way to model that.
The imperative ways of setting up a callback and figuring out how to go poke some things and then, oh, well, what if I'm interrupting the current thread?
I need to set up queues so I can push data around and I have to handle synchronization.
All that stuff was really grody before.
And I think reactive techniques are a really good way of modeling that because it's really embracing
This notion of you have events and at that event based programming, I think really is great for certainly for UIs.
It's great for like edge casey things like signal handlers and it's good for network servers sometimes, depending on what you're doing.
And so I think it's really great that you can do that.
And I also think it's great that you can have that sit next to UIKit.
You can have it sit next to generic programming.
You can have it sitting next to machine learning.
You can have it sitting next to all these different things.
And then you can provide one system that allows you to pick the right solution off the shelf to solve your problem.
It's not saying there is only one way to do it and you have to do it this way.
You can have a diversity of thought and APIs and you can have different communities that all interoperate and work together in a common framework.
Hopefully not too much diversity.
I hope this settles down, at least in the Apple space.
I hope this settles down to something.
Because I think we're, you know, this Swift transition, we just talked about it earlier, like, you know, Objective-C and Swift live together and will continue to live together for a long time.
But there's a gradient and we're going through a transition.
There's no expectation that in 50 years there will be the community will be 50% Objective-C and 50% Swift.
Like, you know, we'll...
I don't know what the Apple API story will look like this year at WWDC.
I think it's really interesting to think about that because until last summer, they didn't have, or technically the spring before that, but until last summer, they didn't have ABI stability.
So they could not have large scale APIs written in Swift.
And then finally, this lands, you have SwiftUI, combine a bunch of other, the ARKit framework, you have a bunch of really cool frameworks that are now written in a Swift first, really natural to that environment, you know, design point, right?
I mean, a Swift API is very different than an Object C API, even if you put all the annotations on it.
Now, this will be the second year they do that.
And I don't know about you, but I've noticed that sometimes Apple puts its toe in gently into the water in the first time.
And the second time, they dump a lot more energy into it.
And the third time, if it's working, they put all their weight behind it.
And so I think it'll be interesting to see what the APIs look like in general, WWDC this year.
I really have no way to predict that, but I would not expect Apple to stand still here.
Swift UI always felt kind of like Swift 1.0 to me, in that it was very super new.
You haven't seen anything like this before.
It's not your mother's UI kit, right?
It's solving similar problems, but in a totally different way.
But it's kind of weird and creaky, and it's a 1.0, and we're not really super sure about it, and we're excited about it, but there's also Catalyst and a bunch of other stuff, and yeah, whatever.
And the second year is when you see...
how did SwiftUI work?
How did it work out?
Have we formalized those guts?
Are we going to improve it in a big way?
Or is it going to take two or three years?
Swift had a couple years of tentative toe-dipping in terms of technological churn, but the direction was clear.
But I feel like right now, you've got the established UI kit and the older app kit, and then the new kit on the block SwiftUI, and that...
And Catalyst somewhere fits in between.
Nobody's not really sure where.
Right.
And so it seems like maybe there's a few too many cooks in this kitchen.
I would say Catalyst is kind of the weird one out here.
But, I mean, I think that Apple has a fairly well-established pattern of often the first version is not good enough.
And people forget that because you're used to using the products when they're mature, but you go back to the first version of the iPhone, right?
And there are some of us that immediately saw the promise and jumped on the bandwagon and said, this is the future.
But there are a lot of other people who said, what are you talking about?
It doesn't even do 3G.
There's no copy and paste.
There's no apps.
There's no like, you know, it's actually an incredible tech demo, but it wasn't really there yet.
And then the second iPhone came out and that's 3G.
And then
And then you get copy and paste and then you get retina screens and then you get, you just fast forward and now it's just like a life changing thing that you can never, you can never imagine living without a cell phone.
Right.
Um, the same thing about OS 10.
I don't know.
John was Puma, a really great release.
Um, if you go back in the day, I'll only, you can tell me the diversion number.
I'll give you the answer to that question.
I thought Puma was 10.1, wasn't it?
You got it.
Do I win a prize?
I don't remember what 10.0 was, though.
It was Cheetah, believe it or not, the most hilarious codename.
There you go.
The slowest release was named Cheetah.
Well, it was aspirational.
Yeah.
But again, like OS X grew to be an amazing, amazing product and an amazing platform.
And a lot of what Apple is great at is recognizing that the first version has to have enough to get the community to understand it and enough to build that momentum.
And then recognizing when it's working and dumping, dumping gasoline on the fire versus recognizing that, okay, well, we have a dumpster.
We just put gasoline in it.
This is not a good thing.
It's on fire.
Yeah.
right and apple doesn't have many mistakes but it does have products that are not successful and people generally forget about those instead of uh instead of dwelling on them that's going to be the bucket catalyst ends in by the way well yeah i don't know i mean like like i feel like catalyst is just uh you know a sidekick to ui kit and the real battle is ui kit versus swift ui right now swift ui is weird and new and
half broken and strange but it's definitely the you know the shiny new kid on the block so you know i don't know if it's like it's a swift one but now if you were if you were to put money ask some stranger what do you think of this swift thing you had to put money on is swift gonna hit big or is it gonna be a disaster it's hard to tell because apple done a lot of weird things with languages before and you know it's gone a bunch of different ways and it was swift ui
it's it's definitely different i see a lot of promise there um i see a path from where it is now to being a completely appraisal for ui kit but it's a long path because ui kit got to build not build on app kit but got to build on the wisdom learned from making app kit and app kit itself has a tremendous amount of you know experience and wisdom built into that api uh so there's quite a pedigree in in ui kit and catalyst is just like
UI kid in a fancy outfit in a different platform.
I think they're functionally very different kinds of technologies.
Like one is trying to change the model and one is trying to broaden the model, I guess.
Yeah, let people use the skills they already have on a different platform.
right and those are really different goals and I don't know how that will work out either but one of the things that people don't realize though is that when Swift was like you talk about you know Apple put a lot of energy into Swift and clearly there's a there's a committed plan to making Swift take over the Apple ecosystem one of the things that's not well known is that even the week before the WWC launched there were very very senior very smart people that were very dubious about Swift right and
And for rational reasons, I mean, the thought process went, and you have to understand, so the thought process went, the iPhone is successful because of Objective-C, right?
And literally everybody in the iOS ecosystem, also the Mac, writes their apps in Objective-C, right?
So now we're looking at adding a new technology, new language to this world.
And these are people, the execs in question, grew up writing Objective-C code, right?
So they're not coming in from the world of...
we have a good sense of what the average programmers on the wild do.
They're, they're people that have spent many, many years thinking about and, and thinking in objective C. And they look, they looked at this upstart Swift thing and saying, well, there's a huge risk that this will cal like cleave the community in half.
And we may end up having two different sub communities within our ecosystem.
And that, that actually would be a very big problem.
And, you know, I think that there's an aspect of that that was true, but, um,
You know, the Objective-C strongholds are diminishing over time, and apparently Apple's feeling confident enough with Swift that they'll introduce Swift-only APIs.
And so I guess it's worked out well.
But early on, it was not clear, right?
I mean, very reasonable, very smart, very strategic people had very real concerns, and it's very hard to predict that.
Yeah, and doing a public announcement.
If I was one of those people, the thing you could bring up is like, look, we were in a similar situation with Insert Technology X, whether it's Objective-C Garbage Collection or even ZFS for that matter.
Once we publicly announce it or ship it and have to support it, look how long it took us to get rid of Objective-C Garbage Collection because if you ship it and people use it, then you have to support it and it's terrible and you eventually learn that it's not the thing.
And so I can imagine the argument was, look, if Swift's going to be the thing, maybe bake it a little bit longer and
make us more confident internally that we think it's going to work out because if we do actually release it and let people ship with it, even if we decide, oh, well, we made a terrible mistake, we're still stuck with it for however many years and it's really a drain.
Yeah.
Well, and that was one of the things that I...
I have a lot of respect for Apple and Apple's ability to make bold decisions, but that was really non-obvious and they were able to make a leap, even though Swift 1 was really not that great.
Swift 1 was very early.
You could call it a tech demo for sure, and they're still willing to make a bold decision.
leap, partially because they believed in the engineering team and they believed in the promise of moving the world forward.
And they really wanted to be the head driving technology in that way.
And I think that's really great.
And it has worked out over time.
But that's both that the ideas were good, I think, but also that it was allowed to iterate.
And one of the things that relieved a lot of pressure from those discussions is we said, hey, you know, we're going to do a controversial thing.
We're going to say we have a new language and you can build and submit apps to the store when it has its final release in the fall.
But we're going to change it and we're going to tell developers that we will change it.
And the reason for this is that we cannot, even though we think we're smart, we cannot make something that is perfect without having feedback.
Right.
And by the time Swift was announced, only something like 250 or 300 people in the world knew about it.
And you can't make something that's really great if it's in that kind of a silo.
And so that ability that we had to really iterate and change the language, even though it was super painful, I think led to the language being way better.
It also led to it being way more comfortable for Apple to take that risk because it didn't have to be perfect on day one.
You should have shipped that one with tuple arguments to functions.
That would have been cool.
I mean, if you go back in the history of Swift, there's so many terrible ideas.
I'm very happy that the most terrible ideas have been ripped out and we're left with only some of the unfortunate ones.
So you had brought up earlier ABI stability and how that has recently landed.
And out of curiosity, what do you see as the biggest things that are possible now that weren't before that line in the sand?
I mean, there's obvious answers, and maybe that's to you the biggest and most important answer.
But is there anything that's perhaps more esoteric or interesting or unique that you think is now on the table that wasn't before ABI stability?
So I look at ABI stability.
ABI stability itself is one of these funny things where it's very important to Apple, but almost nobody else should care.
Right.
Or you care as an app developer because you don't have to link the library into your code and so your app is smaller, right?
But you otherwise don't care.
It's also an insanely complicated feature, right?
It's also something that many of the languages don't ever even get.
So if you take other languages like Rust, for example, it's a great language.
They've never fought with this.
And it's really hard.
And doing this well is really hard and has a lot of really innovative aspects to it.
But I look ahead and so I look at that as kind of this table stakes thing that you have to get done that's just really hard.
And so until that was done, Apple's engineering team and design effort couldn't work on some of the more exciting, bigger, impactful things.
But when I look at it, I look at there's different kinds of features that are missing.
So to give you an example, one of these is what's called variadic generics.
So you take a generic function and you can have n arguments to your function or n generic types that go into it.
Variant generics are one of these... We were talking about this before.
It's a super esoteric, hardcore, power user, library developer type feature.
But what it enables is it enables things like tuples going into dictionary keys.
It enables... Right now with SwiftUI, they have this hilarious problem where if you have more than 10 controls in your top level, it doesn't work or something.
And so you have...
A lot of these rough edges that get shaved off by having this really esoteric feature that only hardcore library developers will use because those hardcore library developers are the ones building these APIs.
And so that's something that's also, I think it's kind of conceptually well-known, but it's a lot of engineering work.
And so I would love to see something like that just for all the rough edges that will go away when that happens.
There are other features like concurrency.
So async await is frequently requested, will be way better for UI development, for server development, for just like anybody that's doing asynchronous programming.
Again, it's all pretty well understood.
There's a few implementation details that need to be sorted out, but that would be amazing.
They've published a Swift 6 roadmap, and I think that's one of the things on the short list, which I think would be great.
The ownership thing we talked about is something that would really help with systems programming and places where you really want both safety and performance.
And those are, I think, the big ones.
And I mean, the big language features that I can think of.
The libraries then are the big missing piece.
And so the fact that here we are in 2020 and there's no command line option processing library yet is kind of hilarious, right?
The same is true of many different things.
I'm also really curious to see what the community does when you talk about foundation and things like this, where foundation is both a great blessing and a curse, where it was really great for bootstrapping the Swift on server and many other communities, but it also just doesn't feel very naturally like a Swift API even today.
So I don't know.
I mean, there's a lot of really exciting things that I'm sure will happen and come as well as many, many smaller kinds of features as well.
And I think what I'm more concerned about is that we do things the right way and really consider and debate and think about how they fit together and make sure that the consequence of what we get in 10 years or something is really beautiful and still feels really good.
It's not an amalgamation of different things that are thrown together.
I think that Swift evolution is a really good
I wouldn't say controlling function, but it's a really good feedback loop that encourages good iteration.
I'm just picturing some function in the guts of SwiftUI that has like 10 arguments named A1, A2, A3, A4, A5, and that's powering the whole thing because it can't be veridetic.
That's exactly what it is.
And it's overloaded functions, one that takes one, one that takes two, one that takes three.
Yeah.
The limit shouldn't be like 10, right?
I don't know what the limit is or how many arguments you can have in a Swift function, but I would think it would be bigger than 10.
They know about copy and paste, right?
I don't know the secret sauce internally, but they pick some limit and they went up to that size.
Similarly, in Swift, just the base language, you can use equals equals on tuples, and it works up to six elements.
Yeah.
because copy and paste does that have a good compiler error message when you exceed it I'm sure it does not right but you know it covers the most important part of the problem and it's good enough but it's just still a bit unsatisfying and it should be a simple thing that is orthogonal to everything else and you just
you're done and they move on.
This, this again is what I mean by there's like a brick that's missing.
And if you start like papering, papering around the corners and you start adding special case things that like work around the lack of that brick, it's just way better to go build the brick and drop it in and then get rid of all the, the workarounds and all the other technical debt that metastasizes around the edges to, to deal with the lack of that big missing thing.
I mean, even PHP has that.
Yeah.
So Chris, you've been extremely generous with your time.
Just a couple of quickie, hopefully easy ones for you, if you don't mind.
You had talked when we had spoken three years ago that you almost never get to write actual Swift.
And obviously your world has changed quite a bit since then.
Are you ever writing Swift these days?
Yeah, so I actually do.
I still have not written a large Swift application that's 100,000 lines of code, but I do actually use it for certain things I don't really want to talk about right now.
Yeah, totally.
I was just curious if are you using it at all or not?
Because it was so funny to me and sad that you didn't get to really receive the fruits of your labor.
Yeah, I still live in that sadness.
And I still write way more C++ code than I should.
But maybe there's a day that will change.
Do you, when you are writing Swift, ever run into a situation where you're like, damn it, I wish it didn't do this, or it's being such a dick?
All the time.
And so to me, it's all those sharp edges that...
um, that everybody runs into for me, it's like, Oh, I really want to go fix that, but I can't because I haven't, you know, it's right.
It's very different.
And similarly, it's the same thing when I work with LLVM LLVM, I know all the bad things about LLVM better than anybody else does.
Right.
And so people, a lot of people are like, Oh yeah, LLVM is really great.
I'm like, yeah, it's, it's, it's okay.
It's better than the alternatives, but it should be way better than it is.
And let's not set our sights on good.
Let's aim for great, you know,
And same thing for Clang.
Why can't you do high-level optimizations in Clang?
It's very sad that you can't do ARC optimizations for the smart pointer class in C++.
And that's an implementation detail issue that should totally be fixed.
I've argued that this should be fixed, but I don't have time to go do it myself.
So it's really tilting at windmills, hoping that somebody else will care about fixing the problem that's really apparent to me, but isn't really apparent to everybody else.
And this is the problem with working on large scale things.
You had mentioned earlier that this is, I think, the last one that certainly I had had for you.
You had mentioned earlier you had made a package shed.
I know nothing, literally nothing about woodworking, but I know that that's something that's important to you in a hobby of yours.
What other things or would you like to share more about the package shed?
What have you been doing woodworking wise these days?
I haven't had a lot of time to do woodworking lately just because I've been super busy and jumping between different things.
But there's different aspects of woodworking that I like.
The thing that I would say is I'm really good at building one of something because I like the process of design and exploration, understanding something, figuring out the, okay, I'm going to build a table.
Well, how high?
Why?
What is the bracing structure underneath it so you don't bump your knees?
centuries or many, maybe millennia, but I don't know any of these things.
Right.
And there's actual principles that underlie all this and there's better and worse and kind of working through all that's a lot of fun because it's a, it's an amazing problem solving thing.
Uh, I would be terrible at building a dining room full of chairs.
Like I would get the first one figured out and that turns into, uh, you know, a manual process of just like doing
fabricating things and i would not be into that at all um but i really love the problem solving the exploration side of that and so lately i've been pretty busy built a little treasure box for my son uh that you can see on twitter if you're interested um it was mainly odds and ends here and there so if you do the chairs you should do the first chair is like chair one like swift one and the second chair looks totally different it's chair two
There you go.
No, no.
First you have to build a chair design factory toolkit.
I think he's already got that.
So here you run into logistical problems like I'm not the only decision maker in the household.
That's where you have the chair evolution process.
Yes, exactly.
I may not even be the most influential decision maker in the house.
Thanks to our sponsors this week, Linode, Jamf Now, and Indeed.
And we will talk to you next week.
Now the show is over.
They didn't even mean to begin.
Because it was accidental.
Accidental.
Oh, it was accidental.
Accidental.
John didn't do any research.
Marco and Casey wouldn't let him because it was accidental.
It was accidental.
And you can find the show notes at ATP.FM.
And if you're into Twitter, you can follow them at C-A-S-E-Y-L-I-S-S.
So that's Casey Liss, M-A-R-C-O-A-R-M-N-T, Marco Arment, S-I-R-A-C-U-S-A, Syracuse.
It's accidental, they didn't mean.
Accidental Tech Podcast So long
So are you guys doing anything from working at home or schooling at home besides playing Minecraft all day?
Because that's mostly what we're doing here.
I think this is the wrong group to be talking about working from home because it consists of two people who always work from home.
And yes, it's different because your family's there or whatever, but maybe not that much different.
And the third person, me, also works from home a lot despite having a regular office job.
So...
I think life has changed a lot less for us than it has for most people.
But it's definitely felt different, even if we're supposedly doing the same thing, sitting in front of the same computers, doing the same type of work, or in Marco's case, not doing the same type of work.
Everybody's...
everybody's here right i mean kid the kids don't leave during the day for any reason and so they're all just here yeah that is critical though like i i literally i i'm getting almost no work done and it's it's you know in in some ways it's my own choice but the main differentiating factor is our kids are all at home you know because the schools are closed for the virus and
I mean, they're going to be they've already been closed for over a week.
There's probably going to be another couple of weeks at least.
That totally changes our day here to the point where, you know, and especially like, you know, we have one kid.
There's no one else for him to play with.
He's not going to school.
All of his out of school activities have been canceled.
He can't go to his friends houses.
what's he gonna do he hasn't he has nothing to do he's in second grade the school work you know he we do have like you know worksheets and stuff that the school puts up in google classroom which is like i mean this is a whole discussion here about like man i feel bad for teachers so often um i know a lot of teachers and it's it's not it's never like a super easy or well-respected job by by our society but
In this particular case, it really shows you quite how important teachers are because, first of all, teachers have all been forced to all of a sudden throw their entire curriculum somehow online, which doesn't work for a lot of stuff and is totally different.
And we're all trying to be teachers ourselves at home.
who've never done this before and it's really hard and we're doing a terrible job largely as like as a people because it's a hard job and we're not trained for it and we have no experience with it and like it really you know one of the hardest jobs in or one of the hardest things about being a teacher is that everyone thinks they know your job better than you do and in this case it that could never be more clear as it is right now but like for us like
you know, because our kid is home all day and has no one else to play with and can't really do anything, I can either, like, you know, sit him in front of the TV for seven hours a day or we can play with him.
And so, we're playing with him.
And, like...
I don't feel bad about that for the most part.
I do feel bad that I am in many ways neglecting my business like that.
That is no question.
I am like I see like, you know, Casey's like pumping out a new build of peak of you almost every day somehow.
And that makes me feel bad because I'm getting no overcast work done.
I'm answering emails as best as I can.
I'm keeping up with urgent business matters as best as I can, but I'm getting no programming done.
Because during the entire part of the day, during most of the day that I'm awake,
So is my kid.
And I'm having to, you know, be a full time parent and teacher.
And, you know, I like, you know, we're running the house.
So, you know, I got to like, you know, make food and everything like, you know, occasionally shop for food, you know, just keep the house clean and running like it's hard.
And it takes up all this time.
And I'm making a decision that while my kid has no one else to play with, then I don't want him to just be watching TV.
I want to be the one to do things with him.
And at the same time, my entire family, all three of us, have developed a significant Minecraft addiction.
So this works out well.
That's all he wants to do is play Minecraft.
When we're not playing Minecraft, all he wants to do is talk about Minecraft or read about Minecraft or watch videos about Minecraft.
So it's 100% a Minecraft-obsessed time for our family, which I gather is not that rare for a nearly eight-year-old.
So it kind of works out well in that we're just kind of playing this game all day.
But I am totally neglecting my job.
But I don't really see a better choice I could make given the circumstances.
Now, really quickly, has New York not canned the entire school year yet?
No, they haven't made that call yet, but it wouldn't surprise me if they did.
But they just haven't made the call yet.
That's very surprising to me because Virginia is doing much better right now than New York is with regard to the virus.
But just earlier this week, I think it was yesterday or the day before as we record this, our governor announced that this school year is over, which is –
Really, really wild for our family because this was Declan's last year of preschool and we'll hypothetically be registering him for kindergarten next month, maybe, possibly.
But he walked out of his preschool class, you know, a week, a week and a half ago, whatever it was, and we thought he would be back in a couple of weeks, which in retrospect, even then I was kind of like, well, it'll probably be a month or two, but he'll be back at some point, right?
Yeah.
He is no longer effectively a preschool student.
It's really, really wild.
I feel terrible for like seniors in high school because, John, Alex still has one more year left.
Is that right?
Oh, God.
What the hell year is he in?
He's got two more years left.
Oh, he's got two.
Okay.
I'm sorry.
But no, it's been weird for us having Declan home all the time.
Obviously, Michaela pretty much always was.
And not bad weird.
It's been weird, weird.
And I think Aaron in particular, since the bulk of the effort has been landing on her shoulders, she's been doing a really good job of doing – not just sitting in front of the TV.
Now, I wouldn't necessarily say that she's doing instruction or anything like that.
But he's not – to your point, Marco, he's not just sitting in front of the TV, mouth agape, just staring.
Yeah.
By the way, no judgment if that's what you have to do.
I'm not saying we're not doing that ever.
I'm just saying I'm trying not to do that for like seven hours a day.
Speaking of Alex, that's what he's doing.
I mean, it's not the television, of course, because he doesn't use that primitive device.
It's Nintendo Switch and iPad.
Fair enough.
And how could you not, especially if you have two working parents?
How can you not do that?
Right.
And the thing is, the school is giving us these assignments online every day just to try to have some semblance of education, instruction, and structure and consistency for the students.
And frankly, I don't think it's much because it can't be.
It's basically homework every day.
It's like, here's a couple of worksheets and activities.
That's basically what we're calling a full school day these days.
And I can't blame – it's not the school's fault.
They're doing the only thing they can do really because they weren't prepared for it.
We don't have like an entire online curriculum for elementary school kids and I'm not even sure such a thing will be possible.
Yeah.
But anyway, so no one's prepared for this, except people who are already homeschooled, but that's not most of us.
And so we have this little bit of homework every day that we do, and we do basic exercise, and we take a dog walk in the afternoon.
And so we have some structure of the day, but for the most part, I'm not filling Adam's Day with school.
Because first of all, we don't have enough school to do that with.
But second of all,
This is a worldwide, historic, pretty heavy event.
I don't want to be the parents who, like, throughout this pretty stressful time, especially, like, you know, kids know what's going on.
They might seem like everything's fine, but they can tell we're all worried.
They can tell everything's messed up.
This is going to weigh on kids, even if it doesn't seem visible right now.
Like, they're perceiving what's going on.
I don't want to be the parent who during this time forced my kid to be doing schoolwork all day.
It's a weird time for everyone.
Pretending like everything is fine I think is both a little inhumane in certain ways if it's like forcing them to do work they don't want to do.
And also, I think it's it's ineffective that like we're not hiding anything.
They can tell they know stuff is wrong.
They know like something's up no matter how young or old they are.
Like they know like this is a big deal and it's not good.
And, you know, wherever this goes from here, we don't know where it's going to go from here.
We don't know how bad it's going to be or the economic fallout and whatever else yet.
Like we don't know all that yet, but we know it's not good.
And I think letting our kid play Minecraft all day for a few weeks is that's not a bad thing in the face of all that.
Yeah, I couldn't agree more.
And one thing, you mentioned this a moment ago, and I know you come from a family of teachers, and Aaron taught up until we had Declan.
One thing that I hope comes of this, you know, if we all make it across the other, make it to the other end, okay.
One thing I hope that comes of this absolute tragedy is that people appreciate teachers at least a little bit more.
Because here in America, anyway, you
Teachers are generally considered to be glorified babysitters by a lot of people, which is atrocious and wrong and terrible and disgusting.
But in so many communities across so many different racial and economic boundaries, it seems like teachers are just kind of babysitters.
There are teachers that are basically just glorified babysitters, but the overwhelming majority of them are trying exceptionally hard and doing so for almost no reward of any sort and typically are getting beat on for the choices they make.
It's just a thankless, thankless, awful job to take on that these people do to some degree out of the goodness of their hearts.
And it killed me watching the way Erin got treated when she taught.
And I hope that now your average parent does a better job of understanding that teaching is hard.
Teaching is a very hard job and it's important.
And at least in America, we don't value the teachers nearly as much as we should.
But to hopefully not end on a bad note and end on a happier note.
you know, we've definitely been watching more movies as a family than we usually do.
You guys are playing more Minecraft as a family than you usually do or did.
All three of us are playing.
Hops would play if he had hands.
And so, you know, I think that that togetherness, well, sometimes maybe a little too much, or at least in our family, we can get a little on edge from time to time.
But
Uh, generally speaking, the, the one silver lining from all of this is that we are getting to have some time with each other that maybe we wouldn't have had otherwise.
And I am, I am thankful for that, even though I wish it was for a different reason.
And my, in my, I mean, in my darker moments, I keep only seeing the bad side of this for me.
Like,
you know my rational mind says you i'm incredibly lucky that i have not immediately lost my job right and you know that i already did do a lot of working from home and then i'm able to do my job from home and like these are all reasons i am incredibly incredibly lucky uh but then i read about people who are just sitting at home uh you know watching movie catching up on movies and reading books and trying to relax and de-stress from the anxiety that we're all feeling and it's like
I'm doing all the same things that I always did, plus being anxious all the time.
Yeah, I couldn't agree more.
I could not agree more.
No, I don't get any kind of break, and it's the worst kind of thing.
I should just be counting my blessings.
Yeah, oh, boo-hoo, you still have your job.
Trust me, I would vastly prefer still having my job, but a tiny, tiny part of me that doesn't really make any sense says, why don't I get to sit around and read a book?
You know, that part of me is wrong and should shut up.
Well, look, the problem is this affects everyone in so many different ways.
Think about – we said we're lucky that we have jobs that we can do from home.
We're lucky that we didn't just suddenly lose all of our income and that we have stable homes and stable family lives that we're not going to all –
have significant problems by being at home for a few weeks.
Those are all some really big conditions that like most people don't have all of those.
And even for us, it's hard, right?
So yeah, it's hard for everyone.
We have the best setups that we could possibly have really like, you know, in reality, like compared to the world, like we are incredibly lucky with the setups that three of us have and the situations we're in.
But it's even hard for us.
So imagine how hard it is for everyone else.
That's why I'm saying if you want to make your kid play Minecraft or watch movies all day, that's fine.
Because if that's what they want to do, again, I do think there's some value in doing these things with them, which is why I do it.
Also, I'm going to do Minecraft right now, but that's a different story.
But I think it's totally fine.
Don't beat yourself up, parents especially.
Don't beat yourself up for all the things you're not doing.
Don't beat yourself up for all of the academic value that your kids are missing out on.
And I have to kind of tell myself to stop beating myself up for not programming almost at all during this time.
But like...
it's just it's a weird time and it's okay to not try to pretend like everything's normal and it's okay to do things differently and to let certain things be untended to for a while because things are different and you have a different workload and god i really appreciate teachers so much i did put out a few releases of switch glass too so me and casey are uh way ahead of you on the software update front
High five, John.
Well, I build an awesome house in the Minecraft server by Dubai Friday.
Oh, you are ahead of us in the Minecraft building, that's for sure.