9 ms·

Building a Production Server Swift App

137 points by ckurose 10y ago

pietrofmaggi 10y ago
> "Python works okay, but I think Xcode is great because of autocomplete and syntax checks." Well, just say that you wanted to try something new. That's a much better excuse to pick a technology. I think that there are some great tools around for Python, and picking a language because of XCode... I think that one of the major selling point of Xamarin is that you can avoid it altogether :-)
- thesmallestcat 10y ago
  So you speak for the author, or what? Tooling is and always has been dire for Python developers, and the productivity that comes from good tooling is absolutely a valid reason for considering a different ecosystem.
  - brokencode 10y ago
    I think his point was that if you're looking for great tooling, you're not going to find it with Swift/Xcode. Right now it doesn't support automatic refactoring, has limited support for inspecting variables while debugging, and suffers from frequent partial crashes and other bugs. If you want to find great tooling, look at Java or C#, which are both excellent languages for servers.
bigdubs 10y ago
butwhy.gif i get that isomorphism is very helpful long term for larger code bases, and being able to share libraries between your ios and server/backend would be very awesome, but at what cost? there are proven server ecosystems that are going to be much less "innovation token" laiden than swift, surely?
- optimuspaul 10y ago
  Sometimes you do things just to do things. Are you never curious?
- chris_7 10y ago
  The dream of a compiles-to-native-executable language with a strong compiler, probably. Rust would also apply.
- sdegutis 10y ago
  Programmers in general today have significant amounts of freedom to choose the toolchain, languages, libraries, and frameworks they use. That wasn't historically always true, especially because the available choices have been growing exponentially for the past 50 years. Many of us are using that freedom to put our efforts into innovating and pioneering this field to make programming easier, safer, quicker, more reliable, and in general trying to improve every possible aspect of it. I suspect the main motivation is that we just love solving problems, which is why we're still programmers to this day, but another and probably less publicly acceptable motivation is that it helps us get our job done quicker, which in turn theoretically allows us to make more money in the same amount of time, which is a no-brainer.
- ben_jones 10y ago
  Honestly I feel like the big interoperability pitch that was put on NodeJS / javascript was just smoke and mirrors to sell various educational, PaaS, SaaS, consulting, etc. products. I see much the same for Swift.
  - philippnagel 10y ago
    Just an anecdote of mine: I am currently building deep learning software that can run in the browser and nodejs - using the same codebase. While I am sacrificing performance compared to Python, CPP, etc., the ease of setting it up and distributing the computation are worth it for me.
