Hacker News new | past | comments | ask | show | jobs | submit login
Opam-ios: an OCaml compiler for iOS via opam, with example server code (github.com)
85 points by e_d_g_a_r on Jan 24, 2016 | hide | past | favorite | 20 comments



Impressive! It would be great if we also get an Android port... would be the first sane cross platform mobile framework.



Great... it's probably time for me to do some mobile stuff :)


It seems that oCaml has been working on iOS for at least 4 years: https://news.ycombinator.com/item?id=3740173 yet you hardly hear about it.

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?

http://www.h4labs.com/dev/ios/swift.html?week=0


Jeff has been maintaining it since, he just released 4.02.3 which is the latest available compiler http://psellos.com/2016/01/2016.01.the-minor-drag.html with iOS 9.2. Not that bad I'd say, that's pretty much bleeding edge. I don't know about swift because I don't know how to compile swift into an object file. Swift is not worth the hassle for me right now.

FWIW apparently it will be officially merged into the mainline compiler soon enough.


Have you encountered any problems with the App Store review process due to the application being written in OCaml? I thought they don't like applications that are not written in Objective-C much.


These days, there are plenty of other frameworks for writing native iOS apps in languages other than Obj-C/Swift (Xamarin/Mono, RubyMotion, etc).

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).


The restriction on scripting says you cannot download and run code, unless it's executed through WebKit or JavascriptCore. So other languages seem to be fine as long as the code to run is bundled with the application.


Okay, I'll bite - why OCaml specifically? Aren't there other FP languages that cross compile to iOS, is there any advantage to using an ML?


Here are some things that make ML (and OCaml in particular) a desirable language for mobile development.

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.


Great response!


Because I really like OCaml, its very easy to talk to C code with it. Hmm, for me OCaml provides

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.


In your point 4) I assume you are referring to this tool?

https://github.com/ocaml-bytes/ocamlcc


No, its a normal feature of the ocaml compilers. I never saw that tool before your post.


That's very interesting, thanks. Now I'm quite tempted to study OCaml.


The server code in the example allocates a new buffer inside the server loop at every iteration. Is this intended?


No, I mention: Here is a stupid server at the beginning, but let no stone be unturned...


Nice. This still requires an OS X host? Or is it expected to work under eg: Linux too?


Yes, for now. Although I have also cross compiled the entire iOS toolchain to Linux, even have objective-C code completion in emacs on Ubuntu! That is however another blog post and detail that I haven't written down about.

TL:DR It is possible for Linux as well, but haven't done it yet.


Wow, very impressive. Following this closely - thanks for sharing!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: