Looking at their github, they appear to be making progress against re-implementing the Swift core library by binding to native classes with similar functionality. Like Arrays: https://github.com/remobjects/SwiftBaseLibrary/blob/master/S...
This is a great find; thanks for the link.
I've used this before and was amazed how well it worked, particularly with libgdx: https://libgdx.badlogicgames.com/
Not affiliated with either, by the way.
And just the use of the words JavaFX and iOS in the same sentence seems weird! More than happy to be proved wrong though....
Plus I imagine that people using the other front ends are doing it for other reasons. C# and Pascal seem like enterprise moves (for the enterprises of >2005 and <2005).
It would be great to see an open source ecosystem for Swift, written in Swift on all *nix platforms.
What makes Swift better than other ML like languages for the mainstream developer is the tooling. e.g. Playgrounds and IDE support, and Apple forcing developers to adopt it (Objective-C had only a few WWDC sessions).
For anything else, Haskell, OCaml, Rust and even F# are better options, as they are more mature, already portable and lots of libraries to choose from.
Haskell is really weird. Even for someone reasonably experienced in functional programming, there are tons of new concepts you need to master to be minimally productive in the language. Beyond that, it introduces a whole new problem class of space leaks that you need to reason about. It's not a bad language, but it is a much more radical leap from anything else you're likely to have tried than Swift is.
OCaml is fairly verbose, still doesn't have a great parallelism story AFAIK, and has a quirky type system (1.5 + 1.5 is a type error) and a not-very-well-loved standard library.
Rust can be pretty hard to use and not very ergonomic. If anybody's first Rust stab at a Rust program doesn't run into "such-and-such does not live long enough," that's pretty astonishing. You have to think about a lot more than with Swift.
F# is tied to .NET, which is sufficient to be unappealing for a lot of people.
Mostly agree, but it does depend on how you define minimally productive. I also believe this is more of a pedagogy problem. For instance, someone can tell me what their definition of being minimally productive is in Haskell and if it is within my skills I can get them there pretty quickly.
> Beyond that, it introduces a whole new problem class of space leaks that you need to reason about.
I feel like "whole new problem class" is unfair since other languages have memory leaks.
Also, there are techniques developing for dealing with space leaks just like other languages have techniques for memory leaks:
> It's not a bad language, but it is a much more radical leap from anything else you're likely to have tried than Swift is.
Perhaps I've drunk the koolaid, but it doesn't seem that radical after having learned it.
> OCaml is fairly verbose
Agreed, it's the main thing that has put me off of learning what is probably an awesome language. To be honest I just can't get over all the let's :/
I find this a little hypocritical since I found it easy to get over lisps/schemes parenthesis.
> still doesn't have a great parallelism story AFAIK
Right, but they are apparently fixing that fairly quickly: https://news.ycombinator.com/item?id=9582980
To be fair that was posted 146 days ago though and I don't know what current progress is.
> and has a quirky type system (1.5 + 1.5 is a type error)
Interesting, that's because you need to use .+ right?
> and a not-very-well-loved standard library.
I'm always torn on whether or not this is a huge problem. Part of me loves being able to build everything as libraries since anyone can essentially build onto the language. With a good enough package manager this seems ideal. The part of me that wants things to be fast and minimal though craves a great standard library so I can have fewer dependencies and a more "standard" experience. A good standard library also has the advantage of giving you good or good enough options without having to do tons of research on the best libraries for a given task.
Haskell for instance can require some knowledge of the library ecosystem to have the best experience. I'm not sure I'd say the standard library (or Prelude as we call it) is horrible, but it's definitely not as performant as it could be since many (all?) things are based on strings being represented as a linked list. The library solution for this is use Text for anything with unicode or use bytestring for ascii only IIRC.
Don't tie your ecosystem to a proprietary (yes, Swift is still a 100% proprietary environment!) toolchain. We've done that several times already in this industry and the results have never been good.
> Using Rust on iOS is pain.
Swift with Objective-C is bridged automatically.
You don't have this problem with Swift.
To avoid the unnecessary overhead of dynamically dispatched Objective-C method calls.
To me, it seems more sensible to go
Rust -> C -> Swift
Rust -> C -> Objective-C -> Swift
Yep, it is easier to make languages target DEX than suffer the pain of the NDK.
They not only advise against it, they make it really uncomfortable for us to use it (vs iOS and WP experience).
Why do you say that? Plenty of Android apps use non-trivial amounts of C/C++ code, and Dropbox has a tool called Djinni that can automatically generate JNI glue code. My guess is that if it's feasible to use pure Dex bytecode, then debugging is easier (because there's only one kind of call stack), memory can be managed more effectively (because the Dalvik/ART garbage collector can manage everything), and performance isn't impacted by the overhead of JNI. But I have nothing to back that up.
- The bug tracker is full of NDK issues
- GDB works, eventually. If one has the right set of versions and mobile firmware
- Integration with the first official IDE (Eclipse CDT) kind of worked, after one turned off indexers, did a few plugin customizations, and even then not really
- When Android Studio was announced, silence ensued about NDK future. When Jetbrains announced CLion, there was the hope that it might came to Android Studio, still silent all the way up to Google IO 2015.
- No pre-defined templates for mixed code applications
- Even today Gradle support for NDK builds is flaky and not final. I am yet to be able to have the samples build out of the box.
- The set of official C++ libraries is quite limited, most game related APIs are exposed. Even C++ libraries used by the Java layers like Skia are not exposed to the NDK.
- By limiting NDK to a few basic POSIX APIs and Android game related APIs, everyone has to pack into their APK everything from JNI wrappers, image loaders, network access, the whole stuff.
Now compare this with using C++ in iOS with help of Objective-C++ or on Windows Phone with help of C++/CX.
First class tooling support, mixed debugging that works and no need to keep on writing wrappers.
Even Microsoft's tooling for Android NDK is looking better than what Google does for their own platform.
As for Djinni, I am yet to make it work on Windows.
So what does this look like in practice? Genuinely curious :-)
So, you get the same benefits of the languages that target other VMs like JVM, CLR, BEAM and so on.
As long as, the language semantics can map into the VM semantics, all the libraries and platform tooling are available without the need of writing wrappers.
True, that is a big "as long as", but it still is less problematic than going through the current state of the NDK.
That is the approach take by Elements for their tools (http://www.elementscompiler.com), for example.
Why is that not possible for real-world languages? e.g. have one language which would include the specifics and complications of each language of the world and use it as intermediary for going back and forth to any language in the world.
Also, how come it doesn't look like they had to provide the path to the runtime? Built into the compiler I guess?
According to the article, you would have to use the NDK to make this work and...
> And of course since we're missing the SwiftCore library this is restricted to a small subset of Swift.
So, it seems more of an academic exercise than a practical thing?
Yes because it's a language of higher level than C++ that can theoretically run on all platforms. Now I don't know about you but I'd much rather write the core of my software in a language that can be used on all platforms. This way I can leverage the same business logic everywhere and just have different, dedicated logic for UIs.
I once tried to use C++ for this but the STL is supremely lacking in almost every way compared to the standard libraries that come with almost every other language. There just isn't much choice out there.
Gah, I'm not sure how you'd do that and still be able to deploy an application to the iOS app store. I would imagine cross compiling Swift would be orders of magnitude easier.
Java isn't married with a JIT, there are quite a few commercial AOT compilers.
Even Oracle is finally planning to add one after Java 9.
And can I just add — WOOOOOO!! Okay. Sorry.