The Changelog: Software Development, Open Source - All the places Swift will go (Interview)

Episode Date: November 16, 2023

This week we're talking about Swift with Ben Cohen, the Swift Team Manager at Apple. We caught up with Ben while at KubeCon last week. Ben takes us into the world of Swift, from Apple Native apps on iOS and macOS, to the Swift Server Workgroup for developing and deploying server side applications, to the Swift extension for VS Code, Swift as a safe C/C++ successor language, Swift on Linux and Windows, and of course what The Browser Company's Arc browser is doing to bring Arc to Windows.

This week on The Change Love, we're talking with Ben Cohen about Swift. Ben is the Swift team manager at Apple, and we caught up with Ben while at KUCon last week. Ben takes us into the world of Swift from Apple native apps on iOS and macOS to the Swift server workgroup for developing and deploying server-side applications to the Swift extension for VS Code, Swift as a safe C and C++ accessor language, Swift on Linux and Windows, and of course, what the browser company's ARC browser is doing

to bring ARC to Windows. A massive thank you to our friends and our partners at Fastly and Fly. This podcast got to you fast because super fast is Fastly. Check them out at Fastly.com and our friends at Fly will help you put your app in your database, close your users all

over the world with no ops. Check them out at fly.io. What's up, friends? I'm here with Vijay Raji, CEO and founder of Statsig, where they help thousands of companies from startups to Fortune 500s to ship faster and smarter with a unified platform for feature flags, experimentation, and analytics. So Vijay, what's the inception story of Statsig? Why did you build this? Yeah, so Statsig started about two and a half years ago.

And before that, I was at Facebook for 10 years where I saw firsthand the set of tools that people or engineers inside Facebook had access to. And this breadth and depth of the tools that actually led to the formation of the canonical engineering culture that Facebook is famous for. And that also got me thinking about how do you distill all of that and bring it out to everyone? If every company wants to build that kind of an engineering culture of building and shipping things really fast, using data to make data informed decisions, and then also informed to like, what do you need to go invest in next. And all of that was like fascinating, was really, really powerful. So, so much so that I decided to quit Facebook and start this company. Yeah. So in the last two and a half years, we've been building those tools that are helping engineers today to build and ship new features and then roll them out. And as they're

rolling it out, also understand the impact of those features. Does it have bugs? Does it impact your customers in the way that you expected it? Or are there some side effects, unintended side effects? And knowing those things help you make your product better. It's somewhat common now to hear this train of thought where an engineer developer was at one of the big companies, Facebook, Google, Airbnb, you name it. And they get used to certain tooling on the inside. They get used to certain workflows, certain developer culture, certain ways of doing things, tooling, of course, and then they leave and they miss everything they had while at that company. And they go and they start their own company like you did. What are your thoughts on that? What are your thoughts on that kind of tech being on the inside

of the big companies and those of us out here, not in those companies without that tooling? In order to get the same level of sophistication of tools that companies like Facebook, Google, Airbnb, and Uber have, you need to invest quite a bit. You need to take some of your best engineers and then go have them go build tools like this. And not every company has the luxury to go do that, right? Because it's a pretty large investment. And so the fact that the sophistication of those tools inside these companies have advanced so much, and that's like left behind most of the other companies and the tooling that

they get access to, that's exactly the opportunity that I was like, okay, well, we need to bring those sophistication outside so everybody can be benefiting from these. Okay. The next step is to go to statsatsig.com slash ChangeLaw. They're offering our fans free white glove onboarding, including migration support, in addition to 5 million free events per month. That's massive. Test drive Statsig today at Statsig.com slash ChangeLaw. That's S-T-A-T-S-I-G.com slash ChangeLaw That's S T A T S I G.com slash change. Well, the link is in Apple.

Welcome. Thanks a lot. Happy to be here. I'm curious why you personally, Swift team manager, why are you at KubeCon specifically? Yeah, so I mean, Apple has loads of people here. We're giving several talks. So mostly from the cloud side of things,

obviously we're big users of a lot of the software that's on show here, and it's great to be a part of this community. Me, myself, I used to be a server developer for many years, but I've been out of it

for, I guess, the eight years that I've been working on programming languages. So this is my way of immersing myself back into what the latest is in tech. Okay.

Because when I was last doing this kind of thing, we were already banging rocks together, running stuff. Cron and, you know, it's amazing. Cron is banging rocks? Well, you know, I see a lot of them banging rocks. There's a lot of impressive stuff here, right?

Yeah, yeah, yeah. Okay. We're cavemen, Adam. We bang the rocks together. Point taken. I'm still using Bash, too. Is that an issue? ZShell is cool, too.

Yeah, right on. I? ZShell is cool too. Right on. I use ZShell as well. But I write Bash in scripts executed with ZShell. Okay. You're using all the rocks. That's right. All the rocks. So we just spoke with somebody.

Who was it? Jared Henderson we were just having on the show. He was building a Mac app and had a website or a REST API and a management and stuff. And he's like, I'm doing client-side Swift. I'm doing server-side Swift. And I was like, that's pretty cool. I don't think most people know that server-side Swift is a thing. When I think of Swift, I think of like, you're going to build an iOS app or a Mac app, of course. But that's just kind of the pigeonhole, unfortunately, that in my mind it's in. But it's apparently a lot more than that now. Do you want to talk about some of that?

