
Introducing Swift Service Lifecycle - hutattedonmyarm
https://swift.org/blog/swift-service-lifecycle/
======
ralmidani
Swift as a language/ecosystem does seem to check all the boxes in contrast to
other modern, mainstream languages; it looks, to me at least, like a much more
ergonomic alternative for building applications compared to Rust and Go. It's
considerably faster and more type-safe than Python and Ruby. And it has a
drama- and shenanigans-free licensing model that I personally am much more
comfortable with as opposed to the shitshow that is Java (and, to a lesser
extent, .Net).

I've been reading lots of Swift docs/articles, and made quite a few book
purchases from raywenderlich.com and hackingwithswift.com. My "gut feeling"
tells me making the investments to become proficient in Swift, and eventually
mastering it, will pay off big time.

As a web-focused developer, I must admit I found Objective-C and UIKit
intimidating, but with SwiftUI, Apple seems to be lowering barriers to entry;
if you know something like Ember, Vue, React, or Angular, you won't struggle
too much trying to grok SwiftUI.

With Vapor becoming a mature framework, and Apple giving its official blessing
for the development of server-side Swift libraries and tools, it does seem
like we may soon reach critical mass on the server, and there is a lot of
appeal in being able to consolidate and develop with one language across the
stack.

If we can get a Swift-to-Kotlin compiler and a Swift-to-JS compiler (there are
already Swift-to-HTML DSLs, and I have been experimenting with a Swift-to-CSS
DSL - with my limited proficiency in the language - and it does not seem
totally impractical), it's not unreasonable to imagine Swift becoming a "rule
them all" language (I remember reading somewhere that Chris Lattner said his
goal with Swift was "Total World Domination" and didn't think it was that far
off, but can't find the source now).

~~~
fauigerzigerk
Swift started out as a pretty nice language, but in my opinion there are some
major problems:

The combination of ubiquitous closures and reference counting is dangerous.
Avoiding circular references is not nearly as easy as you might think and
reference counting is slow (low memory usage is an upside though).

And lately, the language has become rather convoluted. They have added
features that make Swift code hard to read. Function builders in particular
are a terrible idea. I know many people like internal DSLs. I don't.

I think it's a big mistake to overload the syntax of a language to such a
degree that reading a piece of code in isolation tells you very little about
what it does, because somewhere far away there may be a mode switch that
completely changes the semantics of that piece of code.

Consistency is more important than "looking clean" at all cost.

~~~
ralmidani
I agree function builders have a lot of potential for abuse. But I prefer to
take a "with great power comes great responsibility" approach over saying a
feature should _never_ be allowed in a language.

If I'm promoting a DSL that makes heavy use of something like function
builders, I should provide robust documentation so other developers know what
to expect. And those developers should, on the other hand, at least skim the
docs in order to get a basic understanding of how the DSL works. If someone
goes through the trouble of providing docs to accompany a DSL, and a
downstream developer doesn't bother to read them, is that really the original
developer's fault?

~~~
fauigerzigerk
Consistency is a good thing, because it allows you to infer how something
works based on what you already know. If you can't infer it then you have to
go read the docs. That's more work you have to do.

There's clearly a trade-off between expressing a specific task as succinctly
as possible and for our knowledge to be transferable between different tasks.

It is the job of a programming language to guarantee a minimum level of
transferability while allowing maximum expressivity. To do that, it has to put
restrictions on how the semantics of syntax can be redefined.

It's clearly an art to get that balance right. In my view, Swift hasn't got it
right and is moving in the wrong direction.

~~~
ralmidani
I sympathize with your concern. I actually chose Python/Django over Ruby/Rails
because I found it almost impossible to understand how Rails really works. The
biggest offenders in my book are Rails doing auto-import and (at least when I
was learning it) lots of reopening of classes. Even if a person wanted to read
the docs to understand where a piece of functionality came from, it was very
easy to get lost.

Swift does risk getting carried away and becoming just a safer and faster
version of Ruby, but I still think it's too early to write it off just because
they introduced some syntactic sugar.

