I'd like to hear from Swift Devs who also need to support Android. What does the landscape for cross development look like today, and what is the prognosis? Is open source Swift going to lead to a truly cross-platform tool set any time soon?
You don't have many choices for cross-platform tools. You can either use C++ that is quite hard for a lot of people but I would say most popular and most stable. You can use C# or Java with Xamarin but it is very expensive, unstable and it is kind vendor lock-in. You can also use JavaScript but you will lose a lot of performance that is very important on mobile. There are other options like using Lua, RubyMotion but they suffer same problems as JavaScript
Bottom line: There isn't convenient, modern, fast, open-source method for cross-platform development.
Swift bridges nicely with C and it is built on LLVM so you will be able to use it on Android with Android NDK and bridge it through JNI and Microsoft recently also adopted LLVM so you will be also able to use it there.
It is far from perfect, maybe one day. Currently it still suffers a lot of problems. Try to write a big application in it and you will soon discover it.
> You can also use JavaScript but you will lose a lot of performance that is very important on mobile.
I've used Appcelerator Titanium fairly extensively. The performance difference vs. native code is undiscernible. Unfortunately, JavaScript is an awful language to use, so there are tradeoffs. Maybe Titanium + TypeScript would be the sweet spot.
I found some things about it to be frustrating and buggy, but it was still less work than writing two different apps. My code was about 90% shared between devices.
It actually uses the MacRuby stuff to compile to native. But the compiler can't optimize nearly as well as it can for statically typed languages, so there's a pretty significant performance hit on the ruby code itself, though once you've called a native library there won't be any difference.
You're never going to have a truly cross platform tool set. The UI/UX paradigms are just too different.
There are already several solutions for sharing library code for business logic between the platforms, either using C++, or compiling Java to Objective-C, and that's about as good as you're gonna get.
I'm excited about the idea of server-side Swift and this seems to be the most ambitious implementation of it so far, but who is this awful web site targeted to? Developers? With its fading and sliding? Really?
Just give us the information without all the wank, please.
Swift, especially with its recent developments, is a hugely promising language for building servers. Type safety? Check, with great type inference. Like functional programming? Functions are first class citizens. Immutable data structures? Available and always encouraged. OO? Classes are there. Structs, kickass enums and interfaces? Fine by Swift. Predictable memory management? Check, ARC rocks. Plus lots of nice language features like guard, do/try, optionals, etc.
Really the only thing that's missing as a language feature is some kind of concurrency support, though I'm hopeful future iterations will include this. In the mean time, it might be a bit of a blocker for serious server-side adoption.
Ya, I was just gonna post this. Scala has more powerful generics and an eco-system of, oh I don't know, every java library ever created. It's also got the Play framework and Akka. When it comes to rationally planned web development, Swift is very low on the totem pole and a bunch of cute language features aren't gonna change that.
Swift's biggest advantage over Scala is its tight coupling with a commendable IDE. Perfect doesn't seem to address how debugging a server-side app will work with Xcode…
I agree with you and that's a nice rebuttal. I use XCode daily since I code in Swift for an iOS project. Great tool. However, I really wouldn't trade so much away just to stay in the same IDE and I certainly wouldn't construct a plan to do so. All the people down-voting me are just Swift fanatics who probably haven't touched the language all that deep. Good language, love the replacement for Objective-C, and you could argue GCD makes Akka unnecessary (though I wouldn't go that far), but again not fit for web development in my humble opinion..
XCode (for ObjC) is very commendable for no longer crashing every 5 minutes, other than that its pretty crappy compared to other IDEs created by multi-billion dollar companies (even some open source IDEs are better)
When working in swift it's as if someone rewrote the thing in Java. As obnoxious as eclipse can be, it at least code completes in a reasonable time.
Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many of the good points of statically typed languages - ie. type safety, ease of optimization, and performance.
Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems."
Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"
Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place"
If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad:
* Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime.
* That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower.
* It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly.
A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
> but it is strongly typed which is usually more useful than static typing.
Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.
> Reflection doesn't get in the way of type safety (in fact, it's generally supported by it)
Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence.
For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.
Not really, you're just operating on a higher dimension.
It's like saying multiplication makes things hard to understand...
You could write things 15 x 3 or 15 + 15 + 15, I dislike having programmers who like to do the latter on my team, or languages that make you do things like: Integer(15).multiply(Integer(3))
I'm sure that using reflection or higher order programming does cut out some people that you probably don't want anyway.
Leveraging the type system for COMPILE TIME dynamic programming is not only safer, but more runtime-efficient.
Wanna be clever? Here you go, be type-safely clever:
Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can still get really verbose.
Agreed, it would be cool if we could specify untyped zones within a function e.g.
@untyped
func parse(json: AnyObject) -> String? {
/* code here is not type checked, if returned value is not type String then value will become nil */
}
Newtonsoft.Json with dynamics is really good at it in the .NET world. I usually use actual typed objects, but the DLR has enabled some cool stuff concerning dynamic input type things.
I think the problem is JSON. Because JSON is tied so strongly to Javascript it tends to be very ugly in any other language. I think we need a simplified (and more concise) alternative to JSON that more closely matches the way languages that aren't Javascript work.
E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)
Swift's concurrency story is pretty much handled by GCD. IMO a fantastic set of APIs that make it pretty easy to deal with worker threads and queueing tasks and such.
Ahh nice - I didn't know that. It'll still be interesting to see what happens to the rest of the libraries and API's that are common place in Swift development
I'm intensely looking forward to Swift for Linux. I'd love to contribute more to open source iOS targeted project but I'm really unwilling to learn languages that I can't use on Linux at all because I don't want to make a Mac my daily driver.
> We are still on track to open source Swift (including Linux support)
> "by the end of 2015" as promised, more details will come
> out when they can.
> -Chris
63 comments
[ 3.3 ms ] story [ 139 ms ] threadBottom line: There isn't convenient, modern, fast, open-source method for cross-platform development.
Swift bridges nicely with C and it is built on LLVM so you will be able to use it on Android with Android NDK and bridge it through JNI and Microsoft recently also adopted LLVM so you will be also able to use it there.
React Native
I've used Appcelerator Titanium fairly extensively. The performance difference vs. native code is undiscernible. Unfortunately, JavaScript is an awful language to use, so there are tradeoffs. Maybe Titanium + TypeScript would be the sweet spot.
There is ActionScript 3
even if you think that "flash is dead" in the browser, for mobile and Desktop you can use Adobe AIR
for server-side, command-line and shell scripts you use Redtamarin https://github.com/Corsaair/redtamarin
I'm the dev behind redtamarin but I welcome other projects like perfect.
Even if the tech and language are different, different pros and cons, a lot of ideas and features are shared.
There are already several solutions for sharing library code for business logic between the platforms, either using C++, or compiling Java to Objective-C, and that's about as good as you're gonna get.
I switch fluidly between rails and swift, and I leave the java dev to those who enjoy it.
Just give us the information without all the wank, please.
Really the only thing that's missing as a language feature is some kind of concurrency support, though I'm hopeful future iterations will include this. In the mean time, it might be a bit of a blocker for serious server-side adoption.
When working in swift it's as if someone rewrote the thing in Java. As obnoxious as eclipse can be, it at least code completes in a reasonable time.
Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"
Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
* Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime.
* That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower.
* It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly.
A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.
Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.
Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence.
For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.
It's like saying multiplication makes things hard to understand...
You could write things 15 x 3 or 15 + 15 + 15, I dislike having programmers who like to do the latter on my team, or languages that make you do things like: Integer(15).multiply(Integer(3))
I'm sure that using reflection or higher order programming does cut out some people that you probably don't want anyway.
Leveraging the type system for COMPILE TIME dynamic programming is not only safer, but more runtime-efficient. Wanna be clever? Here you go, be type-safely clever:
https://vimeo.com/channels/flatmap2015/128466887
http://www.haskellforall.com/2012/06/you-could-have-invented...
With a good type system, you won't need reflection. If it compiles, it will work.
And give me a break on the "cut out the dumb people" part, I heard it many times from people right before they shoot themselves on a foot. Repeatedly.
As engineers, it's our job to solve problem and reduce complexity. Fail at either of the two, you have been a shit engineer.
There's a line somewhere between excessive verbosity and dumb trust (like the YAML snafu). I haven't seen great syntax yet, though.
@untyped func parse(json: AnyObject) -> String? { /* code here is not type checked, if returned value is not type String then value will become nil */ }
E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)
This is how I complete it. I'm surprised other people don't and that I'm getting downvoted.
Common misconception perhaps, but the _language_ is called Ruby, not Rails...
> [Hype] [Hype] [Hype] [Hype] [Hype]
> Features
> - JSON encoding and decoding
Okay! Well, moving on.