Yeah. So it's great to have an opportunity to talk about this stuff. So server-side Swift has been a thing for some time. I think presumably Jared's using some of the great frameworks throughout there. So there's a technology called Vapor, which is kind of a Rails-like piece. That's what he's using. And he mentioned another one called Hummingbird. Yeah, Hummingbird is more of like a cut-down kind of when you don't need a whole framework to bring up a site, you just want to respond to HTTP requests. So yeah, that's more of a lightweight thing.

And they're both pretty cool. The authors of those technologies sit on our Swift on Server working group that we have that's kind of following a similar pattern to CNCF, right? Where they have libraries and frameworks and they try and incubate them and then graduate them to officially endorse things. And yeah, it's an opportunity for people to write the same code that they write on their devices on the server side. Obviously, there's a big win there, which is you get to share code between the two places. But even if that's not something that you're into, we think Swift is a great opportunity

for high performance but approachable language on the server side. Yeah. Obviously, it didn't start there. I do remember when Swift was first launched pre-open source, and Chris Lattner talked about some of the design decisions that he made. Very ambitious. It was like scaling down a single script all the way up to huge applications and stuff. Has that vision been realized in your opinion?

I think so. I mean, we're seeing recently some pretty exciting developments. So just in the last couple of weeks, we introduced a vision document. We actually, the language steering group that I'm a member of that sets the direction for the language via our sort of open process that we have on the forums that we run at swift.org. We have these things called vision documents. They're kind of our version of roadmaps that set out larger language features.

So when we introduced concurrency a couple of releases ago, that started off with a vision document, and then individual pieces of the language get proposed as a part of that. And one of the latest vision documents that we just officially approved was for something called Embedded Swift, which is the ability to slightly subset down the language to a point where you can build statically linked binaries that are really tiny. So we have, if you look at the vision document, it actually has a video of us running on one of these STM32 boards, which have just one mega memory, a really tiny binary that bounces a

Swift logo around an LCD screen. And up until recently, that involved statically linking the entire Swift runtime into the binary. That would end up being about 600K, which would fit on a lot of things, but not something that small. That binary now strips away all of the dead code and gets you down to the point where the binary for this little demo is just 15K, which is, and 10K of that is actually the image of the Swift logo. So it's really just 5K of code. And that allows us to target new environments, but using the same language with all of the same sort

of high-level feeling features that you get with a regular piece of Swift code, sub-setting out just a few things that need heavy runtime support, like reflection and things like that. That's cool. So for those who haven't written any Swift, probably lots of people with Java backgrounds, JavaScript backgrounds, Go, Rust, whatever it is, how do you characterize the language in terms of typing, in terms of paradigm? Is it OO? Is it functional?

If you're just going to give the elevator pitch of Swift, the programming language features, how does it fit into other programming languages? Yeah. So the way I like to introduce Swift is actually I go back to when I first saw Swift and what really got me into Swift. So I actually wasn't a member of the team when Swift first launched. I joined about a year or so later. And at the time, I was actually working in fintech.

I was working for a bank, working on trading systems. And so we were a team doing sort of equity and derivatives trading. We had full stack development, server side, and UIs. And we were using various different languages. So we were using, on the server side, for these trading systems that really needed high performance, low latency. The developers separated into two camps, right? You've got the Java programmers and the

C++ programmers. The Java programmers were really fighting the garbage collector all the time. They were like, because every millisecond counted, they were making sure not to allocate too many objects and using ring buffers of scalar types and things like that. And they would look at the bytecode to make sure everything was going well. And the C++ programmers found this hilarious, right? They were like, why don't you use a proper language? But it wasn't so funny when the C++ code would segfault in the middle of a trading day, right? So that was the server side.

You had two camps of developers who had chosen a language, and that forced them into a pretty tough choice, right? Safety versus performance. Then we had UI programmers. They were targeting Windows. They were, you know, targeting Windows. They were using Visual Basic and then C Sharp. C Sharp, kind of a nicer language, I would say. It's my personal opinion than Java. Like it's kind of, you know, it came out slightly after Java and I feel like it was like slightly improved, similar style. So obviously they were enthusiastic about that, but they were, again, sitting on top of a garbage collector language.

And then we also had for less latency-sensitive things, we would have Ruby programmers writing Ruby on Rails apps for things like static data maintenance. And Ruby is such a... I remember I actually listened to one of your podcasts where you had Justin Searles on, and he was talking about how Ruby, they really focus on the joy of programming, right? And how it was such an enjoyable language to program in. But obviously, it doesn't scale to the kind of latency-sensitive environments that you need for that sort of thing. So it was really interesting that we were all using all of these different programming languages. And obviously, I think people should learn different programming languages. It sort of expands your brain, makes you a better programmer. But it was kind of unfortunate that the choice of language really limited them in some way.

