OCaml: Add support to iOS/Mac ARM64

https://github.com/ocaml/ocaml/pull/9699

by wczekalski • 6 years ago

244 100 6 years ago

nindalf• 6 years ago

I think most programming languages and associated tools will start supporting ARM64 as a first class citizen. The current lack of support isn't due to apathy, just constraints around ARM64 not being popular for desktop development. For example, it's difficult to support a platform that isn't well supported by your CI/CD provider.

Linus Torvalds previously said that ARM on the server would never be a thing since developers didn't run ARM on their personal machines. Since this assumption is no longer true, the ecosystem of tools will now support ARM better and we'll see ARM on the server become a major thing in a few year's time.

EduardoRFS5• 6 years ago

I don't think that was the case for a long time on the tooling side, OCaml has a great support for ARM64 for a long time now, but Linux ARM64. But well most developers aren't actually using Linux.

But a thing that is going to change is supporting iOS, one of the reasons that this PR was approved(and it adds support to iOS) it's mostly because there is a Mac ARM64

asveikau2• 6 years ago

I don't know much about ocaml specifically, but speaking in the abstract, probably one of the best reasons I can think of for a compiler to target arm64 Linux is to target android phones.

enedil• 6 years ago

Most OCaml developers might be actually using Linux though.

nix234• 6 years ago

But well most developers aren't actually using Linux.

What??

slezyr• 6 years ago

But well most developers aren't actually using Linux.

Then it would be Windows and not Mac OS.

Is Mac OS any popular outside USA?

nicoburns3• 6 years ago

The current lack of support

I'm not sure that's even true from a tooling perspective. It's true that desktop applications often don't support ARM64, but toolchains usually do because both Android and iOS are primarily ARM64 and are hugely popular platforms.

heavyset_go2• 6 years ago

As someone who jumped on the ARM train early, and someone who doesn't want to contribute to creating more electronic waste than necessary, it's disheartening to see 32-bit ARM being increasingly ignored as a platform compared to ARM64.

wczekalski3• 6 years ago

ARM 32 bit is supported by OCaml. Just not for iOS/MacOS since the 32 bit iOS devices are ancient by now.

cesarb• 6 years ago

It's not just ARM; the same has been happening to x86. 32-bit in general is going out of fashion for general-purpose platforms.

petre• 6 years ago

It's not just about electronic waste, many low power embedded platforms are still ARM 32 bit.

mattgreenrocks• 6 years ago

There's confirmation bias at work here, but I've definitely noticed a slight uptick on ARM-related work to various dev tools (think LLVM and whatnot) in 2019-2020 leading up to the announcement. That and $5 gets you a decent cup of coffee, but hey.

OCaml is known for having a small-ish implementation with good performance IIRC (not sure where multicore is these days). Will have to take a look at this.

superherointj• 6 years ago

OCaml has multicore now and seems to be doing well. Latest report: https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047/1

babaganooj• 6 years ago

I have this vague idea, which can be completely false, that porting software that runs on ARM64 Linux (which is what cloud servers use) to Mac ARM64 (which I think is BSD derived?) is not trivial. Or is it?

saagarjha6• 6 years ago

Depends on the kind of software. POSIX compatible C requires few, if any, source changes. Code that makes direct syscalls will need more work.

lmm2• 6 years ago

In the general case it's not necessarily trivial, just like porting software from x86 linux to x86 mac is not necessarily trivial. For example your software might rely on some system interface that's done differently on those platforms, e.g. if you're using kprobes then it would take an effort to port that to use dtrace. And if we're talking about a GUI application then the framework it uses might not be first-class on mac, e.g. GTK only works in an X11-based way. But there are cases where it's as simple as pushing the compile button and getting out something working.

monadic23• 6 years ago

Hah, and arm servers were already gaining an economic edge before Apple’s consumer product switch.

alderz2• 6 years ago

By reading the stream of comments on the PR, and from my own experience, I feel that it is extremely cumbersome to do code reviews on Github. Atlassian's Fisheye/Crucible looks like a better solution. Does anyone think otherwise? I think Github has a large room of improvement in this regard; a PR is not the same as an issue.

ChrisMarshallNY• 6 years ago

I don't feel like GH is really meant to be a code review platform. It does PRs, but I assume that review should be done offline (like in other tools, like Crucible).

We have used GH as a review platform for an open-source project, but they tend to be relatively minor PRs. If they got hairier, we'd probably find something else.

Personally, I really don't like having a gazillion different tools. If we can use one tool for several purposes, then that's what I prefer. If the tool becomes too cumbersome, then I'll work with something more specialized.

aspenmayer2• 6 years ago

Is there a good self-hosted open source platform for this? I’m new to all this, even though I’ve been computing since I was in grade school. Coding is a new discipline for me, and it’s hard to know the territory without a guide. I’ve seen you around and would trust a recommendation from you.

skrtskrt• 6 years ago

I have used and enjoyed Upsource (JetBrains code review tool) particularly for trunk development where you often need to be able to cherry-pick randomly-ordered commits into a review.

I honestly don't know how much our org paid for it though.

momothereal• 6 years ago

I've been using GitHub for code review (both open-source and commercial projects) for about 5 years. It's improved a little bit, but for PRs with >100 files changed it's obviously lacking good UX.

For me, the biggest improvement would be the tree-view you get in Fisheye/Crucible. It's so hard to get a grasp on large refactoring PRs on GitHub.

