Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pushing Swift to the Server

skilled.io

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Pushing Swift to the Server

#81

Post by mahyarm »

Entangled wrote: post #57

For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…

You can do that today with iOS apps theoretically too & just use command line xcodebuild. You'll be missing all of the IDE things that swift is struggling with although.

Re: Pushing Swift to the Server

#82

Post by pjmlp »

geodel wrote: post #80
pjmlp wrote: post #74

Earlier quoted context omitted.

According to Mark Reinhold, Sun designed JNI to be hard on purpose, to discourage developers to write native code. He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones. Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code fro…

Interesting talk. Go folks also probably want cgo similarly difficult to use. Though for them I guess it will work, as they have already written compiler/GC/runtime/ssl etc in Go plus some asm.

I never understood why cgo was an option instead of doing what most languages do.

The only reason I see, was having an easier way to parse header files.

Re: Pushing Swift to the Server

#83

Post by mahyarm »

echelon wrote: 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.)

I don't use swift in a backend context, but from the iOS side:

* The debugger & indexer fails often.

* Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems.

* Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so.

* You also don't have full control over your build chain, and decisions made by apple xcode can screw you over in when they change something in an update.

* Migrating your code from one version to the next can be a multi-week event.

I wouldn't use swift until it matures as a language in a few years. On backend you rarely need something that is not garbage collected. I would stick with python, golang & java. Maybe use rust or C++ if you need it.

Re: Pushing Swift to the Server

#84

Post by mahyarm »

kawsper wrote: post #27
echelon wrote: 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/

They really should be comparing against golang and java.

Re: Pushing Swift to the Server

#86

Post by JimDabell »

jstapels wrote: post #61
wmil wrote: post #31

Earlier quoted context omitted.

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…

https://www.jetbrains.com/objc/

AppCode only runs on macOS and requires Xcode to be installed. It's no help to people who aren't running macOS.

Re: Pushing Swift to the Server

#87

Post by valuearb »

mahyarm wrote: post #83
echelon wrote: 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.)

I don't use swift in a backend context, but from the iOS side: * The debugger & indexer fails often. * Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems. * Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so. * You also don't have full control over your build chain, and deci…

I've been developing on iOS for 7 years and Swift for 3. (Half of my 8 store APIs are in Swift)

While I agree with most of your criticisms I'll say it's never taken me more than an hour to update any code base when Swift versions change, it's a mostly automatic process.

Also I'd say anyone doing iOS development in Objective C instead Swift nowadays is doing themselves a grave mis-service. It's much easier and faster to build higher quality apps in Swift.

Re: Pushing Swift to the Server

#89

Post by mahyarm »

valuearb wrote: post #87
mahyarm wrote: post #83

Earlier quoted context omitted.

I don't use swift in a backend context, but from the iOS side: * The debugger & indexer fails often. * Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems. * Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so. * You also don't have full control over your build chain, and deci…

I've been developing on iOS for 7 years and Swift for 3. (Half of my 8 store APIs are in Swift) While I agree with most of your criticisms I'll say it's never taken me more than an hour to update any code base when Swift versions change, it's a mostly automatic process. Also I'd say anyone doing iOS development in Objective C instead Swift nowadays is doing themselves a grave mis-service. It's much easier and faster…

Apple's target is the 1-5 person developer team with maybe 50kloc of code & 1 mac mini acting as a CI box. Xcode scales ok in these cases.

Backend development tends to feature a lot more developers with a lot more code. Swift starts getting really painful when you hit those numbers. Go look at presentations done by larger swift codebases like linked-in, uber, lyft & airbnb to see where it starts happening.

Re: Pushing Swift to the Server

#90

Post by coldtea »

valuearb wrote: post #88
coldtea wrote: post #51

Earlier quoted context omitted.

Obviously because you don't want to have servers running OS X?

Swift on Server runs on a Linux.

I know that. The parent asked why it matters that it's multi-platform.

Hence my answer: that it matters because if it wasn't, then you'd have to run Mac OS X to use Swift on the server side.

Post reply on HN