[afavour]

Chicken/egg, I think. There was a burst of activity of Swift on the server a few years ago and frameworks like Vapor seem like they’re still pretty active:

https://vapor.codes/

But I think “why” remains a valid question when you could make a safe pick like Node, Python etc. I really like Swift as a language but I’d still struggle to justify using it outside of iOS.

[wlesieutre]

There were three major server side Swift projects, and Vapor is the surviving one from that era

Dead projects are

- Kitura https://github.com/Kitura/Kitura

- Perfect https://github.com/PerfectlySoft/Perfect

Don't know of large organizations using it in production, the vibe I get is that it's useful for an iOS developer who wants to deploy a small server for their product without learning Python or Javascript.

You could certainly use it at larger scale, but you have to justify giving up the big ecosystems of its competitors.

[fastily]

There’s also hummingbird: https://github.com/hummingbird-project/hummingbird

[wahnfrieden]

Sadly this project is getting steadily slower. Adopting async made it slower than Django. But this is due to Swift limitations. Hopefully Swift replaces Codable and improves async performance.

[KerrAvon]

Swift is a peer to Rust, not Node / Python. It has some nice affordances that Rust doesn't, while still being a native-compiled language.

[morshu9001]

It's more of a peer to Go

[afavour]

In the case of Vapors (building "HTTP servers, backends and APIs") I'd say Node and Python are absolutely alternatives.

[myko]

So is https://gotham.rs/!

I think they were just talking about the language features, not building web services generally

[ux266478]

Swift is absolutely not a peer to Rust. Even without GC, Swift comes with a substantial runtime to enable a lot of features that precludes such a comparison like everything to do with messages and actors. With regards to safety, Swift's data isolation system is cute, but isn't comparable to a substructural type system at all, and it's useless if you're not writing code that uses actors.

Most of what makes Rust's safety powerful is that lifetime analysis is universal and highly granular. Things like no dangling references to local variables, no 'collection cycles', handling parametric code, etc. are basic features that Swift can't provide. On top of it all, the whole system is ruinously complicated compared to Rust's type system. That's the sad reality of what happens when you try to implement something so fundamental as an extra bolt-on to a language that can't properly accomidate it.

[cosmic_cheese]

On the other hand, Swift has a more gentle learning curve with plenty of progressive disclosure (many features aren't strictly required to build something useful) and generally more approachable syntax.

Swift is also more conducive to "old style" retain mode imperative UI frameworks like AppKit (sometimes declarative and/or immediate mode doesn't fit the bill), which has to date been a major weak point for Rust.

[ux266478]

For what it's worth, I'm not an active user (or fan) of Rust. I've just used a lot of languages, it's a hobby of mine to learn new tools.

> a more gentle learning curve ... and generally more approachable syntax.

This is all the more reason it's not a peer. The heavyweight class Rust belongs to (which includes things like Sepples, ATS, Ada/SPARK, D) are as a rule not approachable things. All of them are serious industrial tools whose target audience are experienced professionals that prioritize extremely broad functionality and flexibility in output. What the input looks like, or the cost of learning to operate these tools is not even a consideration for this audience. Swift doesn't fit this bill. It simply compromises too much for things that this class of language isn't concerned with. People reaching for a new language in this class aren't thinking about how easy it is to learn, or even how nice it is to use. Rust abandoned ML-family syntax to babyduck C++ at massive cost to its "niceness".

On syntax, do you mean semantics? Syntactically they're both generic curly-brace algol stuff with minor differences at best. Semantically Rust is certainly more complicated.

> which has to date been a major weak point for Rust.

It's very ironic, given Rust's original purpose was to replace C++ as the implementation language for Firefox. Retained mode GUIs have unfortunately fallen by the wayside due to a number of factors, it's not just unique to Rust. If a language hasn't inherited a legacy retained mode lib, it's not likely it'll get a decent one unless it's really lucky. Unfortunate, because you're right, retained mode GUIs absolutely have their upsides and web browsers aren't a solid replacement. They're just complicated to implement, and computers are fast enough now that the much simpler immediate mode paradigm is the choice for every new framework being written. It is what it is.

[zerr]

Does not support Windows.