And so my first impression when I saw Swift, when Chris announced it on stage, was like, yes, this is what we need. Because it was a non-GC language, compiles down to native, but it had that higher level feel that actually made it really enjoyable to program in, a lot like Ruby, right? So I think the sort of ambitious elevator pitch for Swift is that it's something that you can achieve C++ level performance in. Obviously, you have to work at it. Nothing comes for free when you're actually operating that level. But the language itself feels a lot higher level, a little bit more like Ruby. Obviously, it has a static type system, but we work hard with things like type inference to make sure that the types aren't in your face. We try and put an emphasis on progressive disclosure so that, obviously, one of the

key things for us is we want app development, which is the main demographic for Swift, to be easy to do. We want somebody to be able to sit down, not have the language get in their way, but also we want the language to be powerful to sit down, not have the language get in their way, but also we want the language to be powerful enough that the framework developers can create things like SwiftUI that is like this super high-level programming language that allows people to be very productive, put together apps super quickly. And so I guess that's how I'd characterize it. It's a native language, but with a high-level look and feel.

Okay. Sounds somewhat too good to be true. Yeah. So obviously this puts a lot of stress and strain on the compiler itself. Right. So that's why we work pretty hard to work on the performance through the optimizer. Obviously, we're a reference-counted language, so we don't have GC pauses. But sometimes we have more reference counts than you want,

and that's where the optimizer has to kick in and eliminate things and prove that there are optimizations there that can make it more efficient. But for the most part, we think we're achieving that goal, and we just want more people to enjoy the language like we do. Yeah, I think breaking it out of the Apple bubble has always been interesting to me. And open sourcing, it was like step one

of that. And if you look at C Sharp, for instance, like it's very much is where it is. I mean, maybe they've made inroads and it's obviously Microsoft

themselves have started to open source tons of stuff. But I was surprised to find in your email that, you know, it's available for Windows and Linux.

I mean, I didn't even know that. I think I knew Linux maybe, but had forgotten. Are these just like native Windows support for Swift? Or how is it? Yeah. Yeah. So Linux we've had since the first day of open source.

Yeah, I remember that. And more recently, we adopted Windows as an officially supported platform. So that was actually a community effort. So it was driven by a member of the core team who actually now works for the browser company who are themselves using Swift to bring their Mac and iOS browser to Windows. And they actually recently published an article where they're using Swift to wrap the Windows APIs. They've actually got a really interesting implementation of COM, which is the way that Windows interoperates with its API that integrates really natively with Swift. And I think one of the links I sent you that maybe people can find online is about how they believe, and we agree, that interoperability is one of Swift's superpowers.

So one of the things that Swift can do is interoperate directly with C-based languages. So this was actually how we bootstrapped the original ecosystem for Apple devices. So on day one, you launch a language, you know, it was there at WWDC, you could download it that day. But when you launch a language from scratch, it doesn't have an ecosystem, except Swift did from day one, because we have this ability to interoperate directly with C and in Apple's SDK's case, Objective-C. So when you import an Objective-C header file into Swift, it comes in and looks and feels like a Swift library. You can create the objects, you can call methods on them as if they

were Swift native methods. One of the things that's nice about the Objective-C ecosystem is that they had these really well-adopted naming conventions for their methods on their types. And that was really nice because we were able to, Swift has also some great guidelines around how to name methods, but they weren't the same as Objective-C. But because the Objective-C ecosystem was so consistent, we were able to do some tricks where we basically renamed the methods so that they actually come in to Swift looking what people refer to as Swifty, right? Like they feel natural. And so that was actually the way that we bootstrapped the original ecosystem. Now sitting on top of Objective-C meant we also had to have C interop as well.

And that's actually a really interesting opportunity on the server side because obviously we have folks who have written code that they felt had to be written in C, right? Like I was talking about right at the beginning, people who actually really, really need that low latency, high performance, they would usually pick C or C++. And I think in this day and age, unfortunately, that's something that's a real problem because of the lack of safety in those languages, right? And the NSA, I think about a year ago, put out a white paper saying, urging people to start moving off of unsafe languages. And Swift was one of the safe languages that they suggested, as well as C Sharp, Java,

Rust. But we feel that Swift has two advantages in this area. One is if you're going from C or C++, maybe you can afford to go to a managed language like Java, but maybe you can't. And so Swift alongside Rust has the ability to compile natively. But Swift has the advantage, one, that we think that the high level feel of the language, you know, pays dividends in terms of productivity when you make the shift from C++ to Swift. We actually have been slowly rewriting the compiler ourselves in Swift. When it first came out, it was already in C++, obviously,

because you can't self-host if you haven't got a language yet. But we've been doing that migration, and I was doing some work on our parser recently. And we have to do it twice at the moment, because we have the old parser and the new parser before we swap the new one in. And it's so much nicer to be writing in a higher level language that feels a lot more productive, right? So there's that advantage. The other advantage is that Swift actually, as of last release, now has C++ interoperability as well as C. And so similar to Objective-C, C++ types come in and look like native Swift types. You can call methods on them with dot and things like that.

And we don't have, you often hear this term FFI, foreign function interface, that a lot of other languages use to interoperate with C, right? So if you use Go or something like that, you have to create bindings and then go through this FFI layer. Swift doesn't have that. We basically, we use the C compiler, Clang, that's also part of the LLVM project essentially as a library to bring in C API directly and that means that we skip the FFI layer that has an efficiency benefit but it also means that we can really integrate those things nicely and you don't have to generate bindings now why is that important the key thing there is that means that just like with apps transitioning from Objective-C to Swift if you've got a big C++ server installation or library,

