Re-use of Julia from within Swift (the new Apple Programming Language)?

[Sam Isaacson]

I know it's early days, but Swift is in all likelihood going to become "huge" and the dominant Mac/iOS language. How easy will it be to call Julia code/packages from Swift? Naturally, I ask since both are based on LLVM under the hood. 

One scenario is re-use of the mathematical/statistical aspects of an application written in Julia (and presumably compiled to a shared dynamic library) together with other front-end application code written in Swift.

A follow-on question is whether this will need Julia to have an option to compile to a dynamic library file for re-use in swift OR if some sort of code injection into Swift could take place (since both are going to end up in LLVM anyway).

[Isaiah Norton]

We know is that it can call C libraries. So in principle, it will be approximately as easy as calling Julia from any other language with a C FFI - which is to say it is currently possible, on the roadmap to be improved, but currently undocumented and not regularly tested. With respect to LLVM IR integration - "we don't have anything to say about that at this point" [1]. In theory it would be possible, but kind of doubtful unless the Swift compiler is open-sourced.

 [1] http://thread.gmane.org/gmane.comp.compilers.clang.user/492/focus=493

[Dahua]

I skimmed the iBook document for Swift yesterday. Overall, it seems a well designed language (a good combination of useful features, but not a lot of innovation though).

It claims:

It is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language.

and

The compiler is optimized for performance, and the language is optimized for development, without compromising on either. 

Kind of in similar spirit as Julia. Sadly, it seems to be an Apple eco-system lockdown.

Dahua

[Tomas Lycken]

On the plus side, C# and the .NET platform was for a very long time tied intimately to MS platforms. Interestingly, MS has made a U-turn and decided to fully open-source the next version [1], so the trend is going in the right direction. I'm not saying that Apple is going to do it just because MS are doing it, but if MS are doing it it's probably because the developers want it. In the long run, I hope the pressure from the market will be big enough to open-source Swift as well.

[1]: http://www.asp.net/vnext

// T

[Tobi]

While its true that MS opened C# more and more I would not consider it for cross-platform development. Similar, even if Apple would open Swift I have doubts that they will push this to be a fully cross-platform solution. ObjectiveC is also open, but it is not in widespread usage on anything but Apple devices.

This is where open-source projects like Julia really shine. Because there are people that care, cross-platform issues are usually reported and fixed very quickly.

Swift certainly looks like a very interesting language. It is quite similar to Julia in various aspects.

It is quite funny that every bigger organization/company creates a new programming language. MS has C#, Google has Go (and Java on Android), Apple now has Swift, Mozilla has Rust. What would happen if some of these would join their forces...

[Tomas Lycken]