- niklasrde 10y ago
  He seems to be a pretty happy iOS developer. He likes Swift as a language (and I must say having used it in frontend dev it does have some very nice things many other languages often used for server-side development don't come with), and he loves XCode as an IDE. If for their personal use-case it does the job and isn't missing major libraries or so, I don't think why such an endeavour shouldn't be supported? I don't think it's so much about sharing libraries - consuming and creating data is quite different, and backend and frontend work probably shouldn't be duplicated. NB: Some of those 'features' I mean are: - Strongly typed (compared to JS, Python, Ruby..) - Compiles to binary which could bring benefits depending on your needs (compared to JS, Java, Scala..) - Being very new, there's little 'legacy sillyness' in Swift 3. Comparing some PHP sites to Swift projects (Frontend, we don't use it in any backend applications yet) I can tell you which one I'd rather work with.
deleted 10y ago
[deleted]
JoKer_handsome 10y ago
I was set to do some effects on After Effects anyone about this experience Ask yourself (https://goo.gl/Ada79j https://goo.gl/Ada79j)
teddyknox 10y ago
Scala vs. Swift vs. C#. Fight!
- chc 10y ago
  That's a bit like Alien vs. Tintin vs. Predator.
  - optimuspaul 10y ago
    except that obviously Tintin could win, but it's not obvious that Swift would.
- lassofreak 10y ago
  These were compared in a presentation in Spain: https://speakerdeck.com/terhechte/nsspain-2016-developing-app-backends-with-swift-on-the-server https://speakerdeck.com/terhechte/nsspain-2016-developing-ap... Perfect (Swift) won, on the server side...
- shagie 10y ago
  They don't have swift in there yet, and it doesn't look like it supports a three way compare, but... http://hammerprinciple.com/therighttool/items/c-3/scala http://hammerprinciple.com/therighttool/items/c-3/scala
nxc18 10y ago
Its cool that you can run Swift on the server, but that sure does seem like a lot of hoops to jump through, coupled with equally many gotchas. No threading on Linux, NSUnimplemented all the time, no built in random, poorly implemented foundation types, etc. seem like a lot to deal with. It seems a more developed language/runtime (e.g. C#/F#/VB .NET or Java 8) would do a lot better with these specific requirements (typesafe, well-tooled, x-plat, server-side app) than Swift. Especially if you're going to be writing the UI in html/js/css and are thus not anchored to the Apple ecosystem anyway, Swift seems like a bizarre choice. The author seems to like xcode quite a bit, but I don't see it as more competitive or better than any other IDE. Not to mention it does window management and the like differently from everyone else, so when you're getting into it, it feels like you have to learn IDEs, and then you need to learn xcode. I also don't understand why people are so complacent about xcode crashing all the time - if VS Code or VS or Eclipse or IntelliJ ever crashed on me I'd be pretty darn upset.
- matt4077 10y ago
  I recently tried my hand in the macOS ecosystem and I must say I was positively surprised by XCode. It's "intellisence" is incredibly fast compared to VSCode. One argument for Swift is also that Swift is used on the client almost as often as Javascript is.
  - untog 10y ago
    > One argument for Swift is also that Swift is used on the client almost as often as Javascript is. That can't be even slightly close to true. The amount of web code out there already dwarfs native iOS, and the majority of native iOS code out there is probably still in Objective C.
    - colechristensen 10y ago
      I think he's talking about the proportion of swift that runs on the frontend vs. backend. The comparison is like JS in your browser vs. node
- holydude 10y ago
illuminati1911 10y ago
"In server-side Swift, you don’t use interface builder, so that reduces most of your crashes to none." You don't use that in iOS app development either unless you are completely insane or are just beginning iOS development and don't know how to make UI properly.
- adomanico 10y ago
  Am I missing a joke here? Interface builder, xibs and storyboards are very useful tools for even extremely large projects. Makes building and maintaining the UI extremely easy. The idea that because a tool is easy to use is somehow indicative of the skill of the person using the tool, is completely bogus. Interface builder has a lot of advanced features for setting up complicated UI. You could quite easily argue the opposite for someone who needlessly creates all of their UI in code rather then in interface builder.
  - cwbrandsma 10y ago
    I'll chime in, having done IOS apps for many years now...I have fully given up on Interface Builder and Storyboards. I build all my UI in code and find it works MUCH better and I spend much less time fighting with the UI. I used to spend half my time fighting with interface builder to get the layout right. Move one element that something else is constrained too...f' your everything. Oh, and setting up constraints in InterfaceBuilder...don't even. Such an amateur implementation I can't even believe they shipped it. (The code implementation isn't that bad tho) Then wire up my events, if you refactor anything...boom -- but only at runtime. Because the compiler is wired into the process, so if a method/property doesn't exist in the ViewController that InterfaceBuilder is expecting, the compiler doesn't break, your app does. Also add in how often Interface Builder crashes XCode.
    - epx 10y ago
      I was rejected in a job interview quite some time ago, probably because I defended encoding UI in code, instead of using Storyboard. Sometimes destiny saves you from trouble.
eptcyka 10y ago
Is there a reason to use Swift over Rust?
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- pjmlp 10y ago
  Developing for any Apple OS, other than that not really.
- scottostler 10y ago
  I use Swift professionally and have written some Rust for fun, and like both languages a lot. I find Swift to be faster to write, not least because it's easier to manually prevent retain cycles than to write borrow-checker approved code. It's also much easier to leak memory and write unsafe threaded code in Swift, so there's a trade-off there. I'm sure if I wrote more Rust I'd get faster at it, though I do think it has a fundamentally more complicated programming model.
  - eptcyka 10y ago
    Fair. I've yet to write any code for an Apple device, but Swift seems like a nice language. Albeit I'm a massive Rust fanboy.
- steveklabnik 10y ago
  The xi editor is mostly written in Rust, but wants native UI on each platform, and therefore uses Swift for the UI on macOS. This contains an answer to your question, but also, something more subtle: that it doesn't have to be either/or.
- deleted 10y ago
  [deleted]
- kernelbandwidth 10y ago
bushin 10y ago
> let data[String: Any] So typesafe!
matthewmacleod 10y ago
Sounds like it's got a bit of development to go before the language is suitable for this use case, but I must admit I'm quite excited about it. Having recently been experimenting with Go and Rust in the same sort of space, my impression is that Go is a bit too verbose and lacking in features - definitely works and lots of people like that, but I don't find it particularly powerful. Rust is great, but I've found that web backends end up with too much code - and it's still quite a challenging language to use, though that may be my inexperience. Building iOS apps in Swift recently, I've really started to get enjoy using the language. Once the various issues are worked out, I'm optimistic about its suitability for things like that - and it's great to have more language options to play with!
iamjono 10y ago
Going to chime in a bit here... "Avoid #if os(Linux)… When you do this, you lose all help from Xcode. It can’t do syntax checking” ... That’s not correct. Jeff was seeing the effect of something else blocking this from happening. arc4random, yeah, it doesn't exist on Linux currently, but there are other options that are better anyway, like using TurnstleCrypto. For Perfect, there's also a macOS app that aside from helping the process of starting projects, dependencies, building etc - it also integrates a standardized Docker Ubuntu 16 image which also hooks into Xcode so when you build it's also building in Ubuntu and therefore catches linux-specific build issues immediately. Anyway, my 2c. (Full disclosure, I work on the Perfect dev team)
- iamjono 10y ago
  FWIW, if anyone wants to discuss, join us on our Slack channel via http://perfect.ly http://perfect.ly My handle on that channel is, surprisingly, the same as here, @iamjono.
geodel 10y ago
Reading about Swift on server side and looking at Swift server dev mailing list. It appears to me that most appropriate use case of Swift on server side is Apple platform where client side is already written in Swift. The server side group at Apple/IBM seems mostly looking for Swift wrappers around C/C++ core technology for sockets/http/ssl related work. This might be amply sufficient for Apple or IBM developing LOB apps in Swift but I do not see how it is very convenient for generic server side applications.
- fauigerzigerk 10y ago
  I don't see how you can conclude from any of that what the most appropriate use case for Swift on the server side is. It's just what a couple of early adopters are talking about today. For me, the case for Swift is that it is a modern language that doesn't waste half of the available memory on a tracing garbage collector. The same goes for Rust, which has even more opportunities for low level optimization where necessary (and way superior string handling on top of it).
  - geodel 10y ago
    I can conclude that by looking at for example Go offers today vs effort of setting Swift web framework like Kitura. IMO it is far away from general purpose server side usage. As far as memory usage goes Swift does not color me impressed when compared to GC'd language: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
    - fauigerzigerk 10y ago
      Adoption is not the same as appropriateness at all. As far as memory usage goes these benchmarks are completely irrelevant. They use very little memory and they measure it in a way that is unsuitable for a memory benchmark in the first place. The problem with tracing garbage collection is that it requires a lot (~50%) of spare memory at all times to give the GC time to catch up without slowing the program down too much.
komali2 10y ago
> You don’t have to see Linux’s horrible UI. lol excuse me? Actually now I'm thinking, what does he mean by "Linux?" Like, Ubuntu server? Is the UI for that considered bad?
anonyfox 10y ago
I still wonder why i would use Swift in the backend. - elixir/erlang: fault tolerance, scalability, high complexity web apps - Node: npm already has what you need, SSR for SPAs, JS is accessible for frontend guys (sort of) - Golang: dead-easy microservices with CLI support, single file deployments, good performance, beginner level language makes Training/hiring easy - Rust: excellent performance and great typesystem, ideal for writing Heavy core algorithms of products and use them as libs from other languages. Also all benefits of Go (except ease-of-learning). - ... - swift? Given that learning languages is not an issue, why should I prefer swift over other stuff? Are there real selling points?

137 points by ckurose 10y ago

> "Python works okay, but I think Xcode is great because of autocomplete and syntax checks." Well, just say that you wanted to try something new. That's a much better excuse to pick a technology. I think that there are some great tools around for Python, and picking a language because of XCode... I think that one of the major selling point of Xamarin is that you can avoid it altogether :-)

thesmallestcat 10y ago
So you speak for the author, or what? Tooling is and always has been dire for Python developers, and the productivity that comes from good tooling is absolutely a valid reason for considering a different ecosystem.
- brokencode 10y ago
  I think his point was that if you're looking for great tooling, you're not going to find it with Swift/Xcode. Right now it doesn't support automatic refactoring, has limited support for inspecting variables while debugging, and suffers from frequent partial crashes and other bugs. If you want to find great tooling, look at Java or C#, which are both excellent languages for servers.

bigdubs 10y ago

butwhy.gif i get that isomorphism is very helpful long term for larger code bases, and being able to share libraries between your ios and server/backend would be very awesome, but at what cost? there are proven server ecosystems that are going to be much less "innovation token" laiden than swift, surely?

optimuspaul 10y ago
Sometimes you do things just to do things. Are you never curious?
chris_7 10y ago
The dream of a compiles-to-native-executable language with a strong compiler, probably. Rust would also apply.
sdegutis 10y ago
Programmers in general today have significant amounts of freedom to choose the toolchain, languages, libraries, and frameworks they use. That wasn't historically always true, especially because the available choices have been growing exponentially for the past 50 years. Many of us are using that freedom to put our efforts into innovating and pioneering this field to make programming easier, safer, quicker, more reliable, and in general trying to improve every possible aspect of it. I suspect the main motivation is that we just love solving problems, which is why we're still programmers to this day, but another and probably less publicly acceptable motivation is that it helps us get our job done quicker, which in turn theoretically allows us to make more money in the same amount of time, which is a no-brainer.
ben_jones 10y ago
Honestly I feel like the big interoperability pitch that was put on NodeJS / javascript was just smoke and mirrors to sell various educational, PaaS, SaaS, consulting, etc. products. I see much the same for Swift.
- philippnagel 10y ago
  Just an anecdote of mine: I am currently building deep learning software that can run in the browser and nodejs - using the same codebase. While I am sacrificing performance compared to Python, CPP, etc., the ease of setting it up and distributing the computation are worth it for me.
niklasrde 10y ago
He seems to be a pretty happy iOS developer. He likes Swift as a language (and I must say having used it in frontend dev it does have some very nice things many other languages often used for server-side development don't come with), and he loves XCode as an IDE. If for their personal use-case it does the job and isn't missing major libraries or so, I don't think why such an endeavour shouldn't be supported? I don't think it's so much about sharing libraries - consuming and creating data is quite different, and backend and frontend work probably shouldn't be duplicated. NB: Some of those 'features' I mean are: - Strongly typed (compared to JS, Python, Ruby..) - Compiles to binary which could bring benefits depending on your needs (compared to JS, Java, Scala..) - Being very new, there's little 'legacy sillyness' in Swift 3. Comparing some PHP sites to Swift projects (Frontend, we don't use it in any backend applications yet) I can tell you which one I'd rather work with.

deleted 10y ago

[deleted]

JoKer_handsome 10y ago

I was set to do some effects on After Effects anyone about this experience Ask yourself (https://goo.gl/Ada79j https://goo.gl/Ada79j)

teddyknox 10y ago

Scala vs. Swift vs. C#. Fight!

chc 10y ago
That's a bit like Alien vs. Tintin vs. Predator.
- optimuspaul 10y ago
  except that obviously Tintin could win, but it's not obvious that Swift would.
lassofreak 10y ago
These were compared in a presentation in Spain: https://speakerdeck.com/terhechte/nsspain-2016-developing-app-backends-with-swift-on-the-server https://speakerdeck.com/terhechte/nsspain-2016-developing-ap... Perfect (Swift) won, on the server side...
shagie 10y ago
They don't have swift in there yet, and it doesn't look like it supports a three way compare, but... http://hammerprinciple.com/therighttool/items/c-3/scala http://hammerprinciple.com/therighttool/items/c-3/scala

nxc18 10y ago

Its cool that you can run Swift on the server, but that sure does seem like a lot of hoops to jump through, coupled with equally many gotchas. No threading on Linux, NSUnimplemented all the time, no built in random, poorly implemented foundation types, etc. seem like a lot to deal with. It seems a more developed language/runtime (e.g. C#/F#/VB .NET or Java 8) would do a lot better with these specific requirements (typesafe, well-tooled, x-plat, server-side app) than Swift. Especially if you're going to be writing the UI in html/js/css and are thus not anchored to the Apple ecosystem anyway, Swift seems like a bizarre choice. The author seems to like xcode quite a bit, but I don't see it as more competitive or better than any other IDE. Not to mention it does window management and the like differently from everyone else, so when you're getting into it, it feels like you have to learn IDEs, and then you need to learn xcode. I also don't understand why people are so complacent about xcode crashing all the time - if VS Code or VS or Eclipse or IntelliJ ever crashed on me I'd be pretty darn upset.

matt4077 10y ago
I recently tried my hand in the macOS ecosystem and I must say I was positively surprised by XCode. It's "intellisence" is incredibly fast compared to VSCode. One argument for Swift is also that Swift is used on the client almost as often as Javascript is.
- untog 10y ago
  > One argument for Swift is also that Swift is used on the client almost as often as Javascript is. That can't be even slightly close to true. The amount of web code out there already dwarfs native iOS, and the majority of native iOS code out there is probably still in Objective C.
  - colechristensen 10y ago
    I think he's talking about the proportion of swift that runs on the frontend vs. backend. The comparison is like JS in your browser vs. node
holydude 10y ago

illuminati1911 10y ago

"In server-side Swift, you don’t use interface builder, so that reduces most of your crashes to none." You don't use that in iOS app development either unless you are completely insane or are just beginning iOS development and don't know how to make UI properly.

adomanico 10y ago
Am I missing a joke here? Interface builder, xibs and storyboards are very useful tools for even extremely large projects. Makes building and maintaining the UI extremely easy. The idea that because a tool is easy to use is somehow indicative of the skill of the person using the tool, is completely bogus. Interface builder has a lot of advanced features for setting up complicated UI. You could quite easily argue the opposite for someone who needlessly creates all of their UI in code rather then in interface builder.
- cwbrandsma 10y ago
  I'll chime in, having done IOS apps for many years now...I have fully given up on Interface Builder and Storyboards. I build all my UI in code and find it works MUCH better and I spend much less time fighting with the UI. I used to spend half my time fighting with interface builder to get the layout right. Move one element that something else is constrained too...f' your everything. Oh, and setting up constraints in InterfaceBuilder...don't even. Such an amateur implementation I can't even believe they shipped it. (The code implementation isn't that bad tho) Then wire up my events, if you refactor anything...boom -- but only at runtime. Because the compiler is wired into the process, so if a method/property doesn't exist in the ViewController that InterfaceBuilder is expecting, the compiler doesn't break, your app does. Also add in how often Interface Builder crashes XCode.
  - epx 10y ago
    I was rejected in a job interview quite some time ago, probably because I defended encoding UI in code, instead of using Storyboard. Sometimes destiny saves you from trouble.

eptcyka 10y ago

Is there a reason to use Swift over Rust?

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
pjmlp 10y ago
Developing for any Apple OS, other than that not really.
scottostler 10y ago
I use Swift professionally and have written some Rust for fun, and like both languages a lot. I find Swift to be faster to write, not least because it's easier to manually prevent retain cycles than to write borrow-checker approved code. It's also much easier to leak memory and write unsafe threaded code in Swift, so there's a trade-off there. I'm sure if I wrote more Rust I'd get faster at it, though I do think it has a fundamentally more complicated programming model.
- eptcyka 10y ago
  Fair. I've yet to write any code for an Apple device, but Swift seems like a nice language. Albeit I'm a massive Rust fanboy.
steveklabnik 10y ago
The xi editor is mostly written in Rust, but wants native UI on each platform, and therefore uses Swift for the UI on macOS. This contains an answer to your question, but also, something more subtle: that it doesn't have to be either/or.
deleted 10y ago
[deleted]
kernelbandwidth 10y ago

bushin 10y ago

> let data[String: Any] So typesafe!

matthewmacleod 10y ago

Sounds like it's got a bit of development to go before the language is suitable for this use case, but I must admit I'm quite excited about it. Having recently been experimenting with Go and Rust in the same sort of space, my impression is that Go is a bit too verbose and lacking in features - definitely works and lots of people like that, but I don't find it particularly powerful. Rust is great, but I've found that web backends end up with too much code - and it's still quite a challenging language to use, though that may be my inexperience. Building iOS apps in Swift recently, I've really started to get enjoy using the language. Once the various issues are worked out, I'm optimistic about its suitability for things like that - and it's great to have more language options to play with!

iamjono 10y ago

Going to chime in a bit here... "Avoid #if os(Linux)… When you do this, you lose all help from Xcode. It can’t do syntax checking” ... That’s not correct. Jeff was seeing the effect of something else blocking this from happening. arc4random, yeah, it doesn't exist on Linux currently, but there are other options that are better anyway, like using TurnstleCrypto. For Perfect, there's also a macOS app that aside from helping the process of starting projects, dependencies, building etc - it also integrates a standardized Docker Ubuntu 16 image which also hooks into Xcode so when you build it's also building in Ubuntu and therefore catches linux-specific build issues immediately. Anyway, my 2c. (Full disclosure, I work on the Perfect dev team)

iamjono 10y ago
FWIW, if anyone wants to discuss, join us on our Slack channel via http://perfect.ly http://perfect.ly My handle on that channel is, surprisingly, the same as here, @iamjono.

geodel 10y ago

Reading about Swift on server side and looking at Swift server dev mailing list. It appears to me that most appropriate use case of Swift on server side is Apple platform where client side is already written in Swift. The server side group at Apple/IBM seems mostly looking for Swift wrappers around C/C++ core technology for sockets/http/ssl related work. This might be amply sufficient for Apple or IBM developing LOB apps in Swift but I do not see how it is very convenient for generic server side applications.

fauigerzigerk 10y ago
I don't see how you can conclude from any of that what the most appropriate use case for Swift on the server side is. It's just what a couple of early adopters are talking about today. For me, the case for Swift is that it is a modern language that doesn't waste half of the available memory on a tracing garbage collector. The same goes for Rust, which has even more opportunities for low level optimization where necessary (and way superior string handling on top of it).
- geodel 10y ago
  I can conclude that by looking at for example Go offers today vs effort of setting Swift web framework like Kitura. IMO it is far away from general purpose server side usage. As far as memory usage goes Swift does not color me impressed when compared to GC'd language: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
  - fauigerzigerk 10y ago
    Adoption is not the same as appropriateness at all. As far as memory usage goes these benchmarks are completely irrelevant. They use very little memory and they measure it in a way that is unsuitable for a memory benchmark in the first place. The problem with tracing garbage collection is that it requires a lot (~50%) of spare memory at all times to give the GC time to catch up without slowing the program down too much.

komali2 10y ago

> You don’t have to see Linux’s horrible UI. lol excuse me? Actually now I'm thinking, what does he mean by "Linux?" Like, Ubuntu server? Is the UI for that considered bad?

anonyfox 10y ago

I still wonder why i would use Swift in the backend. - elixir/erlang: fault tolerance, scalability, high complexity web apps - Node: npm already has what you need, SSR for SPAs, JS is accessible for frontend guys (sort of) - Golang: dead-easy microservices with CLI support, single file deployments, good performance, beginner level language makes Training/hiring easy - Rust: excellent performance and great typesystem, ideal for writing Heavy core algorithms of products and use them as libs from other languages. Also all benefits of Go (except ease-of-learning). - ... - swift? Given that learning languages is not an issue, why should I prefer swift over other stuff? Are there real selling points?