you can do the migration essentially function by function, file by file. So it's not a big bang rewrite, right? So, which is normally where these kind of initiatives go to die, right? You're like, oh God, okay, we've got this existing installation. It's all running in C++. What are your choices? You can either break it up into microservices, which has consequences in terms of performance and all sorts of things like that. You're now going to monitor multiple things. Or you can try

and smoosh your new language and this existing service together, and that ends up being pretty painful. With Swift, we think that it's a much easier migration because you can just directly interoperate with your C++ code as if it was native Swift code. How frequently is that migration happening? You said the NSA suggesting Java and Swift and others as safe languages to move to. It's got to be an initiative of your walls, like you mentioned, the vision aspect of it to enable paths to migrate. How much out there is to be migrated? Is it just a ton?

Oh, yeah. Obviously, right? There's a lot of code out there to be migrated to. And you want to be the target of that migration. Right, exactly. So we think that if people are heeding that warning and saying, oh, maybe I should think about getting off of my existing C code base. That we're a great opportunity for people to adopt us and both level up in terms of a language that's easier to use, but also make it a less painful transition where it's not just a rewrite.

Because one of these problems with rewrites like that is you end up with the rewrite team and the legacy team. And there's this really sometimes unhealthy dynamic there, right? Where, you know know which team are you on and sometimes the legacy team are like we want to stick with this thing or that we want to enhance the existing old thing and the rewrite team are always like ah we've got to rewrite everything before we can we can move on to the new thing if instead you're like at the code level introducing a new language bit by bit you know you can mix it up a little bit you. You don't need to have two separate teams for the new thing and the old thing. You can just say, okay, today I'm adding this new feature.

I'm going to write it in Swift. And so there's a couple of great talks on this that we gave recently. One was actually at Strange Loop where Conrad from the Swift team talked about how we introduced Swift into an existing open source Apple project, FoundationDB, which is actually a sort of a database technology that we use on the iCloud side, and introduced Swift into that. And that could be done incrementally. And then there's another talk that John McCall, who actually chairs our language steering group, gave at CPP Now, which is a C++ conference, where interestingly, there were multiple people giving talks about successor languages. It's kind

of funny to go to a C++ conference and say, like, hey, I really want to think about getting off of C++. But he has a lot of credibility in that area. He worked on Clang for years. And so, you know, he's an expert in the language. He's the maintainer of some of the standards documents. But he's basically there to say, hey, we've got to start thinking about this, got to start moving on. And we think that this is a realistic path that you could take. When did the support for Windows come about? And is that also part of this, you know, a welcoming banner? Like it's a migration target in terms of C++ to Swift, but also to be able to develop on Windows. Is it a runtime that's on Windows? Is it

a development environment that goes somewhere else? Describe the Windows support and the initiative behind that. Yeah. So, like I say, Salim and the folks at the browser company have done some really heroic efforts in wrapping some of the Windows SDKs. And I'm not going to speak for them because it's their work, but I suspect the answer is mostly that they're not looking to create like a cross-platform SDK, right? They want a language, in the case Swift, that will compile Windows binaries and have that able to access the existing SDK, just like Swift accesses the existing SDK on Apple platforms. So there is a bit of a runtime in terms of, obviously, we have a standard library that you can use. We also have taken the next level above the standard library, which is something called Foundation. Now that's something that Apple developers will be very familiar with.

It's been around for a long time as the core part of Apple's SDK. When Swift first launched, obviously, Foundation itself, when Swift first launched, was written in Objective-C. And the initiative at the time was we were going to create this parallel version of Foundation written in Swift. Unfortunately, the challenge there is those two things got a little bit out of sync because the Objective-C implementation on Apple's side wasn't identical in every way to the implementation that we refer to as CoreLibs Foundation on the Linux side. And people found that a little bit challenging. I think that was one of the reasons why Swift on Linux adoption stalled a little bit in the early days. So about a year ago at the Swift on Server conference, Tony Parker from the Foundation team announced something new,

which is that we were open sourcing a new pure Swift implementation of Foundation that was actually going to be the implementation of Foundation that if you are running iOS 17 is on your phone. And so that's actually identical code now that we're open sourcing and that you can run on Linux and Windows as a package that you download and compile into your binary, whereas on iOS, it's there in the frameworks that you use. And it was a while to get to this point, because we had to do quite an interesting trick, which is we actually had to invert things.

We originally had a library written in Objective-C, and then we were sitting on top of it as Swift. And we had to flip that around so that actually the implementation of Foundation was written in Swift, and then we had to re-expose all of that functionality back to existing Objective-C apps. One of the things we have on Apple platforms is we have this ABI-stable platform where you can write an app, put it up on the App store, and then the operating system upgrades underneath it without you having to re-download the apps. And that's really important. And that relies on a technology of ABI stability, which is something that Swift implemented, I guess, three years ago now with Swift 5.0, which was a really important point for us because that allowed us to start

