I have deployed my backend on a tiny DO droplet using Docker, and it just works. There was a slight bit of learning curve for deploying it, but I can now create images locally on my Mac and pull them remotely for a fresh deployment/migration in less than a minute. Being able to build locally using Docker for Mac also means that the speed is great.

Before that, I had the app live on a Heroku setup but it cost quite a bit.

My app is at https://apps.apple.com/nl/app/instint/id1454800508

Inter-op with various web-services is often quite a headache too. Sometimes there's support for Swift or even an official SDK, but it's often not so straightforward to actually get it working. You're definitely in untreated territory here, and it shows.

So we moved NodeJS. I feel Node is a meme at this point, but man does it simply work. There are code snippets for everything and usually it doesn't take longer then 30min to figure out how to do something.

Some other (well known) quirks are:

-- Forced code formatting for everything. If you don't like it you'll probably never like it. It's mostly a problem if you're switching languages often.

-- Lots of little things you'll stumble on that have to be internalized. Loop parameter scope, variable shadowing, randomization of map iteration, the way slices spring to life but maps don't, colon-equals with multiple variables, no unused variables, etc. There are lots of "Go Gotcha" lists around and I believe there's even a book about them. Every language has them but they're especially noticeable in Go because (1) the rest of the language is so easy to pick up that they tend to stick out and (2) they can't be fixed because Go has a backwards compatibility guarantee that no breaking language changed will be introduced.

Anyway, I really enjoy Go. None of this is enough (IMO) to prevent anyone from at least giving it a try and seeing how it suits them.

Besides that, I like the language to some extent.

- checking for "if err != nil {" boilerplate

- having $GOPATH instead of using the current directory when setting up a project. This one is not a problem anymore I believe.

Other alternatives would be Kotlin, C#, Go, or even Java.

We (Transeo [1]) use Swift and Vapor to power our application which serves millions of users and regularly hits 20k requests per second. We're running on substantially less hardware than we budgeted for, which is great, and the performance is also notable - our p99 response time at peak rps is ~250ms.

That being said, performance isn't the only thing that you should look for when choosing your backend language/framework, as you've noted. We've been using Swift/Vapor for more than 5 years now so we've seen the community grow alongside it, and I am really excited about where it's going. While the ecosystem at one time was a bit of challenge (in terms of finding a package to do something, etc), over the last ~2 years we have rarely run into problems finding code snippets or packages to accomplish our tasks. We do a lot of bulk CSV processing (hundreds of gb's at a time), SFTP transfers, PDF generation/merging, calculated database locking, all of which has been relatively seamless ecosystem-wise. Check out the SSWG projects [2] for some more cool stuff happening in the ecosystem.

Hiring has been fine as well - we have a number of developers on the team that did not have Swift or Vapor experience coming in and were able to map other frameworks on top of it and pick it up quickly.

All of that being said, I will admit that I am biased on this topic :) Frameworks and programming languages are merely tools in your tool-belt, and different tools are right for different workloads.

[1]: https://gotranseo.com [2]: https://www.swift.org/sswg/

Regarding Swift I am not sure how popular it is for the backend, you might not have a lot of libs for example for doing common things. Also no idea well a Swift backend performs under load. Swift is a nice language for sure, maybe if you can risk it, go for it but keep also this in mind - https://boringtechnology.club/

If you really really need something high-performance, then Rust is the main contender. Don't be fooled by superficially similar angle brackets syntax. It's not similar to C++, it's is not even a C-family language (closer to ML). Things like having multiple string types may seem like the same mess, but it's not a legacy baggage like in C++, but an explicit meaningful choice exposing ownership and encoding semantics.

If you merely need pretty good performance, go for golang. It's very successful for services.

I don't see room for Swift in server-side languages. It won't be able to shake being Apple's technology first, and having Linux support as a second class. It's not low-level enough to beat Rust on performance. It can't compete with popularity and ease of use of JS/TS and golang.

I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.

So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.

Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.