the_af3• 6 years ago

I wonder how one does manage a PR with >100 files changed. I realize these are sometimes unavoidable, but shouldn't we strive for smaller PRs? No tool will help you with exploding complexity...

outadoc• 6 years ago

This extension [1] makes code reviews more bearable, I highly recommend it. I don't understand why Github hasn't shipped this years ago. They've been improving the UX since their acquisition but there's still a long ways to go.

[1] https://addons.mozilla.org/en-US/firefox/addon/better-pull-r...

ahnick• 6 years ago

On GH I can see the files that are changed and make/read comments that are inline on the files as well. This has been sufficient for my needs. What is it that Fisheye/Crucible brings to the table that you think would be desirable on GH?

alderz2• 6 years ago

I guess that for some people, and particularly in small reviews, it is enough with the list of files and inline comments.

I would like to have a tree view where I can see all the files at a glance, and, more importantly, switch back a forth between them. I find it hard to follow the code in Github's UX.

Also, Fisheye/Crucible gives you more flexibility to edit the review, by allowing you to remove files, and add or remove commits. Github PRs are based on branches, while Fisheye/Crucible code reviews are based on commits; it is an entire paradigm shift that gives the user more control. For example, I can create two separate reviews from the same branch on Crucible; that's impossible on Github.

MaxBarraclough• 6 years ago

You might be interested in Torvalds' low opinion of GitHub pull-requests.

https://github.com/torvalds/linux/pull/17#issuecomment-56599...

Discussed at:

https://news.ycombinator.com/item?id=3960876

https://old.reddit.com/r/programming/comments/tionj/

secondcoming• 6 years ago

Agreed. We moved to GH from Bitbucket and code reviews is the only thing that Bitbucket did better.

dathinab• 6 years ago

It's not just git. I have yet to see a platform which does PR code reviews in a way I like.

If it's small PR or PR's from trusted sources it's not an problem but once it's bigger and from a third party reviewing it can easily become much more annoying then it should.

Besides UX aspects on major offender IMHO is the text based diff algorithm. I had to often changes where you could have created a easily readable diff but non content aware git diffs just produced total garbage.

lmm2• 6 years ago

I spent four years working at a company that uses stash/"bitbucket server". Coming back to GitHub I was shocked at how much worse their PR workflow is.

berkut• 6 years ago

I agree whole-heartedly (against both Github and Gitlab code reviews for serious large changes), but from what I've heard Crucible is apparently EOL now?

saagarjha6• 6 years ago

If one was ever curious why the security research device program should have been open to everyone and available without restrictions: part of this work was done on a jailbroken iOS device and QEMU. I doubt anyone would have been able put in that work had they not had access to that.

EduardoRFS5• 6 years ago

There was a previous PR where I got the overall patches needed, but almost everything was developed on the iOS + QEMU, at first I didn't had spare money to buy an used iPhone.

The only feature developed on the real iPhone was the dynamic linking, but because I already got the device.

Also I don't have a mac so Hackintosh, a powerful Hackintosh but nonetheless

vmchale• 6 years ago

Time for OCaml mobile :)

This is cool stuff, love to see functional programming growing and developing.

weitzj2• 6 years ago

Does anybody know what’s the status with bitcode support? Last info from about 1.5 years ago was that the Golang and Rust toolchain did not support it, but also Apple did not make it mandatory.

What is the current state? Does ocaml support bitcode?

UncleOxidant• 6 years ago

There is an OCaml interpreter that does run a bitcode, is that what you're referring to?

Gaelan• 6 years ago

The App Store has an option where, in addition to uploading an ARM binary, you can upload LLVM bitcode (a binary representation of LLVM IR). This allows Apple to optimize the app differently for different devices[0], and is required to build apps for watchOS and maybe tvOS.

[0]: Not sure if Apple does this in practice, but I believe the purpose of bitcode is that they could do that if they wanted to.

EduardoRFS5• 6 years ago

There is no support to bitcode, but there is no major advantage to support it, so it doesn't seems to be worthy

sanxiyn2• 6 years ago

tvOS and watchOS require bitcode, but yes I agree that's not major advantage compared to work required to support it.

sanxiyn2• 6 years ago

Rust had bitcode support since 2018: https://github.com/rust-lang/rust/pull/48896

weitzj2• 6 years ago

Good. One more reason to look at rust. Main motivation is webassembly for me

scott31• 6 years ago

... to the language which lacks multi-threading

gmfawcett• 6 years ago

Low effort post? Even though multithreading isn't relevant to the ARM64 work: for the first time in a long time, I think we can see a serious Ocaml multicore in the practical future, not the perennial "some day, maybe." You can already try the pools/futures part of the new multicore implementation, it's the algebraic effects part that is still outstanding -- see:

https://github.com/prismlab/parallel-programming-in-multicor...

nephanth2• 6 years ago

Ocaml has multithreading support now though (it was merged recently iirc)

yawaramin4• 6 years ago

Not yet, but it's being prepared to merge.

smabie• 6 years ago

It should land pretty soon I imagine.

cageface• 6 years ago

Of all the niche languages out there I'd like to see break into the mainstream Ocaml is my favorite. It seems to hit a sweet spot between pragmatism and elegance.

OCaml: Add support to iOS/Mac ARM64

Related Stories