I've said before that writing an import statement never killed anyone. If
Swift were to make something like auto-imports mainstream, I would definitely
take it as an indication they were going in the wrong direction. But so far
that doesn't seem to be the case.

------
qalmakka
Maybe if swift had something like rustup, people would consider it more when
developing for Linux. Also other popular languages like Rust and Go work well
even on weird architectures and little known operating systems, while Swift
does not even properly support Windows or FreeBSD. It always felt to me that
Apple doesn't really care that much about making the language popular outside
of the Darwin family.

Swift is not even in the default repositories of most distributions, for
instance.

~~~
saagarjha
> Also other popular languages like Rust and Go work well even on weird
> architectures and little known operating systems

As someone working on porting “everything” to a decidedly not weird
architecture and a very well known operating system, I chuckle a bit because
neither language works right now. Not even their dependencies work. It’ll be a
while before they will be supported.

(Swift works perfectly, but it would be unfair to compare it because it had a
strong investment made in it to work…)

~~~
Abishek_Muthian
I've been running production grade Go apps[1] on aarch64 servers for ~ a year,
written on macOS(x86_64), tested on aarch64 before deployment and never faced
a single instance where something didn't work because of the architecture.

These are the benchmarks for different ARM platforms[2], where I had submitted
one for Jetson Nano a year back and now it seems there's one for Apple
Silicon.

I'm not telling, no one would ever find cross platform issues with Go; I'm
just curious to know what issues you have faced and whether it's because of
Apple's extension of ARM instructions.

