Server swift develop

Recently, I have heard many voices: the news that swift on the server is going to die. The development of swift on the server is really slow. I hope you can discuss the reasons for this result, so as to make swift better.

4 Likes

Citation needed.

1 Like

To clarify here, because my original post is tongue in cheek but not constructive, I think there are many in the server side Swift community who would disagree both with the idea that it's going to die and that development is slow. So I think that before any constructive conversation can happen here we'll need to define what those two assertions really mean.

6 Likes

I don't care much about rumors, but there are indeed some news which are predestinated to trigger those:

https://docs.vapor.cloud/shutdown/

Of course you can say that both don't matter, I can hardly interpret those events as good news for Swift on the server...

1 Like

I don't know what triggered IBM's decision to step away from server side Swift (and presumably Kitura), but I wouldn't be entirely surprised to hear that Vapor influenced that decision, as it's been more of "the talk" than Kitura, and solidly developed.

In addition, I would be careful of asserting that a server side framework (Vapor) wasn't working because the hosting business that was created alongside it wasn't panning out as being effective. Today there's a lot of additional options to host swift running on a VM or within a container with Vapor that don't require a specific hosting environment to enable it. The comment in the shutdown announcement actually implies just the opposite:

Going forward, the Vapor core team will be concentrating its efforts on the framework and all of its open source packages. This includes new, free guides for deploying to platforms like Amazon Web Services, Digital Ocean, and Heroku.

I read this as directly implying that the large commodity hosting solutions were easier to use, and that the investment in a specific hosting provider wasn't panning out as effectively as they'd originally hoped, so they're dropping the hosting avenue and focusing their efforts on the framework itself to help accelerate and speed development.

7 Likes

I mean it's a lot of coincidental evidence, none of which is by itself conclusive, but which all together don't paint the brightest picture of server-side Swift. Apart from IBM pulling out and Vapor Cloud shutting down, there's also a whole other set of issues (e.g. see my post in the Rust vs. Swift thread), and overall, it just doesn't look like server-side Swift is experiencing huge adoption. Even on this forum, discussions about it are quite rare, the related subreddit is all but dead, the general subreddit is basically iOS-only and the most popular discussions on HN are generally several years old. You can say about these "metrics" what you will, but there doesn't seem to be a huge excitement about server-side Swift.

The most active discussion forum I know of is the Vapor Discord. It’s not some surprisingly massive underground community, but it is definitely active and definitely excited.

1 Like

Vapor Cloud and Red shutting down is a ultimately good thing for Swift on the server. We wouldn't have made the decision to do it unless we believed that 100%. That's not because we were disappointed in the products or they were underperforming either. We felt the products were received well and we were impressed by their performance. They are just not the most efficient way for us to support ourselves at the moment.

This is bizarre to me since from my perspective at least things are busier than ever. I guess we could try to do a better job of posting on the forums and Reddit but honestly I'd rather focus on improving the framework. Making sure that people enjoy using Vapor is what's important to me.

13 Likes

Without wanting to diminish any of your effort going into Vapor, I want to point out that an inside perspective (development on Vapor is busy) can be quite distinct from the outside perspective (how much does the general development community engage with server-side Swift).

But, point taken: just because the adoption of server-side Swift is limited (and it definitely is: most developers I talk to don't even know that it's a thing), it doesn't mean it's dying. Sometimes, very dedicated and quite small communities can live healthily for quite a while. But it's definitely a tradeoff (in terms of fewer libraries, fewer tools, etc.) that one has to be willing to make.

Can confirm.

From a half distance macro perspective it looks aka feels like Swift server-side is not really getting a lot of traction and it makes more sense to learn & invest in already established "web-tech".

Macro impression is also that SwiftNIO is a strong base-tech which helps the eco-system but overall swift on server is too low-traffic and low-interest after that many years to expect it to establish itself as a relevant web-tech-variant anytime soon or maybe ever.