implementing parts of our operating system in Swift up until that point. It was only a technology that we could use internally within the operating system, but we couldn't expose frameworks written in Swift. But once we achieved that, we were able to do that inversion of foundation, and now we're at the point where we're starting to open source code that is literally the identical code that you will be running on your phone built into the operating system on Windows and Linux as well. What's up, friends? This episode is brought to you by our friends at Neon.

Serverless Postgres is exciting and we're excited. And I'm here with Nikita Shamganov, co-founder and CEO of Neon. So Nikita, one thing I'm a firm believer in is when you make a product, give them what they want. And one thing I know is developers want Postgres, they want it managed and they want it serverless. So you're on the front lines. Tell me what you're hearing from developers. What are you hearing from developers about Postgres managed and being serverless? So what we hear from developers is the first part resonates. Absolutely. They want Postgres. They want it managed. The serverless bit is 100% resonating with what people want. They sometimes are skeptical. Like, is my workload going to run well on your serverless offering? Are you going to charge me 10 times as much for serverless that I'm getting for provision? Those are like the skepticism that we're seeing and that people are trying and they're seeing that the bill arriving at the end of the month.

And like, well, this is strictly better. The other thing that is resonating incredibly well is participating in the software development lifecycle. What that means is you use databases in two modes. One mode is you're running your app, and the other mode is you're building your app. And then you go and switch between the two all the time because you're deploying all the time. And there is a specific part

when you're just building out the application from zero to one, and then you push the application into production, and then they keep iterating on the application. What databases on Amazon, such as RDS and Aurora and other hyperscalers are pretty good at is running the app. They've been at it for a while. They learned how to be reliable over time. And they run massive fleets right now, like Aurora and RDS run massive fleets of databases. So they're pretty good at it. Now, they're not serverless. At least they're not serverless by default. Aurora has a serverless offering. It doesn't scale to zero. Neon does. But that's really the difference. But they have no say in the software development lifecycle.

So when you think about what a modern deploy to production looks like, it's typically some sort of tie-in into GitHub, right? You're creating a branch, and then you're developing your feature, and then you're sending a PR. And then that goes through a pipeline, and then you run GitHub actions, or you're running GitLab for CI, CD. And eventually, this whole thing drops into a deploy into production. So databases are terrible at this today. And Nian is charging full speed

into participating in the software development lifecycle world. What that looks like is Nian supports branches. So that's the enabling feature. Git looks like is Nian supports branches. So that's the enabling feature. Git supports branches, Nian supports branches. Internally, because we built Nian, we built our own proprietary. And what I mean by proprietary is built in-house. The technology is actually open source,

but it's built in-house to support copy and write branching for the Postgres database. And we run and manage that storage subsystem ourselves in the cloud. Anybody can read it. You know, it's all in GitHub under Neon Database repo. And it's quite popular. There are like over 10,000 stars on it and stuff like that. This is the enabling technology.

It supports branches. The moment it supports branches, it's trivial to take your production environment and clone it. And now you have a developer environment. And because it's serverless, you're not cloning something that costs you a lot of money. And imagining for a second that every developer cloned something that costs you a lot of money in a large team, that is unthinkable, right? Because you will have 100 copies of a very expensive production database. But because it is copy and write and compute is scalable, so now 100 copies that you're not using, you're only using them for development, they actually don't cost you that much. And so now

you can arrive into the world where your database participates in the software development lifecycle, and every developer can have a copy of your production environment for their testing, for their feature development. We're getting a lot of feature requests, by the way, there. People want to merge this data or at least schema back into production. People want to mask PII data. People want to reset branches to a particular point in time of the parent branch or the production branch or the current point in time, like against the head of that branch. And we're super excited about this. We're super excited. We're super optimistic. All

our top customers use branches every day. I think it's what makes Neon modern. It turns a database into a URL and it turns that URL to a similar URL to that of GitHub. You can send this URL to a friend, you can branch it, you can create a preview environment, you can have dev test staging, and you live in this iterative mode of building applications. Okay, go to neon.tech to learn more and get started. Get on-demand scalability, bottomless storage, and data branching. One more time, that's neon.tech. So Swift on Mac, Swift on linux now swift on windows obviously swift on ios swift on android so there is a community effort so like i was saying earlier windows became an official platform relatively recently and what happened up till that point is it was really this community effort

where community members took the open source Swift, made it run on Windows. The hackers are going to hack. Exactly. So the hackers hack and then they get it going. They do a really amazing job. And then they have to deal with all sorts of struggles. In the case of Swift on Windows, now all of a sudden we have to compile the compiler with Visual Studio, which is always fun because C++ compilers don't always agree. So they did that work. And then at that point, once it graduated, it became an official version of the language.

We have people who are working on Android, and they're still in the sort of the community bringing it upstage. We also have a community effort to implement WebAssembly as well. Oh, nice. That hopefully at some point will stabilize and can graduate. Yeah. That's cool. And the reason I think of that is you go back to Arc's story, the browser company. And it's a really cool go-to-market strategy.

I mean, we know that a lot of new businesses, software businesses, start on Mac if you have a certain demographic or targeting. Obviously, they are with Arc, the browser company. But now they can use the same language and they can say, okay, we've established some sort of foothold here, people like it, let's go ahead and develop a Windows app. And so they're doing that, right?

