Live data from Hacker News

Ask HN: What is the future of Swift on the server-side?

news.ycombinator.com

41–50 of 60 posts

Re: Ask HN: What is the future of Swift on the server-side?

#41

Non-existent unfortunately. Swift hasn't taken off outside of the Apple ecosystem, which is of course heavily client focussed. If you like the look of Swift, but you're writing backend code then I would definitely recommend Rust. It's actually super nice to work with. Not at all like C++. Other alternatives would be Kotlin, C#, Go, or even Java.

I‘m also a rust enjoyer but if OP is a swift fan, I’d say kotlin feels the closest to swift

Re: Ask HN: What is the future of Swift on the server-side?

#42
post #30

Google's Go language is well suited for back-end code. However, it's a very opinionated and quirky language. If its style suits you it's a great choice. If, after looking at it for a bit, it doesn't sit well then nope.

What did you find to be quirky?

Not OP, but at the very beginning I found quirky:

- 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.

Re: Ask HN: What is the future of Swift on the server-side?

#43
(Disclaimer: I am a member of Apple's Server Side Work Group (SSWG) and these opinions are mine and mine alone)

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/

Re: Ask HN: What is the future of Swift on the server-side?

#44
post #30

Earlier quoted context omitted.

What did you find to be quirky?

Not OP, but at the very beginning I found quirky: - 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.

Ah ok. I see those a lot and was just curious if there was anything new or unresolved. It's a fine language. If you enjoy Rust or Zig, I'd recommend it on your day off.

Re: Ask HN: What is the future of Swift on the server-side?

#45
post #40
post #38

Swift on Server has become quite mature over the past years. The ecosystem features a libraries for a lot of tools you want to integrate. Furthermore, it is being used in production by some major companies besides Apple, e.g. Amazon has a bunch of production services running on it. One of the greatest things about Swift on Server is not only the language but also the community. They are very open to new joiners and t…

Source on Amazon running Swift services? Excuse my doubt, but I've never heard of that and it seems very unlikely to me.

https://twitter.com/tachyonics/status/1565647722341748737

Re: Ask HN: What is the future of Swift on the server-side?

#46
I have a couple which others haven't mentioned yet. I have very little/no experience with them, but what I have read about them matches your criteria, so they might be worth a look.

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)

Re: Ask HN: What is the future of Swift on the server-side?

#47

> What are the other alternatives, Nim? 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 similar to Swift: a language mostly famous for mobile apps, but with ambitions to be a general-purpose backend language.

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.

Re: Ask HN: What is the future of Swift on the server-side?

#49

I think you're misinterpreting the direction of Rust. 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.

My current problem with rust is the dependency hell. Hundreds of sub dependencies for every top level one. Yes some of them are super common like serde or rand, or oddly some crate that seems to be just to create directories on the filesystem?! A blessed subset of crates is what I was counting on to save the day, but when something like tonic brings in 100 or so fine grained one-off sub dependencies I don't think that can work. Right now I am just plugging my ears saying "my code is memory safe and I am fearlessly concurrent!" But I am thinking "what horrible thing is lurking in the depths of my dependency tree and which state actor put it for later?" If that seems paranoid look at the recent issues with pypi malicious packages. I know I can roll my own, but that cost money, and if tokio or tonic didn't exist, and crates wasn't so darn easy to use, maybe google would have made a monolithic grpc crate instead?
Post reply on HN