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

71–80 of 91 posts

Re: Building a Production Server Swift App

#71

Post by rudedogg »

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…

String bridges to NSString, are you sure you need to cast?

Re: Building a Production Server Swift App

#72

Post by rudedogg »

codesternews wrote: post #38
hota_mazi wrote: post #36

Earlier quoted context omitted.

Your argument is not against Swift-the-language but Swift-the-environment. Environments improve over time.

But as author is also talking about the environment and I know it will improve but if you in to this and you have large codebase than waiting 10 minutes (some times it take 20 minutes thanks to Xcode 8.2) for build compilation and with every new Xcode release and swift release things are getting change so fast that most of time it is very hard for production app quality. Also not all dependencies keeping up at that r…

How large is the codebase? I think this is usually due to type inference on dictionaries in some cases. Usually explicitly specifying the type fixes the build times.

There's a tool that will tell you how long each part of your program is taking to compile so you can find the source.

Re: Building a Production Server Swift App

#73

Post by bigdubs »

lassofreak wrote: post #64
eptcyka wrote: post #25

Earlier quoted context omitted.

Not necessarily true https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

But it is true? https://medium.com/@rymcol/benchmarks-for-the-top-server-sid... Perfect (Swift) kills Node.js - which means it kills other stuff (like Ruby) without question. Python would be hard tho...

Would be curious to see `perfect` on the techempower list.

Re: Building a Production Server Swift App

#74

Post by bigdubs »

lassofreak wrote: post #65
bigdubs wrote: post #2

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?

One IDE, for all your code. (Especially useful for App projects) Code sharing also equals error checking, across code. One book/site/dictionary open at a time. One style to remember, at a time. What makes an ecosystem "proven"? Would you not buy an electric car, because the gas engine is proven?

An ecosystem is proven if there is good library support for common items, the libraries themselves are well thought out and battle tested, and if there is a good distributed knowledge base for common gotchas and issues.

These things take time and lots of people using a platform, and obviously that usage has to start somewhere, but part of being an engineer is balancing novelty with genuine improvement.

Re: Building a Production Server Swift App

#75

Post by rudedogg »

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…

I don't think that's how whole module optimization works. From what I understand it slightly slows down compilation, but you end up with more performant apps. For this reason I think it's only used for Release builds (that's how I have it setup).

https://swift.org/blog/whole-module-optimizations/

Re: Building a Production Server Swift App

#76

Post by bigdubs »

echelon wrote: post #18
niklasrde wrote: post #11

Earlier quoted context omitted.

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…

Both Go and Rust fit into the same niche you mentioned (statically typed, single binary, no "legacy silliness"). Both currently support the server use case better as they have more libraries and stronger concurrency primitives available. Neither has the disadvantage of poor Linux support. While I can understand why an iOS developer might spring for using Swift for server development, I'm not sure why any backend engi…

You basically completed my original comment with much better clarity.

This is what I was driving at.

Re: Building a Production Server Swift App

#77

Post by st3v3r »

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.

Not close to true. If you don't like using IB, that's fine and your choice. But many of us prefer using visual tools to lay out our UIs, so that we can see how it's going to look without having to compile and run the app every time and then navigate to the screen.

Re: Building a Production Server Swift App

#78

Post by st3v3r »

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.

I don't. It's not that hard to talk with the other devs on your team to avoid those merge problems.

Re: Building a Production Server Swift App

#79

Post by st3v3r »

illuminati1911 wrote: post #60
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…

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…

Anytime you dismiss something as things that "real developers" don't do, you're going to get a huge backlash, and rightfully so.

Re: Building a Production Server Swift App

#80

Post by geodel »

johnymontana wrote: post #68
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…

What mailing list is that? I couldn't find it with a quick google search.

Here you go:

https://lists.swift.org/pipermail/swift-server-dev/

Post reply on HN