It'd be very cool if you could start on iOS and then as that business becomes established and you think you have something here, now move it to Android without starting brand new, right? Or going to a React Native from the beginning. I mean, there's ways that you can try to go cross-platform, but if you could have Swift to start with and you could have all the benefits that Swift has,

including the ergonomics that are nice, so you can move quickly and build something fast, and then not have to rewrite or hire a whole new team on the android side obviously there's a difference between a language runtime and the sdks to do all the thing and the widgets and stuff but somebody could build on top of it from there you know and i think react native has seen a lot of people using it because it provides that kind of flow to a company and i think with arc moving to windows that's really. But if you could start at iOS

and then graduate over to Android, I think that'd be a really cool story too. Yeah, I think there's a great opportunity there for the community to bring something about that works. Due to the open source nature of it, there's nothing stopping people bringing it to new platforms. I think another thing that people have done is, before we announced this recent vision around embedded Swift, people were already actually bringing Swift to embedded platforms. I think there are a couple of products that are kind of maker kit products that actually are based around Swift. I think somebody has already brought Swift to Arduino platforms. So yeah, that's part of the open source nature is that anybody who has a will to make it happen for a new platform and has a great business idea can get involved.

When it comes to the moving from C and C++ initiative, there's this big push, not just from the NSA, but there's grassroots efforts, there's more formalized efforts. I know it was at Josh O's from Let's Encrypt, really pushing, like, let's rewrite all of the Internet's core infrastructure, open source mostly, in memory-safe languages, et cetera.

Most of that that I've seen from my purview is getting rewritten in Rust. There's lots of, I mean, on the kind of stuff that we cover in Change.org News, it's like this but rewritten in Rust like weekly. And so Rust really has momentum there. And I wonder if you think that Swift can go toe-to-toe with Rust in terms of just capabilities. I know you think there's some ergonomic advantages, which probably is the case.

But in terms of momentum, it just seems like Rust has some. And I wonder if you follow that or if you have insights on why that is and how Swift might help out in that regard? Because there's so much to rewrite. Yeah, there is. And I mean, anything is progress. So certainly, I think new rewrites moving off of C into Rusta are exciting to see. Like I say, I think there's a couple of interesting things there. So Swift and Rusta share a lot of similarities. Obviously, they're both GC-free. They are influenced by a lot of the same predecessor languages. The key difference probably comes down to their approach to defaults.

Rust, the default is that objects aren't copyable by default and need to be uniquely owned by default, whereas Swift takes the approach where objects are copyable by default and don't need unique ownership. But when you need to for either performance reasons or for actual business logic reasons, you can opt out of copyability. So if you want to create a, I don't know, a wrapper for a file handle where it'd be bad to make a copy of the file handle and pass it off to somebody, you can opt that type out of copyability and that now becomes what we call a non-copyable type. And that was introduced in the last version of Swift. We actually have some new language proposals this year to extend that capability, make it a bit more flexible.

But yeah, that's really the key difference. The other key difference goes back to, which is kind of really in the weeds, that idea of ABI stability. Swift has this capability of creating libraries that expose generic APIs and are separately compiled, but are able to be API stable. And that's actually a really key differentiator. Maybe unpack ABI stability, just in case we're assuming that everybody knows what that means. Yeah, so as I was saying earlier, the key with Apple's platforms is you can compile your app

and then you upgrade the operating system underneath you and the APIs, so long as they still provide the same ABI, the application binary interface, your app compiled against the old APIs can run against the new APIs. And that's how come you can upgrade your phone to the latest version of iOS and you don't need to redownload the apps from the App Store. Now, that's always been possible with C. C has really always had, I could see a world where actually C usage, maybe in a dream world, is reduced down, but C lives on as the way that different languages talk to each other, right?

So if you want to talk from your Go program to your Rust program, you use C, right? Like you use the C ABI and you use C Go on the Go side and you use FFI on the Rust side. So C has always had this ABI stability capability, but on Apple platforms, we needed more than that. We needed the ability to create something like SwiftUI that exposes a rich API that's easy to use and is really expressive and uses sort of much more powerful features like generics in a way that other languages aren't able to provide. And the fact that we make these available whilst preserving ABI stability is something that is really key to Swift's success on that platform. Now on Linux, most people don't really need that kind of thing. They just compile their single static link binary and then they ship it off to the server.

And so Rust itself actually doesn't have a stable ABI. And that's a choice they made. Their generics model actually does something called monomorphization, which is what C++ does. And that essentially means you have to compile the code for your generic, the generic code you're calling into your binary. Swift doesn't have that restriction, and that therefore gives us a slight benefit. But like I said, that's kind of in the weeds. What we actually think is the key differentiator is the readability benefit you get from Swift. And I think that's actually really important because, again, if we move into a dream world

where we've managed to move on from memory-unsafe languages like C and C++, hopefully we see the number of exploits that are coming from things like buffer overruns and use after free and all of these ugly things that can happen with those unsafe languages. We see those exploits reduced down, but there are still going to be exploits. And probably the next frontier after that is going to be correctness bugs. I don't know if you saw recently, there were two CDs issued for curl that came out and got a fair amount of press. And one of them was a high severity issue that was a buffer overrun, I think.