@Tobi, I haven't used it myself, but I've heard good things about the Xamarin framework (https://xamarin.com/). Even if it doesn't convince devs who are already using good cross-platform solutions, it opens up a wide range of possibilities for .NET people.

Also:

Sam Isacsson tried to reply to this thread but seems to have posted as a private message to me instead. This is what he wrote:

Does the fact that it's not open stop it from being to interoperate with Julia? I presume Swift will be able to call "C" libraries AND Julia can call "C" libraries so why wouldn't Swift be able to call Julia (even if this is only on Mac for the time being).

// T

[Tobi]

Yes with Mono C# is already quite cross-platform. Still, I would personaly favor other solutions esspecially when developing cross-platform desktop applications (because WPF is not available on Mono).

To Sam: Yes if Swift is able to call C libraries you should not have problems embedding Julia in Swift. See http://docs.julialang.org/en/latest/manual/embedding/ for documentation.

[Tony Kelman]

If Apple does end up open-sourcing Swift, I pity whoever eventually tried to write the equivalent of the "libuv rewrite and Windows port" patch for it. Linux support would presumably be doable with fewer scattered ifdefs, but it remains to be seen how receptive to outside contributions Apple will be.

[Dahua]

To me, C#, Swift or the like are particularly suitable for application development (e.g. GUI softwares and Apps) within certain platforms. Unfortunately, none of these are very cross-platform (I know Mono, but still kind of feeling unnatural using it in Linux or Mac). 

Recently, I realized that Javascript seems the one that is truly cross platform -- you can run it everywhere there is a web browser. In principle, you can write your UI (ok, webpage UI) once and run it everywhere (sometimes have to deal with the brewer's quirk though).

What I have always been wanting is something that can elegantly connect scientific computation backend and the GUI front-end, which is useful for building a demo system. I think Julia + Javascript is an ideal combination. Haven't figured out the best way to do this though.

- Dahua

[Tony Kelman]

Agreed wholeheartedly. As neat as Swift may be on the merits as a programming language, it's a walled-garden app development toy as long as it lacks portability and a stdlib as comprehensive as Julia's for numerics.

It seems what Julia could really use is a unified high-level platform-agnostic GUI framework that simplifies working with Gtk, Tk, Qt, Cocoa, WPF, JS web interfaces, etc as interchangeable backends. John Verzani has some cool un-registered work on the Gtk/Tk/Qt front, would be interesting to see if a JS backend (auto-generated via Emscripten possibly?) could fit within a similar framework as well.

What are your thoughts about what's missing from IJulia to achieve some or all of this?

[Tobi]

It depends a little on the direction one is looking from whether one calls Swift or Julia a toy :-)
I am quite impressed how Apple releases a product which is "ready" and directly encourages the developers to use it.

I think a high level Julia toolkit is feasible but there are two issues. First, it is a lot of work. Second, each toolkit nowadays comes with some declarative xml language that is used to describe the interface. Unfortunately they are all incompatible and thus are hard to get abstracted away. The best thing I could think of is to create a new interface language that is parsed in Julia and uses the low-level APIs of the different "native" toolkits.

[Steven G. Johnson]

On Thursday, June 5, 2014 11:01:53 AM UTC-4, Tony Kelman wrote:

It seems what Julia could really use is a unified high-level platform-agnostic GUI framework that simplifies working with Gtk, Tk, Qt, Cocoa, WPF, JS web interfaces, etc as interchangeable backends.

 

It doesn't make much sense to me to build a backend-agnostic toolkit to abstract out other backend-agnostic toolkits (Gtk, Tk, Qt, wx); it seems a little too meta.  Why not just pick Gtk or whatever platform-agnostic toolkit you prefer and focus on making a good Julia interface for that (e.g. Gtk.jl)?

[Rahul Dave]

I’ve been wondering a bit about this: node-webkit is an embedded webkit and node javascript runtime, what would it look like as a front end for winston/gadfly/widgets/etc. The part i am especially fuzzy on is the event loop integration: node-webkit intermeshes the node and webkit event loops. And we use libuv, which is used by node as well. So, could julia be a IO ‘source/sink’ for node, running on a separate thread in the way node io modules coded in c++ do? Does that even need event-loop integration? What would be its benefits? And would there be any to making certain julia types directly accessible from js?

-- 
Rahul Dave
Sent with Airmail

[Tony Kelman]

You're probably right, getting only one of the local x-platform GUI toolkits working really well and easy to use should be first priority. That doesn't help with web widget deployment though. Perhaps too much to ask to have it all look similar and interchangeable from a high-level interface.

[Mike Innes]

You could launch a Chrome instance from Julia (using e.g. Chrome Embedded Frame) and manipulate the DOM etc. using the C api directly – think node-webkit but with Julia instead of JS as the scripting language. That could be a great way to have cross-platform GUIs in Julia, especially since you'd get things like display of plots for free – and you wouldn't have to sacrifice performance either. It would be a fairly big project to get that working well, but it could be worthwhile, too.

In the meantime it would also be possible to connect Julia to environments like Light Table and expose a "JSCall"-like API over a socket.

[Stefan Karpinski]

I think that we have an option in Julia, afforded by generic functions, that may give the best of both worlds. Instead of trying to have a single "grand abstraction" over all possible graphics and UI toolkits, develop a shared vocabulary – common generic types and functions like Point, Line, Polygon, Circle, draw, plot, etc. These can behave similarly everywhere but not every graphics package or UI toolkit needs to fit into the same overall mold.

[Tobi]

I am myself not entirely sure what the best direction here is. When I contributed some the List/TreeView code to Gtk.jl I was kind of surprised how generic the interface was in the end. This means that Gtk.jl uses Julias generic methods wherever it can (e.g. "push!" and so on)