Live data from Hacker News

Pushing Swift to the Server

skilled.io

31–40 of 109 posts

Re: Pushing Swift to the Server

#31
post #5

Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)

While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time.

The target market is really iOS devs who want the same language on the back end.

That's a perfectly reasonable engineering goal for an iOS-first shop.

But they're a vocal group and like to hype up server Swift as the next big thing for everyone. That's just not going to happen.

Re: Pushing Swift to the Server

#32
Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.[1]

I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.

Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can run, but that's it. Other than that you are on your own. No UI libs, nothing.

This leaves you with iOS if you need to run on mobile which is extremely restricted. Want to freely distribute an app among your colleagues on the lab? Fuck you. You have to do all sorts of acrobatics with testing devices, provisioning certificates, etc.

In Android you just compile an .apk and send the link to your colleagues to install it, like in any other platform on Earth except iOS. Even macOS.

[1] http://www.apple.com/ipad/business/work-with-apple/ibm/

Re: Pushing Swift to the Server

#33
I recently rewrote a server that I had in Kotlin and really happy with the results. With this I am pleasantly surprised! I already liked the syntax, and now it gives me another reason to try it out. I am not sure though how would it compare with Go.

Re: Pushing Swift to the Server

#34

Why? Why choose Swift over a language with an established framework ala python, ruby, ASP.NET, Node.js ?

Agreed, every languages do established and growth into a mature language. Swift was born and constantly learns every languages for the last 30 years of pros and cons including Rust, Go and Ruby.

Swift is built on LLVM (Compiler designer) and CLang which both are developed by the same group but they do not forget children who can learns Swift from young age for robotics, electronics, 3D and many things could be done with Swift.

More is need to be done on tooling before Swift will be on par as Java and C ecosystem.

In the same analogy, why choose Tesla or electric powered vehicles when other car manufacturers are established? Keep learning and improve it.

Re: Pushing Swift to the Server

#35
post #27
post #5

Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)

The consultancy Nodes reports that their framework Vapor[0] that is written in Swift is "around 100 times faster" than other frameworks written in PHP, Ruby and Python, you can see his bold claim 4 minutes in here: https://vimeo.com/193549098 , but of course no benchmarks have been presented. [0] https://vapor.codes/

Even assuming it's true, that's not an impressive claim. Frameworks in those three languages are not known for their speediness.

If they claimed 1000 times, maybe that would be something worth sitting up to take notice.

Re: Pushing Swift to the Server

#36
post #32

Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.[1] I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS. Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can…

I do not say this to defend Apple, as this is itself a form of "fuck you" "acrobatics" forced on you by Apple, but if you download Cydia Impactor (a program I develop that has a horrible UI which is about to get at least somewhat better in the next couple days), you can drag the IPA file to the device and it will have you log in with your Apple account (even if you are not a registered developer) and can then automate the entire 7-day free provisioning and installation process, helping this use case.

Also, while I am leaving a comment: the server space is different from Android in that 1) you don't need a UI and 2) there apparently is a sponsor working on the open source project (and it is my understanding that IBM is actually putting in more time than Apple) to make it useful there: Ruby is a language that is going to be a problem for you building either Android or iOS apps, and yet that is certainly not a reason to claim it would be a bad choice of language for coding a website backend.

Re: Pushing Swift to the Server

#37
post #17

Earlier quoted context omitted.

It is great convenience for LOB applications when client macOS/iOS app and server backend both written in Swift. Team which knows Swift can be utilized for client/server side of products. I am afraid that Rust might go Scala way where above average smart dev(s) decide on behalf of team what is best technology. Hence only very small teams and individual developers will use it. Larger teams with mixed skills and multip…

This reminds me of "Javascript everywhere". Technically yes, but I don't think that language is a main issue for being able to develop both client and server part of the app. Languages can be picked up in a matter of weeks, concepts like good api design, choosing the right database, deployment etc are the real challenge.

You are right of course. I still think it is great proposition for at least Apple platform. For client side Apple will push it for greatness for server side it is still too early.

Re: Pushing Swift to the Server

#39
post #27
post #5

Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)

The consultancy Nodes reports that their framework Vapor[0] that is written in Swift is "around 100 times faster" than other frameworks written in PHP, Ruby and Python, you can see his bold claim 4 minutes in here: https://vimeo.com/193549098 , but of course no benchmarks have been presented. [0] https://vapor.codes/

I'm not sure how Vapor is ready for production.

Try its hello world locally and then bench it with `wrk`. You'll get a lot of failed requests with a concurrency > 1. (I didn't test concurrency = 1)

Re: Pushing Swift to the Server

#40
post #27
post #5

Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)

The consultancy Nodes reports that their framework Vapor[0] that is written in Swift is "around 100 times faster" than other frameworks written in PHP, Ruby and Python, you can see his bold claim 4 minutes in here: https://vimeo.com/193549098 , but of course no benchmarks have been presented. [0] https://vapor.codes/

Pretty much anything that compiles to good native code can be 100 times faster than "frameworks written in PHP, Ruby and Python". At least if we're talking MRI/CRuby and CPython, and especially without running multiple workers in those languages.
Post reply on HN