
Building a Production Server Swift App - ckurose
https://realm.io/news/slug-jeff-bergier-building-production-server-swift-app/
======
iamjono
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
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.

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

~~~
codesternews
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 or language syntax totally changed now you need
to change million of lines of code to new syntax. It might be improved in
future but for now I do not think it is time to swift as server language.

I really like the language but for using it on server development nah.

I need to wait for 10 minutes or more to compile my code. I am really
frustated. I am solving for 2 days Xcode 8 issues beacause it compile slow and
it is really frustating as a developer. It does not matter how I write code in
a language but in swift 3 dictionaries are really mess and slow to compile and
it's long way to go for swift.

It's just my personal opinion.

~~~
mahyarm
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!

~~~
Aker89
can also recommend this approach at the moment:
[http://khanlou.com/2016/12/guarding-against-long-
compiles/](http://khanlou.com/2016/12/guarding-against-long-compiles/)

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

~~~
dep_b
Wow, just what I needed! I posted a rant a few days ago here where I advocated
for just this thing!

------
pietrofmaggi

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

------
matthewmacleod
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!

------
anonyfox
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?

------
geodel
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
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
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...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift)

~~~
fauigerzigerk
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.

~~~
geodel
Sure, May be I am wrong and Swift will be just fine for server use cases.

------
komali2
> 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?

------
eptcyka
Is there a reason to use Swift over Rust?

~~~
scottostler
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
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.

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

~~~
jarjoura
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.

------
bushin
> let data[String: Any]

So typesafe!

------
teddyknox
Scala vs. Swift vs. C#. Fight!

~~~
chc
That's a bit like Alien vs. Tintin vs. Predator.

~~~
optimuspaul
except that obviously Tintin could win, but it's not obvious that Swift would.

------
bigdubs
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?

~~~
niklasrde
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.

~~~
echelon
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 engineer would choose Swift.
There are a myriad of better choices, including those that you ruled out.

~~~
bigdubs
You basically completed my original comment with much better clarity.

This is what I was driving at.