[1][https://needgap.com](https://needgap.com)

[2][https://github.com/golang/go/wiki/GoArm#jetson-
nano](https://github.com/golang/go/wiki/GoArm#jetson-nano)

~~~
saagarjha
The comment wasn’t really an attack on the languages being unportable itself
but more that their toolchains are complicated and not very flexible,
requiring a decent amount of additional work for new architectures, whereas a
lot of the “./configure && make” style projects already work.

Apple’s proprietary extensions don’t really affect porting efforts except in
one specific case when writing high-performance JITs for language runtimes.
(And there is a fairly simple patch to disable this entirely.)

~~~
Abishek_Muthian
>chuckle a bit because neither language works right now. Not even their
dependencies work. It’ll be a while before they will be supported.

I'm not sure what's preventing you from giving a direct & specific answer. As
it would be useful to know where Rust/Go's toolchains fail for using the code
for cross - platform applications.

~~~
saagarjha
Rust is blocked on libffi, as are most things using Python (which includes
cmake, and that precludes all of LLVM). I downloaded the Go bootstrap and it
tried to link against crt0 directly and it's either looking up the wrong one
or there is none for aarch64. It's also looking for a file called
defs_darwin_arm.h which I don't have. Some warnings that will probably be
problematic at the future related to the ABI defining char to be signed.

~~~
Abishek_Muthian
>I downloaded the Go bootstrap and it tried to link against crt0 directly and
it's either looking up the wrong one or there is none for aarch64.

Go team was already working on getting the toolchain to work on darwin/macOS
before Apple announcement[1] because GOOS=darwin meant iOS(gomobile) and there
are instructions available now[2] to build it successfully before the official
patches. Your test results there would be a valuable contribution.

>Some warnings that will probably be problematic at the future related to the
ABI defining char to be signed

You mean unsigned char? that's a common hurdle while porting x86 code to ARM.

[1][https://github.com/golang/go/issues/38485](https://github.com/golang/go/issues/38485)

[2][https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf35...](https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf3553b4501)

------
skohan
That's a neat idea, thanks to named parameters and an expressive type system,
I can see how Swift could be a good fit for tasks typically handled by config
files. Also having a turing complete language available to customize behavior
could have some interesting use cases.

------
RcouF1uZ4gsC
>Shutdown sequences include freeing up resources that hold on to file
descriptors or other system resources that may leak if not cleared correctly.

Startup workflow is important, and it is nice to have an abstraction that
makes it easier.

I am less convinced that shutdown workflow is important, and may be more
trouble than it is worth. On modern operating systems, the OS will handle
process shutdown and clean up system resources such as file descriptors etc.
In addition, with things like the OOM killer, etc, the process may not have a
chance to actually clean up. Trying to engineer graceful shutdowns is extra
code with subtle edge cases (like circular dependencies), and generally, less
well tested and exercised. Finally, the operating system needs to be robust
against leaking resources due to processes crashing, anyway. So on the
balance, I think it is worthwhile to do a startup workflow and engineer your
service so that you can always crash safely without messing up your system or
leaking resources.

~~~
PaulRobinson
If your code is crashing more often than it is gracefully shutting down, you
have a problem.

Yes, you need to engineer for the crash scenario, but you shouldn't be relying
on that in the same way you shouldn't tell users the only way to stop your
software is to `kill -9 [PID]`.

In a normal deployment it might be useful to use shutdown parts of code to
signal to orchestrators that the operation has been completed successfully so
they can take further steps, for example.

Everybody's circumstance is different, but I definitely recommend thinking
more about shutdown workflows.

~~~
twic
> If your code is crashing more often than it is gracefully shutting down, you
> have a problem.

You have this exactly backwards. If your software crashes rarely, you have a
problem - when it _does_ crash. Because then it's doing something you aren't
routinely and thoroughly testing by doing it all the time.

This is an old, counter-intuitive, but powerful idea - if you're not familiar
with it, start with this paper:

[https://dslab.epfl.ch/pubs/crashonly.pdf](https://dslab.epfl.ch/pubs/crashonly.pdf)

------
ksec
The first thing that caught my attention;

 _Tom Doron is a member of the Swift Core Team and the Swift Server Work
Group. He manages a team working on server-side Swift libraries at Apple._

Server Side Swift ? At Apple?

I thought IBM gave up on working Server Side Swift and that was it.

~~~
trevor-e
I think Apple is pushing for the same thing that helped NodeJS get really
popular: using the same language across your entire stack. In a perfect world
Apple can have their devs use Swift to build an iOS/macOS app or help out with
server-side code also written in Swift. For a company their size it could
really pay off. I think Google had the same vision with Go but ultimately
failed (imo).

As an iOS developer I'm really excited to use Swift more and more outside of
app development.

edit: to clarify a bit more, I think Apple's vision is a lot more than just
being able to build a small web app in Swift. They really want to build
_everything_ with it.

~~~
pjmlp
Google had no vision with Go, it was just a group of well known developers in
the UNIX world that got fed up waiting for their C++ compile times, with a
supporting manager that decided to fund their work.

Google is pretty much Java and C++ alongside their infrastructure, and OSes.

K8s prototype was started in Java and migrated to Go after some Go aficionados
joined the team.

Besides k8s, you have Google download service (because someone from Go team
bothered to port the service to Go), gVisor, parts of Android GAPI, the new
internal Android build system, gVisor, and Fuchsia TCP/IP stack that
apparently should be rewritten in C++/Rust.

And that is about it, as much as it comes outside.

------
pornel
It's interesting that this gets an official blessing. It isn't something
integrated with the Swift language, just a bit of code that could be a regular
package.

~~~
jmull
I think they are trying to establish a common approach to foundational
concerns.

That makes sense to me, though I see the risk. There's a big benefit to the
community as a whole if standard concerns are handled in a common: developers
will become experienced with them and understand them in deep ways. Tooling
can target them. Documentation and other learning materials can become wide
and deep.

The risk is that potentially better approaches have a very high hurdle to
overcome the "official blessing" to become more than a niche option. That's
good and fine for alternatives that are only incrementally better or better in
some ways worse in others. But sometimes a significantly lacking "official"
approach holds back an overwhelmingly superior non-official approach.
Hopefully the Swift Server Work Group will keep that from happening or at
least not for too long.

------
_pmf_
That's the kind of language integrated cross-cutting DI that I always wanted.

