Anyone care to discuss long term support? How brittle is it with iOS upgrades, for example?
Any Swift examples that I can include in my Swift Weekly page?
FWIW apparently it will be officially merged into the mainline compiler soon enough.
This wasn't always the case, but IIRC the current review rules only forbid having a runtime scripting language that isn't JS (since Apple can happily sandbox JS), but anecdotally even that isn't a problem these days (e.g. plenty of games use Lua for in-game scripting).
1. Sound, static typing prevents entire classes of errors. This becomes even more important when you are shipping an irrevocable binary to users which you cannot update after the fact.
2. That same static typing can prove safe the removal of data boxing, and run-time lookup in order to increase performance.
3. OCaml (`ocamlopt`) does not run your program in a "Virtual Machine" like Java - instead it compiles your code more directly into machine code like C++. Many (but not all) of the other functional languages compilers produce a byte code, and then rely on a JITed Virtual Machine to (hopefully) optimize your code at runtime. `ocamlopt` compiles your program into assembly and you can inspect that assembly ahead of time in order to understand how it will perform. There's always tradeoffs with this approach, but the benefit is that you do not need to wait for (or hope for) a JIT to optimize your code (or re-optimize your code when usage patterns change).
4. OCaml is strict (as opposed to lazy), fairly close to the metal, and maps to lower level instructions in a fairly straightforward way - you would not be very surprised if you were to inspect the assembly. OCaml also has two ways to create bindings to C code. One way is easy and automated, the other way has better performance.
5. OCaml has a reputation for being able to allocate tons of memory at an impressive rate. To the extent that is true (and I've not yet observed anything to the contrary) I would imagine that would make it well suited to building UIs that are rapidly re-rendered.
6. OCaml has an Objects type system extension which makes it easier to create bindings to platform APIs (which tend to follow an OO design).
7. OCaml has two compiler modes: `ocamlc` and `ocamlopt`. Both support separate compilation, which is indispensable when building UI applications, where tweaking/reloading is very common. `ocamlc` would be ideal for that rapid development phase because, although it produces slower programs, it compiles them significantly faster. `ocamlopt` is ideal for shipping because it produces faster executables.
8. OCaml does not require that you write only pure programs. This makes it much easier to integrate with existing platform/mobile code which is also typically not pure.
1) Type safety
2) Native code speed
3) No C style memory issues, its a garbage collected language
4) You can compile OCaml code as a C library, then call it from C. OCaml in general has great C/Objective-C/C++ interoperability.
5) Predictable performance, no head scratchers.
6) Functional programming if I want to do that.
TL:DR It is possible for Linux as well, but haven't done it yet.