Building a Production Server Swift App
1–10 of 91 posts
Re: Building a Production Server Swift App
#2butwhy.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?
Re: Building a Production Server Swift App
#3butwhy.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?
Sometimes you do things just to do things. Are you never curious?
Re: Building a Production Server Swift App
#4[deleted]
Re: Building a Production Server Swift App
#5I was set to do some effects on After Effects anyone about this experience Ask yourself (https://goo.gl/Ada79j)
Re: Building a Production Server Swift App
#6Scala vs. Swift vs. C#. Fight!
Re: Building a Production Server Swift App
#7butwhy.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?
The dream of a compiles-to-native-executable language with a strong compiler, probably. Rust would also apply.
Re: Building a Production Server Swift App
#8Its 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.
Re: Building a Production Server Swift App
#9butwhy.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?
Programmers in general today have significant amounts of freedom to choose the toolchain, languages, libraries, and frameworks they use. That wasn't historically always true, especially because the available choices have been growing exponentially for the past 50 years. Many of us are using that freedom to put our efforts into innovating and pioneering this field to make programming easier, safer, quicker, more reliable, and in general trying to improve every possible aspect of it. I suspect the main motivation is that we just love solving problems, which is why we're still programmers to this day, but another and probably less publicly acceptable motivation is that it helps us get our job done quicker, which in turn theoretically allows us to make more money in the same amount of time, which is a no-brainer.
Re: Building a Production Server Swift App
#10butwhy.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.