Pushing Swift to the Server(skilled.io)
skilled.io
Pushing Swift to the Server
https://www.skilled.io/u/swiftsummit/pushing-swift-to-the-server
108 comments
You can do that today with iOS apps theoretically too & just use command line xcodebuild. You'll be missing all of the IDE things that swift is struggling with although.
I think stability and maturity and is what Swift is missing now to qualify for many domains you mentioned(i.e IoT/systems programming)
> http://pokerduel.herokuapp.com
Doesn't seem to work with the latest Firefox version on Mac. It loads, but clicking does nothing.
Doesn't seem to work with the latest Firefox version on Mac. It loads, but clicking does nothing.
Are you developing any iOS apps in Swift? How might I contact you to ask about your experience so far?
proven?
Wow. 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
""" 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
Similar for (roughly) "we ran one benchmark and can now say that swift is similar to java in performance and uses half the memory generally, for all things". No reference to the benchmark either.
The reference was shown in the slide. Here is the link:
http://benchmarksgame.alioth.debian.org/u64q/spectralnorm.ht...
In addition to reading Swift benchmark code, mixing unsafe C with Swift aren't complicated to learn and offer more performant. In contrast to Adobe AIR + C API (ANE).
The site owner asked us to replace the original URL you had with a static one in the hope of taking some strain off the web server, so we've done that. I hope that's ok.
That's not hard either, given the nature of both languages (native / compiled vs JVM). Yes I know Java can perform better in some situations.
Yeah, the Mars mission loss is also really well-worn at this point. I've heard this example in contexts ranging from cross-org communication, to software APIs, and unit checking (as in SI, USCS, etc.). Now I can add "language X is better than language Y" to that list!
What's worse is that the whole "story" wasn't even tied in to the rest of the talk. So basically, the guy spent 10 minutes talking about an interesting anecdote that had almost nothing to do with the rest of the talk.
Exactly. I'm a fan of Swift on the server, but this is the best they can do with marketing?
It's still early, 2017 will be exciting times with Swift 4.
That's where we are coming to share more of SSS topics in https://www.facebook.com/ServerSideSwiftCommunity/
That's where we are coming to share more of SSS topics in https://www.facebook.com/ServerSideSwiftCommunity/
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.)
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.)
I don't use swift in a backend context, but from the iOS side:
* The debugger & indexer fails often.
* Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems.
* Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so.
* You also don't have full control over your build chain, and decisions made by apple xcode can screw you over in when they change something in an update.
* Migrating your code from one version to the next can be a multi-week event.
I wouldn't use swift until it matures as a language in a few years. On backend you rarely need something that is not garbage collected. I would stick with python, golang & java. Maybe use rust or C++ if you need it.
* The debugger & indexer fails often.
* Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems.
* Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so.
* You also don't have full control over your build chain, and decisions made by apple xcode can screw you over in when they change something in an update.
* Migrating your code from one version to the next can be a multi-week event.
I wouldn't use swift until it matures as a language in a few years. On backend you rarely need something that is not garbage collected. I would stick with python, golang & java. Maybe use rust or C++ if you need it.
I've been developing on iOS for 7 years and Swift for 3. (Half of my 8 store APIs are in Swift)
While I agree with most of your criticisms I'll say it's never taken me more than an hour to update any code base when Swift versions change, it's a mostly automatic process.
Also I'd say anyone doing iOS development in Objective C instead Swift nowadays is doing themselves a grave mis-service. It's much easier and faster to build higher quality apps in Swift.
While I agree with most of your criticisms I'll say it's never taken me more than an hour to update any code base when Swift versions change, it's a mostly automatic process.
Also I'd say anyone doing iOS development in Objective C instead Swift nowadays is doing themselves a grave mis-service. It's much easier and faster to build higher quality apps in Swift.
Apple's target is the 1-5 person developer team with maybe 50kloc of code & 1 mac mini acting as a CI box. Xcode scales ok in these cases.
Backend development tends to feature a lot more developers with a lot more code. Swift starts getting really painful when you hit those numbers. Go look at presentations done by larger swift codebases like linked-in, uber, lyft & airbnb to see where it starts happening.
Backend development tends to feature a lot more developers with a lot more code. Swift starts getting really painful when you hit those numbers. Go look at presentations done by larger swift codebases like linked-in, uber, lyft & airbnb to see where it starts happening.
Of course, all dev gets more painful with more devs and larger code, so I assume you're saying that it increases more steeply with Swift than with...what? Java maybe? Or something else that the presentations you mention were comparing it to?
Objective-C, Objective-C++, Java, Javascript/Node, Python, Ruby, Golang, C++, C, C#. Build times increase significantly, the indexer takes 15-30m, sourcekit crashes, xcode UX freezes for 5s repeatedly, the debugger cannot print values when you hit a break point. On and on and on.
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 everyone. That's just not going to happen.
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 everyone. That's just not going to happen.
AppCode only runs on macOS and requires Xcode to be installed. It's no help to people who aren't running macOS.
Given all the complaints about XCode & Swift, I would say that it's not a huge advantage.
>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
They won't have any worse time than someone using Go or Rust or D anywhere else..., that is, languages without "premiere Dev environments" and IDEs...
They won't have any worse time than someone using Go or Rust or D anywhere else..., that is, languages without "premiere Dev environments" and IDEs...
For a while, there was a Swift plugin for JetBrain's CLion. https://blog.jetbrains.com/clion/2015/12/swift-plugin-for-cl...
I don't know what the future plans are for that ...
I don't know what the future plans are for that ...
[deleted]
The Swift Open Source community is quite vibrant. They're already building it on Linux + macOS. See: https://github.com/apple/swift
Edit: They also have a Platform Support page, where they discuss their goals/intentions on cross-platform: https://swift.org/about/#platform-support
Edit: They also have a Platform Support page, where they discuss their goals/intentions on cross-platform: https://swift.org/about/#platform-support
There's quite a few windows developers out there as well for which I don't think we'll see Swift any time soon. In contrast Rust has fantastic windows support.
[edit]
Yup, no mention of win32 on that page at all.
[edit]
Yup, no mention of win32 on that page at all.
Is it as mature or have as large of a (server-focused) community? No, but I might consider this over Go or Rust because I already know Swift (from iOS development), and I haven't used Go or Rust at all. Fluency and confidence speed development time.
In all honesty though, even though I really like Swift, I'd probably choose something else I already know well like ASP.NET Core until the Swift-on-the-server scene matures.
As for cross-platform capabilities, IBM has contributed a lot of effort to running Swift on Linux and in the cloud. They even have a web-based REPL you can check out.
In all honesty though, even though I really like Swift, I'd probably choose something else I already know well like ASP.NET Core until the Swift-on-the-server scene matures.
As for cross-platform capabilities, IBM has contributed a lot of effort to running Swift on Linux and in the cloud. They even have a web-based REPL you can check out.
Swift and Rust are remarkably similar if you're familiar with what Swift calls "protocol oriented development" (I think it's called). Really, it's just a version of Haskell's typeclasses in disguise.
Go and Rust are fine for some use case. Swift is fine for iOS and macOS developers as they are all backed by strong communities.
Roadmap for Swift: http://researcher.watson.ibm.com/researcher/files/us-lmandel...
Roadmap for Swift: http://researcher.watson.ibm.com/researcher/files/us-lmandel...
The consultancy Nodes reports that their framework Vapor[0] that is written in Swift is "around 100 times faster" than other frameworks written in PHP, Ruby and Python, you can see his bold claim 4 minutes in here: https://vimeo.com/193549098, but of course no benchmarks have been presented.
[0] https://vapor.codes/
[0] https://vapor.codes/
I'm not sure how Vapor is ready for production.
Try its hello world locally and then bench it with `wrk`. You'll get a lot of failed requests with a concurrency > 1. (I didn't test concurrency = 1)
Try its hello world locally and then bench it with `wrk`. You'll get a lot of failed requests with a concurrency > 1. (I didn't test concurrency = 1)
Even assuming it's true, that's not an impressive claim. Frameworks in those three languages are not known for their speediness.
If they claimed 1000 times, maybe that would be something worth sitting up to take notice.
If they claimed 1000 times, maybe that would be something worth sitting up to take notice.
Because having 100 less resources with similarly convenient language is something to sneer at...
When there are at least 4 such languages/runtime implementations that exist already and have more libraries that also "have 100 less resources" then, yes, that one claim is a lot less special.
Pretty much anything that compiles to good native code can be 100 times faster than "frameworks written in PHP, Ruby and Python". At least if we're talking MRI/CRuby and CPython, and especially without running multiple workers in those languages.
They really should be comparing against golang and java.
For the clever design of the language: coding with optionals is a breeze, it defaults to thread-safe reference counting, a cleaner syntax (IMHO only), .... .
For the unifying potential of the language: swift on the server (currently linux / freebsd limited), swift on mobile (Google seems to be moving in this direction too), swift on the desktop (macOS only).
For the unifying potential of the language: swift on the server (currently linux / freebsd limited), swift on mobile (Google seems to be moving in this direction too), swift on the desktop (macOS only).
> Google seems to be moving in this direction too
Source ?
The press made a lot of fuss about this claim.
Unfortunately we have no confirmations nor denials,
it would be nice to hear an internal about this.
http://thehackernews.com/2016/04/android-swift-programming.h...
http://www.dday.it/redazione/19590/app-android-scritte-con-s...
http://www.webnews.it/2016/04/08/google-apple-swift-android/
http://android.hdblog.it/n429420/Google-Swift-di-Apple-lingu...
https://www.tomshw.it/android-google-pensa-swift-apple-posto...
http://thehackernews.com/2016/04/android-swift-programming.h...
http://www.dday.it/redazione/19590/app-android-scritte-con-s...
http://www.webnews.it/2016/04/08/google-apple-swift-android/
http://android.hdblog.it/n429420/Google-Swift-di-Apple-lingu...
https://www.tomshw.it/android-google-pensa-swift-apple-posto...
Here's the original article that sparked this claim. They say that "Sources tell The Next Web".
https://thenextweb.com/dd/2016/04/07/google-facebook-uber-sw...
https://thenextweb.com/dd/2016/04/07/google-facebook-uber-sw...
It is great convenience for LOB applications when client macOS/iOS app and server backend both written in Swift. Team which knows Swift can be utilized for client/server side of products.
I am afraid that Rust might go Scala way where above average smart dev(s) decide on behalf of team what is best technology. Hence only very small teams and individual developers will use it. Larger teams with mixed skills and multiple locations might stick with boring but reliable technology like Java.
I am afraid that Rust might go Scala way where above average smart dev(s) decide on behalf of team what is best technology. Hence only very small teams and individual developers will use it. Larger teams with mixed skills and multiple locations might stick with boring but reliable technology like Java.
This reminds me of "Javascript everywhere". Technically yes, but I don't think that language is a main issue for being able to develop both client and server part of the app. Languages can be picked up in a matter of weeks, concepts like good api design, choosing the right database, deployment etc are the real challenge.
You are right of course. I still think it is great proposition for at least Apple platform. For client side Apple will push it for greatness for server side it is still too early.
"Boring but reliable" is often underrated.
For you, if you don't own a Mac as you say and are not interested in iOS development, at this stage almost certainly not. You should probably stick with more mature existing tools.
One day Swift on the server, or other platforms, might be interesting completely aside from the Apple ecosystems, but for now I think it's main attraction on the server side is for people already using Swift for MacOS or iOS development.
One day Swift on the server, or other platforms, might be interesting completely aside from the Apple ecosystems, but for now I think it's main attraction on the server side is for people already using Swift for MacOS or iOS development.
I think it probably is a good idea (and yes Swift is cross-platform). Mainly just because Swift is really nice language. Personally I would probably prefer to use Rust, but for a developer who is already familiar with Swift it makes a lot of sense.
I think that Swift as a language has a lot of promise and if it can be proven to work well on the server, it's something that one of the thousands of iOS developers can easily migrate into.
Why would it matter if it was cross platform if it is running on a server?
Because the officially supported platform, macOS/iOS, isn't a server platform anymore.
Previous investment in Windows architecture for one. Cross operability with locally running Windows applications for another. Unfortunately though there are obvious solutions to these problems, those who make decisions about spending are often not as concerned about doing it right (IE they already invested in Windows). It's a selling point for adoption. I suspected that with Linux Shell in future Windows Servers Kitura will just run there, but I'm sure there will be performance hiccups doing that (at least compared to native environments).
Obviously because you don't want to have servers running OS X?
Developing on Mac, deploying on Linux, which could be x86 or ARM, etc? MacOS isn't really a server platform, definitely not a cloud OS.
Case in point, Apple's iCloud runs on basically anything but Apple systems (most notably, IMO, Microsoft Azure).
It matters that the same development tooling is available on Linux.
if you've linux you're good to go. Just a text editor like atom or sublime and do everything via CLI. Very fast and expressive too
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.[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 run, but that's it. Other than that you are on your own. No UI libs, nothing.
This leaves you with iOS if you need to run on mobile which is extremely restricted. Want to freely distribute an app among your colleagues on the lab? Fuck you. You have to do all sorts of acrobatics with testing devices, provisioning certificates, etc.
In Android you just compile an .apk and send the link to your colleagues to install it, like in any other platform on Earth except iOS. Even macOS.
[1] http://www.apple.com/ipad/business/work-with-apple/ibm/
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 run, but that's it. Other than that you are on your own. No UI libs, nothing.
This leaves you with iOS if you need to run on mobile which is extremely restricted. Want to freely distribute an app among your colleagues on the lab? Fuck you. You have to do all sorts of acrobatics with testing devices, provisioning certificates, etc.
In Android you just compile an .apk and send the link to your colleagues to install it, like in any other platform on Earth except iOS. Even macOS.
[1] http://www.apple.com/ipad/business/work-with-apple/ibm/
> 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
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
I do not say this to defend Apple, as this is itself a form of "fuck you" "acrobatics" forced on you by Apple, but if you download Cydia Impactor (a program I develop that has a horrible UI which is about to get at least somewhat better in the next couple days), you can drag the IPA file to the device and it will have you log in with your Apple account (even if you are not a registered developer) and can then automate the entire 7-day free provisioning and installation process, helping this use case.
Also, while I am leaving a comment: the server space is different from Android in that 1) you don't need a UI and 2) there apparently is a sponsor working on the open source project (and it is my understanding that IBM is actually putting in more time than Apple) to make it useful there: Ruby is a language that is going to be a problem for you building either Android or iOS apps, and yet that is certainly not a reason to claim it would be a bad choice of language for coding a website backend.
Also, while I am leaving a comment: the server space is different from Android in that 1) you don't need a UI and 2) there apparently is a sponsor working on the open source project (and it is my understanding that IBM is actually putting in more time than Apple) to make it useful there: Ruby is a language that is going to be a problem for you building either Android or iOS apps, and yet that is certainly not a reason to claim it would be a bad choice of language for coding a website backend.
>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 invested in iOS and macOS.
Doesn't Apple becoming friends with IBM ensure that it will be used at least by many IBM customers? Which is quite a large potential base (and not all are happy for how Oracle moves with Java).
I also don't see why a top notch, statically compiled, very fast language, with automatic memory management, and support from a huge vendor AND a huge community AND open source, wont catch up.
>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 run, but that's it.
That's because the work for porting properly there hasn't been done yet. But it's more or less the same with Google's own Go, which is much older than Swift, Rust, D, etc.
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 invested in iOS and macOS.
Doesn't Apple becoming friends with IBM ensure that it will be used at least by many IBM customers? Which is quite a large potential base (and not all are happy for how Oracle moves with Java).
I also don't see why a top notch, statically compiled, very fast language, with automatic memory management, and support from a huge vendor AND a huge community AND open source, wont catch up.
>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 run, but that's it.
That's because the work for porting properly there hasn't been done yet. But it's more or less the same with Google's own Go, which is much older than Swift, Rust, D, etc.
> 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).
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).
> 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.
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.
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.
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.
> You have to do all sorts of acrobatics with testing devices...
A problem completely unheard of in Android land.
Ok, so maybe you can find a few situations in which Android might be a better solution that iOS. Congratulations. Android for the win. But there are many, many craptons of successful iOS apps out there that might like to be able to use services running on e.g. Linux. The existence of useful roles for Android devices won't make those go away.
A problem completely unheard of in Android land.
Ok, so maybe you can find a few situations in which Android might be a better solution that iOS. Congratulations. Android for the win. But there are many, many craptons of successful iOS apps out there that might like to be able to use services running on e.g. Linux. The existence of useful roles for Android devices won't make those go away.
As long as you are ok with going through the App Store and only using iOS then yeah, good for you.
This is what I meant earlier with:
> I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.
But in many enterprise, industrial, education, and scientific applications, iOS is a complete fail. Not because of iOS in itself, but because of the many restrictions Apple imposes on the development workflow and the limited hardware.
Or if you need cough mobile crossplatform cough...
This is what I meant earlier with:
> I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.
But in many enterprise, industrial, education, and scientific applications, iOS is a complete fail. Not because of iOS in itself, but because of the many restrictions Apple imposes on the development workflow and the limited hardware.
Or if you need cough mobile crossplatform cough...
IBM, 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.
According to Mark Reinhold, Sun designed JNI to be hard on purpose, to discourage developers to write native code.
He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones.
Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code from Java should be something like P/Invoke on the CLR. Similarly calling into Java APIs from native side should have less ceremony setting up what to call.
Additionally there should be a standard support for integrating GPGPU into Java.
As it was deemed too complex to be ready by Java 9 timeframe, it ended up being scheduled for 10+ roadmap.
For the latest status check "Going Native" at JVM Language Summit 2016.
https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PL...
He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones.
Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code from Java should be something like P/Invoke on the CLR. Similarly calling into Java APIs from native side should have less ceremony setting up what to call.
Additionally there should be a standard support for integrating GPGPU into Java.
As it was deemed too complex to be ready by Java 9 timeframe, it ended up being scheduled for 10+ roadmap.
For the latest status check "Going Native" at JVM Language Summit 2016.
https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PL...
Interesting talk. Go folks also probably want cgo similarly difficult to use. Though for them I guess it will work, as they have already written compiler/GC/runtime/ssl etc in Go plus some asm.
I never understood why cgo was an option instead of doing what most languages do.
The only reason I see, was having an easier way to parse header files.
The only reason I see, was having an easier way to parse header files.
I recently rewrote a server that I had in Kotlin and really happy with the results. With this I am pleasantly surprised! I already liked the syntax, and now it gives me another reason to try it out. I am not sure though how would it compare with Go.
I'd be interested to know if any developers are investing in swift outside of the Apple ecosystem. Given that the language still seems to be in flux (the v2 -> v3 transition didn't appear seamless), why would you pick it?
Why? Why choose Swift over a language with an established framework ala python, ruby, ASP.NET, Node.js ?
Agreed, every languages do established and growth into a mature language. Swift was born and constantly learns every languages for the last 30 years of pros and cons including Rust, Go and Ruby.
Swift is built on LLVM (Compiler designer) and CLang which both are developed by the same group but they do not forget children who can learns Swift from young age for robotics, electronics, 3D and many things could be done with Swift.
More is need to be done on tooling before Swift will be on par as Java and C ecosystem.
In the same analogy, why choose Tesla or electric powered vehicles when other car manufacturers are established? Keep learning and improve it.
Swift is built on LLVM (Compiler designer) and CLang which both are developed by the same group but they do not forget children who can learns Swift from young age for robotics, electronics, 3D and many things could be done with Swift.
More is need to be done on tooling before Swift will be on par as Java and C ecosystem.
In the same analogy, why choose Tesla or electric powered vehicles when other car manufacturers are established? Keep learning and improve it.
Well, neither Python and Ruby (prior to 2005-6) nor Node.js (prior to 2010-11) had any "established frameworks".
With this logic we'd still all be using CGI scripts.
Besides, Swift is several times faster CPU wise, type safe, and modern...
With this logic we'd still all be using CGI scripts.
Besides, Swift is several times faster CPU wise, type safe, and modern...
Speed, types, etc.
Python, Ruby, maybe.
Node.JS with Typescript or ASP.NET with C#/F#... I doubt it :)
Node.JS with Typescript or ASP.NET with C#/F#... I doubt it :)
Compiled langs are usually somewhat faster than node also, see golang, etc.
For now, i wouldn't. But swift is both a fantastic language, with enough felixibility to code generic code, and type safety to provide the best reliability ( no other language i know makes it that easy writing null pointer exception safe code), and one of the fastest( much faster than python or rails).
Mainly because you are already writing your MacOS or iOS app in Swift anyway and might even be able to re-use some code. If you aren't, no real reason for now to be honest.
No, 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.
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.
I completely agree with the general point, however at the minimum this lets client and server share the same exchanged models ( what the server sends to the client is defined once, as well as the opposite).
There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).
There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).
Yeah, the most obvious benefit is being able to share validation logic across front-end and back-end. All validation is necessary on the back-end for security reasons, but it's convenient for users if it also happens on the front-end, because they don't have to send data to the server before finding out it's invalid.
Are you suggesting something like http://espresso.caffei.net/ ?
This repo demonstrates deployment of the Kitura web framework using Node.js and Now.
https://github.com/aranajhonny/now-swift-example
https://github.com/aranajhonny/now-swift-example
How many projects really have just an ios client? If the argument is to have the client and server the same language then isn't that also an argument for a Java android & Java server?
It looks like we're getting Swift EE before Go EE.
Perfect team is writing an article for Native iOS and Android development using Swift. To be release soon.
Ctrl-f for "So,". 24 results.
You can sound much more professional and less juvenile by dropping the "So," prefix when you speak or write.
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.
[deleted]
Why. Seriously. Why. Whatever happened to domain-specific languages.
It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a couple of apps in Swift and they're up and running unattended:
http://swiftforums.herokuapp.com
http://pokerduel.herokuapp.com
Repos here:
https://github.com/kuyawa
And the fact that you can also develop for the desktop, mobile, tablets, watch, TV and IoT in one language is a huge advantage.
Swift is here to stay.