Live data from Hacker News

Building a Production Server Swift App

realm.io

31–40 of 91 posts

Re: Building a Production Server Swift App

#31
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…

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

Re: Building a Production Server Swift App

#33

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

Re: Building a Production Server Swift App

#34
post #22

Is there a reason to use Swift over Rust?

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.

Re: Building a Production Server Swift App

#35

> "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 :-)

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.

Re: Building a Production Server Swift App

#36
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…

Your argument is not against Swift-the-language but Swift-the-environment.

Environments improve over time.

Re: Building a Production Server Swift App

#37
post #22

Is there a reason to use Swift over Rust?

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

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.

Re: Building a Production Server Swift App

#38

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…

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

That said I really love the language but it's my opinion by looking other languages swift is not for server development and will not be successful. But that's my opinion.

Re: Building a Production Server Swift App

#39
post #22

Is there a reason to use Swift over Rust?

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.
Post reply on HN