So a standard like, okay, that's written in a memory unsafe language, you can overrun the buffer. High severity, because pretty nasty, you could, in theory, get an exploit that runs arbitrary code. So that's bad, and we know the solution to that is that we need to move on

from a memory safety point of view. The second CB that was issued at the same time was actually a logic correctness bug. It was to do with cookies, and it was low severity because a lot of things had to line up in a perfect way. You had to have access to the file system in order to exploit it. But it allowed, I think, potential injection of a cookie as an exploit. And that was purely a logic bug. And I have this feeling that over time, as we manage to get a grip on language safety and the number of exploits that result from things like buffer overruns go down, the number of exploits that result from correctness actually goes up. And at the end of the day, that's going to mean that people are going to need to be able to write in a language where they can look at their code and know what it does. And there is a risk there that if we spend all of our time focusing on the memory safety aspects, and actually

that leads to a lot of ceremony in our code that makes it less readable as a result, that actually, I suspect, means that we're going to end up in a situation where people have a harder time writing code that's actually logically correct because the ceremony gets in the way. And that's another reason why we think that Swift is a nice option there because we try and go for a low ceremony language, including little niceties like Swift doesn't have semicolons to end each line. I know it seems trivial, but every time I move back to writing a bit of C or C++ and I realize I have to put those back in, it's a little frustrating. Fair. That's fair.

And as a guy who's written lots of memory-saved code, I can assure you there's plenty of logic bugs coming out of my fingers as well. So that's definitely going to be a problem. Performance as well, I think. The reality is, yes, we want natively compiled languages. I was railing on the GC pauses earlier, but at the end of the day, I, I, I look at a lot of performance bugs as part of my job. And a lot of the time they actually come down to not the low level stuff. It's the high

level stuff. Like, are you actually in a for loop that inside the for loop has another linear scan on something. And so therefore, like suddenly when somebody has like some massive input data set, it's a lot slower exponentially. So or quadratically slow compared to a normal input data set. And that's actually where a lot of the performance challenges come from. It's really similarly like the logic of the code. And the key there is to be able to have a language that feels lightweight enough that you can look at it, understand what it's doing, and then spend your time thinking about, oh, have I architected this right? Am I, you know, making 10 calls when I could make one?

Could I do things a little more simply or more efficiently? That kind of thing. How much in practice do you have to deal with memory related things in Swift? So I've written some Objective-C, and I know there's automatic reference counting and stuff, but there's also times where you have to turn it off or on, or maybe you have to futz with it, and I wrote some before that was a feature, and I can retain release and stuff, right?

So that's the tradeoff of not garbage collection. It's like, well, you're dealing with some stuff. In Swift, is all that gone? Do you still have to poke under the covers once in a while and say, you know what, there's some memory issues or not? Or how does that play out? The only time when it comes up is when interoperating with another legacy language. So if you're writing pure Swift, if you have that luxury, if you're just sitting down with a clean piece of paper and you're just writing some standalone item, like maybe a framework or something like that, you don't encounter any of that low-level operation.

The one thing you do have to be aware of in a reference-counted language is that you can get cycles, right? So if you explicitly need to have, let's say, the classic example is doubly linked list. If you have a link from node A to node B and then a link back from node B to node A, that creates a cycle. You need to break that cycle then a link back from node B to node A, that creates a cycle. You need to break that cycle. So one of those references needs to be weak. But that's pretty rare in practice. You know, if you're writing like data structures, which is usually something you grab a package to do, right, then you need to be aware of that sort of thing. The only other time that comes up usually is kind of callbacks, which used to be a lot more popular up until our

recent releases of Swift because we now have async await. So instead of like having a callback where you pass in a closure and get called back, you can now await an asynchronous method call, which is a lot nicer. So really the complexity comes when you're interoperating with an older language. So yes, there are some Objective-C libraries that don't even use automatic reference counting. And so you have to manually retain a release, and those operations are exposed to you in Swift if you need to call them to interoperate with something. Similarly, if you're calling into a C library,

depends on the C library, but some C APIs expose some disgusting void star thing, and you have to operate with it, and Swift has a bunch of affordances to allow you to try and turn those into a more strongly typed pointer that's a little safer. Even if it's still an unsafe pointer, it's a little safer to operate with. So really, that's where it kicks in, is that interoperability with those legacy languages.

So this sounds apropos of nothing, but maybe we can squeeze it into the ergonomics conversation. I think I saw recently, did you all remove the increment and decrement operator? This was like somebody on Twitter was just like... I saw that this morning. I do not know why somebody dredged that up. That was a change in Swift 3.0, which I guess was six years ago. People are talking about it. It's all over Twitter. Yeah, so yes, at the time, I think actually that change was proposed by Chris Lattner at the time, or maybe he was the review manager, I can't remember.

Yeah, we removed the pre- and post-increment operator, I think, because the idea is they're a bit of an attractive nuisance. I think if it was just a pre-increment or post-increment operator, that might make sense, but having two and like you know you that should not be the thing that people encounter or is there like first learning a language is like oh what's the difference between pre and post there's like all sorts of like myths on the internet about how one is more efficient than the other and things like that so yeah in the early days of swift there was a lot of rapid motion with the language that was actually one of the things that um was a bit of a challenge for the very early adopters from the swift 1.0 days is the language did go through a fair amount of churn. Since I think Swift 4, we actually adopted a policy where there are no more breaking language