It does feel like it is viable to use for small / local / private projects if one already knows or really likes swift but not really beyond that. I might give it a try for a small private commercial product if it came to that.

All this from the perspective of someone who developed for iOS/macOS in ObjC and Swift for a few years and started to learn WebDev in the last year and chose JS/TS/React/Angular/Node/Express instead of expanding that to Swift on the Server because it feels unlikely that clients are interested in Server-Swift in the first place or could be convinced given the overall appearance of its viability / adoption as a serious tech-option.

/2c

1 Like

Perhaps I can share some insight from the other side of this (very involved, working in it daily).

I am the CTO of a site that serves hundreds of thousands of users and millions of requests in a highly regulated and data-sensitive industry. We use Vapor to power everything that we do. While I agree with the point that it can be hard to remove yourself from the bubble once you're in it, I also think it's worth noting that there is a lot of stuff happening inside of that bubble. Many cool projects and new companies are using SSS and show no signs of slowing that down.

When I start to feel anxiety about the state of the ecosystem, the packages available, etc, I just remind myself that the large web frameworks used in massive contexts today were born the same way. People put their faith in DHH for Rails and in Taylor for Laravel - two projects which now power a considerable amount of the web (including this very forum running on Rails!). After all, Vapor is barely 4 years old.

For me, SSS is an exercise in betting on the future - that means I (and many others) could be very wrong, but I don't see it happening. I have faith in Tanner (and the rest of the Vapor team) the same way that others did with their own framework developers.

Sorry for the slight ramble - I wanted to provide context for my own beliefs about the state of these projects :)

11 Likes

I'd be interested to know what timelines you are comparing Swift to and I'd challenge they are fair comparisons. For reference, Vapor's 1.0 release was closer to 3 years ago and that was starting from absolutely nothing. Not even a networking layer. Laravel's 1.0 release was 9 years ago and they started from a very established ecosystem building on top of Symfony. Express.js's 1.0 release was 10 years ago and they were able to build off of Node.js which was initially released in 2009. SwiftNIO is not even 2 years old yet! The first version of Vapor built using SwiftNIO was 3.0 and I'd argue that's a more fair "1.0" to use for comparisons to other languages. Swift itself is also incredibly young compared to PHP, JavaScript, Ruby, etc and Swift still has lots of pain points to work out with things like memory ownership, generics, and coroutines. Tooling around Swift on non-Apple platforms has a lot of work to do as well. Things are still very young and too much growth too quickly is not good either. I think the rate at which Swift on the server is growing at the moment is fine and as long as we focus on making the software compelling, we don't need to worry about anything else.

10 Likes

Reading this adds a virtual +1 to the ambient impression i have.

I understand you are deeply involved, but my post really was not supposed to be a fair and balanced result of an in-depth analysis and comparison; ) Just an ad-hoc hex-dump of my current impression.

Hmm... Not exactly sure what you're implying here.

1 Like

I tried to say that this sounded positive to me :slight_smile:

P.S. I am not a native speaker and apparently i went with too much flourish there.

Ah - I see. Glad to hear it :) Feel free to reach out if you ever get involved, I am also @mcdappdev on Discord.

1 Like

I think some of the recent major advances in compiling Swift on Windows, WASM, and Android will significantly increase the demand for Swift on the server. Additionally, Swift Package Manager keeps improving and thus the ability to share code between platforms is getting easier as well. I do think Async/Await is a very important piece of the puzzle but Rust only just released their implementation. I think Server Side Swift has still has great potential. The community just need to keep at it and continue to bring more and more developers into the fold!

5 Likes

I think the development of swift on the server is really very very very slow. Now, what can swift do? Actually Only used to develop app on iOS platform, but we still have OC, Dart(Flutter)....

Can you talk about why development of swift on the server feels very slow? What other tech are you comparing it to?

Also tagging @shuishangmusheng because they made a similar point.

Terms of Service

Privacy Policy

Cookie Policy