Live data from Hacker News

Building a Production Server Swift App

realm.io

11–20 of 91 posts

Re: Building a Production Server Swift App

#11
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?

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.

Re: Building a Production Server Swift App

#13
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?

Well, maybe it isn't for you. I've had this conversation a few times a year for decades. I don't think there's a need to convince anyone that something new is for them. There are always early adopters for any new technology. It will mature. Feel free to jump in at any time where the cost meets your needs, or never.

The reason the first people jump in is because "they can". Then others follow for various reason.

Re: Building a Production Server Swift App

#15
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 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.

Re: Building a Production Server Swift App

#16
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?

Swift runs at the speed of C. It could be several orders of magnitude faster than ruby or python or node.

Re: Building a Production Server Swift App

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

Exactly. Apple seems to not care about the backend developers (well why would they). They fall behind MS and Google (.NET and Golang).

Re: Building a Production Server Swift App

#18
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?

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

Re: Building a Production Server Swift App

#19
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?

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.

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.

Re: Building a Production Server Swift App

#20
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 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.

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

Post reply on HN