changes except with a major version upgrade. And so basically when we introduce a new major language version and the next one is actually going to be Swift 6, there was actually a post to the Swift forums just a couple of weeks ago about what it means to migrate to Swift 6 and what the goal is there. When we introduce Swift 6, that's going to be the version of Swift that introduces data race safety by default. So we talked about Swift being a memory safe language. The one exception to that is if you have two threads and you've created those two threads and they share state between themselves. If you mutate a global object from both threads at the same time, that introduces a data race that can introduce memory unsafe behavior. As of today, you can opt into a strict mode that will prevent you from introducing those data races into your code. So if you have the latest version of Swift, if you download the latest tool chain from Swift.org to try out the upcoming version,

you can opt into that data race safety checker and it'll give you a bunch of warnings saying, hey, this is a class, you're escaping it by sending it from this task into this task. That could introduce a data race, and it'll tell you, and you can go in, and there are various language techniques that allow you to do something about that, you know, unsharing the reference, making a copy, things like that. Swift 6 will turn those warnings into errors, and that means that if you're starting a new project from scratch, you can be certain that your code is guaranteed data race free because the compiler just won't let you accidentally write a data race. Obviously, like all of these things, there'll always be unsafe opt outs where you say, oh, I've got to deal with this legacy API. So I need to be able to tell the compiler, I know, I know, but let me pass this value.

But obviously, people have existing code bases where, you bases where they've got to ship their app, they've got to do an update, they've got the latest version of the language, they want to use the latest version of Xcode that comes with the latest version of Swift, but they haven't got time to go through and address all of those warnings in order to switch to that newer secure mode. And so whenever we introduce a new major version, we always make it an opt-in choice. So when you compile your code, you say compile with the version of the language 5.0 or compile with the version of the language 6.0. And if you tell the compiler compile with the version of the language 6.0, it will stop you from making these data race issues into your production code.

But if you compile with version 5.0, it won't stop you. You can just get away with them just being warnings, and then you can tackle them at your leisure. And that's been much better for the community because it means that they can move forward. We don't end up getting into the classic Python 2 to Python 3 situation where people are holding back. And you can also do that migration at the module by module level. So you can break up your code and say, okay, this bit of code I've audited, it's good. I can go to Swift 6 mode. This bit of code, maybe I'm going to do that next month.

But in the meantime, I need to ship my app and adopt it. Stick with Swift 5 for now and then adopt Swift 6 maybe after I do that. That's cool. Very fascinating. All the places you can run Swift nowadays. Yeah, we'd really like people to get onto the Swift website, download a toolchain for their platform of choice, and try it out.

All right, we'll link up all the things, including those links you sent us, specifically the ARC one, very interesting. And we did not mention real quick the Godot engine situation. Maybe we'll just close with that. Yeah. This is in a proposal that from Miguel de Casa of adding Swift as a potential language

of choice for the Godot engine. I'm not sure exactly how that would work. Is that a rewrite? Is that just like an extension? Tell us more about what he's proposing there. This is for gaming. Yeah. So I saw that Miguel had posted his video from

GodotConf to the various social networks, and it was a really exciting talk to see. So the way he sort of cutely characterizes it is he made this, I guess, multi-million dollar mistake. He's kind of riffing off of the old saying by Tony Hall that he made the billion dollar mistake by introducing null into his first programming language. In this case, Miguel is suggesting that the mistake was popularizing a garbage collected language into a game framework in the form of C sharp, which obviously is a very popular language for writing games in. But then you have to fight with this issue in this really performance critical segment of the gaming industry with GC pauses. So he's proposing using Swift. He's been a bit of a Swift booster for a while, and it's great to see him advocating it in new places.

I believe his suggestion is that, again, leveraging that C++ interoperability capability, they could start to introduce Swift into different parts of the Godot project. And again, you can make that an incremental thing because you can just have it interoperate with the existing C++ code. But he's also written a nice Giddo API wrapper

that allows you to actually get going with Giddo using Swift today. And I've actually seen a few folks post to Mastodon with some examples of their game engines written in Swift, which is really cool to see. Very cool. Well, we'll link up that talk as well. I can go watch that one myself.

I like what Miguel has to say. Very, very smart guy. Knows what he's talking about. Very convincing in his argumentation. So we'll link that one up as well. Thanks, Ben. It's been awesome. Thanks a lot.

Is there anywhere Swift will not go? I don't think so. I think Swift will go everywhere. Developers want a fast, modern, safe, and a joyful language to write. And it seems that's on track based on what Ben shared today. Of course, go to swift.org to keep up on all things Swift. Big thanks to our friends and partners at Fastly, Fly, and TypeSense. And of course, to the beat freak in residence, Breakmaster Cylinder.

Those beats, they're banging. Okay, stick around for Friday. We're coming back at you with another episode of Change Logging Friends. I think you'll dig it. See you then. Thank you. Game on.