Hello everyone, so today I'm going to talk to you about swifts and this is aimed at people
who aren't really seen swift before, so I hope for the supplies to some of you at least.
I'm going to explain to you why swift is the best language for building modern applications
for back-and-services.
So I'm Tim, as mentioned, I run a company called Birkenham to be the service host of
Consultancy Helping Clients, deploy a main team, applications and services around the world,
but I'm better known as being one-half of the vapor-court team, and vapor is a open source
frame up for building APIs, web apps, back-ends in Swift.
I see on a couple of workgroups of Swift, so the website workgroup, which is responsible for Swift.org,
and the server workgroup, which I'll talk about later on in the talk.
And as mentioned, I will come out as a service host of Swift, which is an annual conference
based on service service, on Swift and the server, so you could say I'm a little bit invested in it.
If you have questions, I'll be hanging around, but feel free to reach out to me.
I'm 0x10, pretty much everywhere.
So let's get into it, so Swift. Swift was introduced just over 10 years ago now, but Apple's
developer conference. Back then, as a replacement for Objective C, as the language of choice
for building applications on Apple platforms. And when it was first introduced, it had four key pillars.
It should be fast, modern, safe, and interactive. And a little bit of kind of the unofficial fifth one,
which was it must be one language to rule them all. It should be a language that should be
able to target the entire stack with your building front-hand applications, or write it in embedded software.
And I want to go through each of those five pillars to kind of explain why Swift is a great language,
both in general and specifically for the server.
So Swift has a ethos of progressive disclosure, so the easy stuff should be easy to do,
and as you adopt more stuff, you can adopt more stuff and make it more complex.
So if I want to define a function in Swift, use the honk key word,
it looks pretty similar to most other languages, you may have seen it, and I can just print it.
If I want to write this as an application, then I can just wrap this in my entry point, use the
app main attribute with the main function, and this will generate a executable for me to build
and run. Well actually because this is Swift, you can also do scripting and just have a print statement,
and Swift will just print it out like you do, because it is really varied in how you can
approach it. But let's get back to our function. If I want to return something and say print a message,
I can return a string using the arrow key word, arrow syntax, and then if I want to use this API,
I can call it with let message equals same message, hello Swift, hello world.
And the idea is that Swift should be relatively easy to read as you scan code,
almost like you're reading some kind of text, and makes it easy to see what's going on with your
code and reason about your code. And that's one of the key talents of Swift is making it easy to understand.
Let's say I want to make this a little bit more complex and have two variables, so I can say hello to
me. Well let's just format this a little bit. For API calls like isn't great because I'm saying
message to Tim, message is a bit redundant there because I'm going to pass an message. And inside the
function I'm using two as a variable name, and that's not great either because it doesn't really
make sense in the context of that function. Well Swift allows you to have different internal
external variable names for your function parameters, so you can see the cool site down below is
say hello to Tim, reads really nicely, easy to see when you're reading it, and internally I can call
my other thing name, so I just prefer to name it, it makes much more sense.
The clearing variables is pretty easy, I can just do let result fully equals true. That's
declaring a boolean, I result with the value cube. Swift also has type inference, it's true,
it's obviously a boolean, so we don't need a ball, let's get rid of that. You'll also notice there's
no semi-colons because those are redundant as well, it really starts to clean up your code.
I come on to kind of Swift safety later on, but generally be aimed for Swift to be for things to
be immutable by default and only opt-in to mutability if you want them, so the lucky word means
this variable is mutable, so if I try and assign to it I'm going to get a compiler error because
it's immutable, so I just need to change it to a bar, and this is similar to like cotton and
other languages as well. If statements look pretty similar to most other things, apart from there's
no brackets, unless you need them, and then for loops also look pretty readable as well,
there's no whole i equals 0, i less than something dot length i plus plus.
We have a nice readable syntax of four name and names, and we can just loop through them,
but you can also get the index as well if you need.
So Swift is also a modern language, it's one of the kind of newer generations of languages that's
coming in of the last kind of decade or so, and it's definitely learnt and taken and borrowed
features and tools and power dynamics from other languages.
More than is optional, so if you're lucky in C you're passing a point to round,
if you know if it's no, not go quickly. In Swift, if I declare a string, this cannot be no.
The compiler one for today is not known wherever you use it and wherever you pass it around.
For what's it to be? No, we want it to be optional, I can mark this as optional with the
question mark on the type, and then this can be noble. But what it means is that wherever I use that,
I have to account for the fact where it can be no. So if I try and add a number to my optional
int, this won't work because what you do in the case where it's no. Maybe for an integer,
you might want to just assume it's 0, but maybe you want to assume it's minus one.
So Swift makes you explicitly opt into these features, which provides really clear,
concise code of what your code is doing. There are various ways of unwraping this in handling it,
you can use guards, you can use iflets, you can use optional training, but if you deal with it,
then the compiler is happy. Swift also has first class generic built-in from a language,
so if I want to define a collection of ints, you can define it like so.
And if I want to then define a collection of strings or collection of doubles or collection of
floats, you don't want to be copying and pasting code and having the same code
you've prepared throughout your purpose. So we can use generics and just have a generic collection
with our items and interesting enough array is also generic under the hood as well.
So it's very easy to reason about and very clear what your code is doing.
Let's talk about strings. So strings in Swift look pretty much like any other string in most other
languages. Define the string is the string, strings are UTF8 strings under the hood,
natively, which is really great for the server world by your passing round strings H to P and things
it UTF8 by default normally. But Swift has really powerful string processing.
So what you do in this case, what's the result of count of that string there? Well for humans,
we read that and go, well that's two characters there. But Unico is a habit of messing up pretty
much everything. Thankfully, Swift gets this right and will print the count as two. But most of
the languages actually really struggle with this. Do you have a script you get for, see you get eight,
drive you get for as well. Because Unico is actually a lot more complicated than just regular
kind of asky stuff. And Swift is one of the very few languages that gets 100 Unicoed and
emojis right. And she's really important the back end because we want to be able to allow
our users to have emojis in their titles for their peers and store those in the database and
store those natively. So these gents add people coming in with their emojis. Swift has a
concurrency model built into the language, which is really really powerful. So if I want to
define a concurrency function that is asynchronous, I have to mark that function as async. You cannot
do any asyncness work inside that without it. And then if I want to call another asyncness API,
I mark that with the await keyword. Is my mouse going to work? Okay, but you can see up there
that I use await and then call the async function. So when you're reading your code, it makes it
very clear as to where the potential suspension points of your functions are. This Swift also
goes slightly further with a think called structure concurrency. So if I define a task that I can
get in capture, but there's some asynchronous work. If I want to cancel that on some condition,
that cancellation will be propagated down to all child tasks automatically for you and cancel
all subsequent tasks and do all the cleanup for you as well. So it is a very powerful feature.
And there are hundreds of other language features that I really don't have time to get into,
but makes Swift a really great fantastic model language, also make it a really nice language
to use on the backend. So the safety and Swift is probably one of my favorite features around
why it makes such a great language for the backend. So it has some relatively unique features
that make it a nice safe language to use. As I mentioned, we have optionals, which ensure that
things can only be in there if you want them to be. And you have to explicitly handle the cases
whether or not they'll. And this means that non-pointed exceptions in Swift do not exist. We don't
have non-pointed exceptions at all. They're just not the things in Swift. Swift is also got
late memory checking, so it's a memory safe language. So other languages, which I'm not going to
name, we'll just consume buffer until you do that stop. And if you forget that luck,
where Swift has got really great memory balance checking, to make sure that standard kind of
classic exploits like memory overflows and use afterfrees are possible. In Swift, you have
explicit air handling. So like I mentioned with AC into weights, if you have a function that's
going to do something that could potentially throw, you have to mark that cool flight with a
tricy word. And your function has to either handle that with a due catch or be marked as throws
as well. So when you're reading code, it makes it really easy to see where the potential points
in your code that could throw errors. Which having done some correct script recently and having
to look through a massive function trying to work out which these lines is throwing out are
is a really nice little feature. There's been a real shift in the kind of industry over the
last few years from moving towards pipe safe languages and Swift is no exception. Swift is type
safe, aesthetically typed and strongly typed. Which means that if you're passing around something
as a type, it can only be that type and nothing else. And if you want to cast it, you have to
explicitly cast it and handle the cases where the cast fails. And the last one is something that's
pretty unique to Swift, which is the day-to-day safety. So Swift has a concept of
sendable, which allows you to only annotate types as being safe to pass across concurrent boundaries.
In essence, you can kind of think of it as thread safe. I'm sure the Swift team at the back
going, no, it's not, but it kind of is. That's the thumbs up, excellent. But what this means is that
essentially with sendable turned on a concurrency checking turned on, databases are not possible.
You'll get compile errors in your code if you're trying to do unsafe stuff. So we have all
of these features in Swift that mean that you're going to get told when you're compiling your code
that you have problems rather than when it's through a clock in the morning, you get page because
your services gone down, which is a really nice feature. Swift is also very important. Is it quick?
Yes, it's a compiled native language, which kind of gives it a bit of a head start over
some of the other interpreted languages. This is a slide from Apple's developer conference this
year. They used Swift on the server and handle millions of requests per second. So it is in
use in production and use well. One of the kind of unique selling points of Swift is the user's
reference counting. So some of the languages are garbage collected, which is quite nice sometimes.
This is that whenever the garbage collector runs, your performance kind of just tanks at some point
during your execution and you can't control it, you have no idea how bad it's going to affect
it or when it's going to affect it. With automatic reference counting, you get a really
nice deterministic performance. So you can predict how well your services can perform without
having to rob about as garbage collector. And this also makes Swift extremely memory efficient as
well. This is a client project I've got running in Fargate on AWS using the smallest
instance that you can provision. And I'm yet to break 2% of memory utilization. So please AWS
gives some small instances. But it's extremely memory efficient. And I work with clients
moving from other languages to Swift, which I've saved, 75, 80% of the cloud server bills,
purely because the amount of memory they don't need anymore.
And this also applies to things like lambda where you're paying per megabyte per
milliseconds. Swift has got exceptionally fast code start times, less than 100 milliseconds compared
to some of the languages where you might be more than seconds. So we're talking orders of
magnitude better. So it's more performance, it saves you money and it's nicer to use as well.
Just to be clear about it. So as we've seen this morning as well continues to see, Swift is
actually not just an application language anymore. You can use it for scripting and it's really
nice for scripting, how they type safe language without having to resort to bash. You can do embedded
development, you can do system programming, you can do server development. There's almost
we'll see in a bit as well as well as application development. So it is now being used throughout
the entire stack. In terms of platforms, as we've heard, supports macOS, it supports several
flavors of Linux. So there's Centos, Fudore, Debbie and you've been to Amazon Linux and probably some
others I've forgotten as well as Windows. But because it supports Linux, you can run it in Docker,
which means it's just another Kubernetes pod. So there's no kind of hard things when having to do
deployments, it's just another pod or container that you ship. One last thing I do on a
start out is its language interrupt. So from the very beginning Swift have to have first class
language interrupt with C and object to C, otherwise it wouldn't take off at all. This Swift also
has now first class support for C++ where you can natively call Swift types from C++ and call
Swift C++ types from Swift. And just last year at the end of last year, there was this Swift
Java prototype release or repository list, which allows you to interrupt with Java directly,
which allows you to slow your migrates, your services over. So we'll have a quick look at this
server ecosystem. As I mentioned, I am on a recording of paper, it's a well established,
very big, very large project that's been going for eight, nine years now, in nine years.
It runs real applications. It has pretty much everything you want to do on a server.
There's also a hummingbird, which is much newer, and probably has less tech deck at the moment.
And there's Swift package index as well. So if you're looking for packages in Swift to do something,
there's thousands of packages on Swift package index. There's probably something there for you.
These days, when working with clients, it's very rare that I actually have to write third-party
APIs or SDKs to talk to APIs and stuff like that, because they're really exist.
As I mentioned, I'm part of the Swift server work group, and we're responsible for
abocating for Swift and the server, making shorts as good as it can be.
Whether that's working with the language team to ensure that we have language features,
the compiler team to make sure it builds and the right platforms,
or whether it's fostering an ecosystem and building packages or tooling.
One of the things we have is that incubation list, or incubator packages, which is very similar to
CNCF's process, or we have a list of packages that have been through an incubation process.
So you start with sandbox, you're incubating, you're graduated. If you're looking for
database drivers or security libraries or web servers or metric stuff, have a look at the
stuff on there, the things in there have been battle tested, I'll well maintain, and I'll
look after, and there are quite a few packages in there now as well. We also have a,
I'll be servier at the org, which is a little plan on routes, I'll be there yet, which lists all
of the kind of fun things that Swift and the server can do, as well as linked to loads of
different packages as well. One of the things that I tend to get asked a lot when talking to
months with people and generally back in people is what about observability. And I think one
of Swift server's great legacies is the adoption of APIs for logging methods and tracing.
So we have API or packages for logging, packages for metrics and packages for tracing that provide
just an API. So all libraries and applications and packages in the ecosystem can just call through
those APIs and then application developers can bootstrap whatever back and they want. So if you're
working with metrics, all of the packages can call through to the metrics API and then as an
application developer, you can choose do I want to use Premiere so that's the or CloudWatch
metrics or whatever, and then our backends that you can plug the automatically work and the same
works for logging and the same works for distribution tracing as well. So it's a real thing that works
really really well. I'll do a shameless plug. The Swift server conference will be October,
South October, this year in London, we have great talks from companies as big as Apple Amazon
through to indie developers through to small apps, showcasing how they use Swift and the server,
the website should be updated soon when tickets go on sale. And so to recap, Swift has an ethos of
being fast, modern, safe and interactive and each of these make a really great language for
back end development that provides you with a really nice language to use, it's easy to read and
comprehend and very fast and very safe. And that's why I think it is the best language for building
one of that occasions on the back end. Thank you.
Yeah I'll take questions here.
So the question was, Swift originally was from the Apple ecosystem, how well is it working
Linux and what's the ecosystem like for packages and stuff, these days very very good. So
the foundational libraries are exactly the same on the Linux and on the Apple platforms.
We've been building packages for the ecosystem since 2016, so it's got a well established
package processor. It works very well, you can do it again, you can do
stack traces and do pretty much anything you want to do, is that?
Any more questions?
All right, thank you so much here for running out!