
Swift Server Work Group Annual Update - Austin_Conlon
https://swift.org/blog/sswg-update/
======
echelon
Swift isn't comfortable to use on non-Mac platforms. Because of this I can't
see it taking over from Go or Rust in the server space. (I mention Rust
because the language type system feels similar to Swift's and Rust is gunning
for the same server space.)

If the Swift folks want adoption, they're going to have to think about the
broader developer ecosystem. There's also an inherent mistrust in Apple that I
think a lot of engineers have. It feels a lot like Google Dart in this
respect.

~~~
favorited
I'm not sure why the discussion is always framed as Swift vs. Rust vs. Go.
It's not like any of them are the dominant backend languages.

Swift can be a great choice for backends for lots of reasons (shared code
between client and server, client devs become full-stack devs, etc.), and it
has its drawbacks as well.

This idea that for Swift to thrive as a server language it has to win some
contest against Go and Rust makes absolutely no sense to me.

~~~
wlesieutre
If anything, the comparison I'd make is javascript. Just like Node, it's a
nice notion that you can take your client language and use it on a server.
Aside from that, does anyone think that javascript is a _good_ language choice
for backend development?

Swift has a lot more redeeming aspects than javascript does, but like this
post acknowledges, they don't have its package ecosystem.

~~~
skohan
> they don't have its package ecosystem.

I think in some ways this is a chicken-and-egg problem. If people start
working with Swift in the server space, that ecosystem will quickly evolve.

Also, Swift has great interop with the C FFI, so you have access to every C
library, and every Rust library with a C API to boot.

edit:

> Aside from that, does anyone think that javascript is a good language choice
> for backend development?

I write a lot of swift code for personal projects, largely because it's so
nice to program in, and I actually think it could be a great choice for back-
end development.

I think Swift offers many of the same advantages of Rust in terms of a robust,
powerful type system, and the feeling that if your code compiles, you're
probably not going to have too many runtime errors (as long as you followed
the rules).

Swift makes tradeoffs in favor of developer ergonomics where Rust chooses in
favor of performance. In the vast majority back-end cases, Swift's performance
will be good enough, and it's ease of use lets you have many of the advantages
of a language like Rust but with the improved productivity of working with a
higher level language.

~~~
eptcyka
>Also, Swift has great interop with the C FFI, so you have access to every C
library, and every Rust library with a C API to boot. I can think of maybe 3
Rust libraries that I'd want to interface with through their C api.

------
rnantes
I love Swift and I think it could be one of the best languages on the server.
However here are a few things that I think would make it better:

\- Async/Await

\- Swift and Swift package manager support on Windows

\- Swift Package Manager resources and run scripts

\- Backtraces

\- Faster/incremental builds

~~~
NobodyNada
> Async/Await

There's some long-term plans for concurrency:
[https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782)

IIRC the compiler already has internal support for coroutines. Unfortunately,
I think it will probably a long time before we get user-facing features like
async/await.

> Swift and Swift package manager support on Windows

Swift works on Windows with all tests passing, though I imagine it's still a
lot of work to compile and run (but I haven't checked).

> Swift Package Manager resources and run scripts

I agree this would be nice. Swift PM doesn't really give you much flexibility
right now.

> Backtraces

Discussed in the article (section Swift Backtrace):

> This package provides support for automatically printing crash backtraces of
> Swift programs on Linux. Backtraces are generated by a builtin C library
> libbacktrace and demangled using a private Swift runtime call. We hope to
> improve the implementation by adopting SE-0262 when it is approved. We are
> also working with the Swift core team to discuss the benefits of merging
> this functionality into the Swift standard library.

> Faster/incremental builds

Swift has pretty good incremental builds, especially compared to the early
versions. Compile times are _way_ better than they used to be and are
continuing to improve.

------
conradludgate
I work for a startup that uses swift as a server language. The original idea
was that both ios and the server would use the same object model which made
life easier. Sadly that didn't scale as they started the android app.

We're migrating away from it slowly as we make more microservices but it's
been an interesting experience.

It was my first time using swift as I am a server engineer and not an ios
engineer.

Its definitely lacking in tooling and libs but it's a really nice language
with a good type system (it's not great though but it's easy). It definitely
has potential to be a really good server language. I'd be more comfortable
using go or python but it's more fun using swift

~~~
mdev
IDLs and schema/contract definitions in common places should help with this.
Stuff like protobufs are good at generating code to use/translate to object
models as well.

The primary motivation for choosing the language should not be sharing object
models, atleast IMO.

------
mickael
I am writing this from the Server Side swift conference. Despite what is said
in the comments, I do not see a community waiting for Apple to push the
server-side ecosystem further. What I see is a group of passionate people
building plans to move the ecosystem forward. Yes, it is still easier to
develop on MacOS than on Linux (but it is doable). Yes, having the async/await
feature in the language sooner than later would help. However, the community
seems healthy and the projects are interesting and well designed.

~~~
jamil7
I'm using vapor on a production app and really enjoying the experience. I do
see there is a lot of work to do in the community though. Where would one
start out to help with the efforts?

~~~
mickael
I would start by both getting involved in the server part of the Swift forum
([https://forums.swift.org/c/server](https://forums.swift.org/c/server)), and
by checking simple tickets you could help with on those projects Github.

------
elpakal
Hey Tanner - there's a typo right away:

We believe that a healthy open source ecosystem relies heavily on the quality
its packages -> We believe that a healthy open source ecosystem relies heavily
on the quality _of_ its packages

------
jaunkst
No thanks.

------
trollian
Still no plans for concurrency? Such a waste.

------
Redoubts
Not gonna lie, this logging api is a howler.

“””

Good:

logger.info("hello world")

Bad:

let message = "hello world"

logger.info(message)

If you have a String that you received from elsewhere, please use

logger.info("\\(stringIAlreadyHave)")

“””

Ugh.

And the payload field (think extra= in python logging) is pretty gross, you
can’t even pass a [String: String] dict. Got help you if you want to dump your
structured logging/data into splunk.