> a performant, statically-typed, systems programming language.

What is your project about? What are the latency requirements? How many concurrent users you expect to have? If these numbers are not high, why are you not using a general purpose language like go or Kotlin?

I used vapor for a evaluation project a while ago and abandoned it quickly. While Swift is a nice language, it is still a 2nd class citizen on non-Mac systems.

You can do a small PoC project and see if you like it.

What makes it a second class citizen?

Things do get better with time and developing for the server with Swift is a great experience, but it still feels a bit early.

For more popular languages you get predefined templates for serverless platforms and compiled binaries directly in the linux distributions default repositories.

In many ways the outside interest in swift died down even quicker then the interest in running ObjectiveC outside of the Apple Ecosystem did, and as the Apple ecosystem don't include an server platform all swift server-side code is running outside of the apple ecosystem.

The problem likely isn't that swift is bad just that it's unremarkable once you take it outside of an iOS context.

Such a squandered opportunity on Apple's part. In the early years, the Swift team talked a big game about wide industry adoption goals, but multiplatform seems to just be a defeated box-ticking exercise now.

People say Apple are an unstoppable marketing machine, but they did an absolutely horrific job of engaging the wider software development community with Swift.

The community tries to expand swift's horizon with all its heart, but as long as apple is the main force behind the language there's going to be no real incentive for it to become a serious contender on other platforms.

I'd recommend go, if it's a serious project you plan to maintain for years.

You should check out Kotlin. Design-wise, it's very similar to Swift, but it has a bigger userbase on the backend and an (imo) more promising future.

Kotlin is probably a few years further into its journey. There's some server-side Kotlin being written, but I wouldn't say a lot.

Asked differently, why are Java (or a mature JVM language) or C# not a good fit?

OP wants a systems language.

OP is describing they want to write a backend, not a operating system. "Systems language" might have been a "kinda" specifier, rather than precise.

Go, Kotlin, C# or even Java works just fine for backends. If I were OP, I'd use whatever I know best, or is the most similar to what I know best. Unless I want it to be a learning experience, they I'd chose the language that is the least similar to the languages I know.

And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.

For myself, I won't use it on the server, but that's because I write servers for relatively low-cost, limited-skill, demographics. I use PHP.

[0] https://www.objc.io

[1] https://talk.objc.io

Java is the "obvious" choice for statically typed web backends. Personally I'll recommend Go and C#. Both have a low learning barrier to entry, check your boxes for backend languages, and have ample resources online. I would choose C# (on ASP.NET Core) if you want flexible typing and inheritance, and Go if you want "simple" imperative code. Rust is also popular but I don't know enough to comment on it.

If you intend to make money and or invite a team into the project over time then maybe look for something lots of people use (.Net Core, C++, TypeScript, Java, etc.)

If you want this project to be a labor of love that is mostly powered by you then pick whatever esoteric thing you want that fits the bill (again sounds like you know the options, Rust, Crystal, Nim, Server Side Swift, etc.)

Swift is a really nice language, much easier to skill up than Rust and MUCH better ergonomics, but again, IBM pulled out and the working group moves at a glacial pace...

I'd be curious to hear as well if there are any corps quietly relying on it.

Crystal (like Ruby but fast and statically typed)

D (a "better" C/C++ with GC)

Pascal (a C/C++ competitor which has fallen out of favor, but is still being developed as FreePascal)

It’s been mostly great. Only downside is the server-side swift community is smaller than others, so you don’t get the deep software library selection something like Python would have.

You can say the same for Swift. But just like with C++, you can always stick to simpler and smaller subset and make great things with it.

See Very Good Ventures own Dart Frog:

https://github.com/VeryGoodOpenSource/dart_frog

Rust 1.65 didn't add a new feature, it removed a limitation on an existing feature.

That's the direction I want my languages to be going in.

Over 200 memory safety issues were found in public crates in rust.

If code reviews were all it took to ensure memory safety, then we wouldn’t need the borrow checker in the first place.