Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)
While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time. The target market is really iOS devs who want the same language on the back end. That's a perfectly reasonable engineering goal for an iOS-first shop. But they're a vocal group and like to hype up server Swift as the next big thing for…
Pushing Swift to the Server
61–70 of 109 posts
Re: Pushing Swift to the Server
#62Wow. That "same language connected by an interface schema would have prevented Mars mission loss" thing is a really thin stretch.
This submission reminds me of "Satirical hacker news post" """ The Muskonauts figured out why their shit exploded. Hackernews, literally all of whom are actual rocket scientists, wonders if unit tests could have helped. """ Also conveniently forgetting that Computer Scientists are yet to solve types physical dimensions mapping in practical programming language. https://hackage.haskell.org/package/dimensional
F# units of measure are pretty cool - types for units!
Re: Pushing Swift to the Server
#63Ctrl-f for "So,". 24 results. You can sound much more professional and less juvenile by dropping the "So," prefix when you speak or write.
Wow! I was shocked to see no matches for "also", et al.
Re: Pushing Swift to the Server
#64IBM, the purveyor of Rational/Websphere suite of Java tools and appservers talking about Java memory usage is sign of changing times. I hope they do better job this time with Swift tools and frameworks.
The times are changing, hence why Java 10 has better support for some form of value types, improved generics, JNI replacement and AOT compilation on its roadmap.
All good stuff. But I have heard JNI is already multiple times faster than Go's cgo stuff so I wonder what could be improved there.
Re: Pushing Swift to the Server
#65For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…
I think stability and maturity and is what Swift is missing now to qualify for many domains you mentioned(i.e IoT/systems programming)
Re: Pushing Swift to the Server
#66Earlier quoted context omitted.
> Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently. Let's not forget it. How does that make presenting their product propaganda any more so than any other product presentation? Heck, they even use it themselves for their backend. > I really don't see Swift becoming a popular full stack solution outside of environments inve…
> How does that make presenting their product propaganda any more so than any other product presentation? Heck, they even use it themselves for their backend. There is that aspect, sure. But what I wanted to point out is the irony of IBM promoting Swift since there isn't really any obvious advantage of using it full stack unless you are using iOS. Which happens to be the product of their new friend. That is all.
IBM has already ported Java over to the z Systems platform. So why is them also supporting Swift a bad thing here?
Re: Pushing Swift to the Server
#67Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.[1] I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS. Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can…
> Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently. Let's not forget it. How does that make presenting their product propaganda any more so than any other product presentation? Heck, they even use it themselves for their backend. > I really don't see Swift becoming a popular full stack solution outside of environments inve…
> Go, which is much older than Swift, Rust, D, etc.
Go is definitely newer than D, which came out in December 2001, though D2, which is significantly different, came out in June 2007, while Go came out in November 2009. And, in the grand scheme of things, Go isn't too much older than Rust, which came out in January 2012.
Additionally, from the point of view of "no UI libs," basically every natively compiled language is at a significant disadvantage on Android, even the originally intended native language, C++ (1983).
Re: Pushing Swift to the Server
#68Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.[1] I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS. Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can…
> Swift is fast
Not really. Apple's propaganda is fast, Swift can sometimes be almost kinda fast if the stars align just right, but in general it is quite slow. For example, last I checked, Kitura's HTTP parser is written in C. And has to be.
Another one: the various JSON "parsers" that wrap the built-in NSJSONSerialization API add about an order of magnitude overhead. That is after all the actual parsing and conversion to a property list, which isn't exactly the most efficient representation in the first place.
The Big Nerd Ranch guys realized that the only way to get a "high performance" JSON parser is to do it 100% in Swift. They did that and the result is significantly faster than the wrappers. And only 4x slower than NSJSONSerialization, which again isn't exactly a very efficient parsing model (think XML DOM parser).
https://github.com/bignerdranch/Freddy/wiki/JSONParser
I do a more in-depth analysis in my book, "iOS and macOS Performance Tuning"
https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...
EDIT: I forgot the link to Freddy
Re: Pushing Swift to the Server
#69No, I don't want to share models between the client and the server. I want an API dependency between them, a code dependency is actually worse.
Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies.
If you are implementering your database schema in the frontend, you´re doing it wrong.
An API is a view against a domain, which in turn is an abstraction above the database. However the client is not aware of the entire domain and shouldn´t be.
Only thing that is a good idea to share is the domain language and the API interface, but can be solved easily by other means than share code base.
And as soon you throw in another client with an other programming platform, all the benefits is lost anyway.
Re: Pushing Swift to the Server
#70Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.[1] I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS. Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can…
While it's not as easy as android it's not exactly complicated to distribute an app internally
https://developer.apple.com/library/content/documentation/ID...
Most of this is talking about getting up and running the first time too so it has length but it's not complicated.