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

Building a Production Server Swift App

realm.io

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Building a Production Server Swift App

#51

Post by mahyarm »

codesternews wrote: post #30
nxc18 wrote: post #8

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 (ty…

I am iOS developer and I really wanted to say swift is headache and not a good language for Server development. I want to see how it goes but as far I know it is not flexible enough. I mean if you are building a production server you really do not want to think about language issues. Like dictionary is taking 4000ms to compile (yes it is true 4s) and compilation error message which has no link with what actual error…

Set your optimization level to -Onone & then manually set SWIFT_WHOLE_MODULE_OPTIMIZATION in user defined variables to YES. Your build times will improve greatly.

Xcode only lets you do WMO & optimizations on in the normal UX. Really bad that they don't expose this :/

Also to other people thinking about swift: don't. 200-100kloc and your build times become 5-20+ minutes. The conditional compiler is not very good either. And once your at that level of code, xcode spins it's indexer for a long time, autocomplete fails a lot and the debugger just doesn't work that well. Printing an object just spins for over a minute, and often it fails to even print the variable. Also configuring your project into many modules become painful with all the targets you have to manage.

Maybe in 4+ years when the language has matured enough and these issues start going away? And you have a build system that doesn't depend on large multimegabyte xml files that can't be written by a human. But for now, no.

It's good enough for a couple of developers doing contract apps although!

Re: Building a Production Server Swift App

#52

Post by epx »

cwbrandsma wrote: post #44
adomanico wrote: post #27

Earlier quoted context omitted.

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…

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…

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.

Re: Building a Production Server Swift App

#53

Post by mahyarm »

codesternews wrote: post #42
Apocryphon wrote: post #31

Earlier quoted context omitted.

Interesting. Do you think Swift isn't as good a language as Objective-C? Or a headache in what way?

No Swift is great language and I did not like Objective-C. The headache in the sense compilation time and also shitty errors come and you do not know what that means. It's type safe language but all the type safety comes with price and some time the code written is just sucks. Json parsing is one example of this. All the casting and all that really make code horrible. In swift 3 they made all value types to Any and i…

Try Freddy, much less casting!

Re: Building a Production Server Swift App

#54

Post by Aker89 »

mahyarm wrote: post #51
codesternews wrote: post #30

Earlier quoted context omitted.

I am iOS developer and I really wanted to say swift is headache and not a good language for Server development. I want to see how it goes but as far I know it is not flexible enough. I mean if you are building a production server you really do not want to think about language issues. Like dictionary is taking 4000ms to compile (yes it is true 4s) and compilation error message which has no link with what actual error…

Set your optimization level to -Onone & then manually set SWIFT_WHOLE_MODULE_OPTIMIZATION in user defined variables to YES. Your build times will improve greatly. Xcode only lets you do WMO & optimizations on in the normal UX. Really bad that they don't expose this :/ Also to other people thinking about swift: don't. 200-100kloc and your build times become 5-20+ minutes. The conditional compiler is not very good eith…

can also recommend this approach at the moment: http://khanlou.com/2016/12/guarding-against-long-compiles/

This makes XCode warn you about functions with long compile times.

Re: Building a Production Server Swift App

#55

Post by geodel »

fauigerzigerk wrote: post #50
geodel wrote: post #48

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…

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 neces…

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

Re: Building a Production Server Swift App

#56

Post by ropiku »

s_dev wrote: post #49
adomanico wrote: post #27

Earlier quoted context omitted.

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…

Storyboards are wonderful if you're a lone iOS dev with little need to collaborate and great for prototyping new designs. However on large projects with plenty of git merges between multiple users I think theres a good case for avoiding.

It's definitely not a good idea to have a single or few storyboards but you can even link storyboards. In my personal opinion splitting into a storyboard per main feature/area is a good balance.

Re: Building a Production Server Swift App

#57

Post by jarjoura »

armadsen wrote: post #33
illuminati1911 wrote: post #21

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

I'm not insane, and was doing Cocoa programming years before iOS existed. To each his own, but I'm not willing to work on codebases that are dogmatic about _not_ using IB. Use IB where it makes sense (most places), do what needs to be done in code in code. Interface Builder was one of the selling points of development on NeXTStep...

For the first several releases of OS X, you actually couldn't build a Cocoa application without the corresponding Nibs to go with it. Apple's frameworks didn't expose all the hooks necessary to write your UI entirely in code, nor would you even want to. It's cumbersome to create a cell and then attach that cell to a NSView and then bind it to a NSWindow.

Re: Building a Production Server Swift App

#58

Post by jarjoura »

epx wrote: post #52
cwbrandsma wrote: post #44

Earlier quoted context omitted.

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…

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.

Most big companies (Google, Facebook, Adobe, etc.) have internal UI frameworks that you share amongst 100s of developers and dozens of projects. Your interviewer should not ding you using code to build your UI. If anything, that's a plus as it should help you have a deeper understanding of how UIKit pieces things together.

Re: Building a Production Server Swift App

#59

Post by fauigerzigerk »

geodel wrote: post #55
fauigerzigerk wrote: post #50

Earlier quoted context omitted.

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 neces…

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

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.

Re: Building a Production Server Swift App

#60

Post by illuminati1911 »

adomanico wrote: post #27
illuminati1911 wrote: post #21

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

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…

Am I?

We can start with what the author just said.

1) It saves you from crashes and other crap

2) If you are collaborating with anyone ie. using git you can forget about them anyway unless you wanna face merge hell.

3) Interface builder is difficult to use, is definitely lacking advanced features so you'll end up putting some UI logic in the code anyway => more complexity, more error/mistake prone etc.

I have to say I'm a bit surprised to see this kind of reaction here on HN. I never thought anyone real developer would use them for anything else than just quick prototyping maybe.

Post reply on HN