OCaml: Add support to iOS/Mac ARM64(github.com)
github.com
OCaml: Add support to iOS/Mac ARM64
https://github.com/ocaml/ocaml/pull/9699
102 comments
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.
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.
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?
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.
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.
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.
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.
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.
I suggest https://www.gerritcodereview.com/
Thank you, I’m going to look into this more.
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.
I honestly don't know how much our org paid for it though.
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/
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/
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.
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.
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...
Usually with massive PRs of that sort I’ll have several smaller PRs to a separate branch that get reviewed so that everything in the massive PR to the main branch has already been reviewed and the big one is just a cursory look. But this approach probably isn’t as feasible with open source projects.
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...
[1]: https://addons.mozilla.org/en-US/firefox/addon/better-pull-r...
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.
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.
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.
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?
Agreed. We moved to GH from Bitbucket and code reviews is the only thing that Bitbucket did better.
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.
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.
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
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
Most OCaml developers might be actually using Linux though.
>But well most developers aren't actually using Linux.
What??
What??
Well, most aren't. The huge majority of developers use Windows and many use OS X.
In any major dev conference in the US/Europe OS X is almost 50% or more (and almost 80% on the presenters side), while Windows has tons of "silent" users (e.g. not the kind to make noise on blogs/HN/etc, but like 90% of devs anyway, working in enterprise, etc).
Even on Stack Overflow poll, which attracts less of the kind of "silent" enterprise devs more likely to use Windows and "bland" environments like .NET and Java, it's 45% Windows, 27% OS X and a little less of that (26%) Linux.
https://www.freecodecamp.org/news/stack-overflow-developer-s...
In any major dev conference in the US/Europe OS X is almost 50% or more (and almost 80% on the presenters side), while Windows has tons of "silent" users (e.g. not the kind to make noise on blogs/HN/etc, but like 90% of devs anyway, working in enterprise, etc).
Even on Stack Overflow poll, which attracts less of the kind of "silent" enterprise devs more likely to use Windows and "bland" environments like .NET and Java, it's 45% Windows, 27% OS X and a little less of that (26%) Linux.
https://www.freecodecamp.org/news/stack-overflow-developer-s...
It's funny to see your observations about Stack Overflow, because it was co-founded by an ex Microsoft guy (Spolsky) and I remember in early days there it had quite the .NET community which was probably not coincidental. I think they also run the site on .NET.
They do and very efficiently, it was at one point a bunch of high end servers - they called it out as an example of going deep not broad for scaling.
I remember reading they had 256GB of RAM on DB servers when that seemed like an absurd amount to me.
I remember reading they had 256GB of RAM on DB servers when that seemed like an absurd amount to me.
They at least aren't using Linux on ARM laptops/desktops, which has been a year away for around a decade now.
I'm guessing he might have meant OCaml devs? Most development shops I've worked in used Linux servers to host their solution, and mostly Linux/Unix based tools and dev environments (people who preferred Windows as their desktop usually ssh'd to Linux boxes to work).
Most developers, there is a lot of places to get this information but if you look at the stackoverflow survey, which is a survey large enough to be relevant, you get some data around 25% of developers using Linux.
We're talking about as their computer, not servers tho, everyone uses Linux for server
We're talking about as their computer, not servers tho, everyone uses Linux for server
Thanks for the answer! I have a followup question: if the server is Linux, that means the app itself (or the "solution") is Linux based, which means that an OCaml solution would have to compile (or cross-compile to) and run on Linux, which means that ARM64 on Linux is relevant :)
Unless of course most OCaml devs don't target Linux.
Unless of course most OCaml devs don't target Linux.
Sure it's relevant, but again like Eduardo said, most devs don't have Linux ARM64 dev machines, they don't use it on a daily basis, they don't have experience with it.
> everyone uses Linux for server
And here I am deploying .NET and C++ solutions on Windows Servers, strange definition of "everyone".
And here I am deploying .NET and C++ solutions on Windows Servers, strange definition of "everyone".
"Everyone" means most in casual conversation.
You maybe had it confused with the universal quantifier ∀ in a math/logic context, but it's not the same :-)
You maybe had it confused with the universal quantifier ∀ in a math/logic context, but it's not the same :-)
Which still doesn't apply, when Linux based servers are about 50% of server market.
https://www.t4.ai/industry/server-operating-system-market-sh...
https://www.t4.ai/industry/server-operating-system-market-sh...
53% Use Linux:
https://insights.stackoverflow.com/survey/2019#technology-_-...
>Linux and Windows are the most common platforms that our respondents say they have done development work for this year. We asked about container technologies like Docker for the first time this year, and Docker was the third most broadly used platform.
But:
https://insights.stackoverflow.com/survey/2019#technology-_-...
https://insights.stackoverflow.com/survey/2019#technology-_-...
>Linux and Windows are the most common platforms that our respondents say they have done development work for this year. We asked about container technologies like Docker for the first time this year, and Docker was the third most broadly used platform.
But:
https://insights.stackoverflow.com/survey/2019#technology-_-...
This is the distinction between the platform for which the work is being done and the platform the work is being done on. You can develop for Linux servers from other platforms.
Thanks, peoples from HN would not have understood that, big thumps up!
I wouldn't think so, from what I've read OCaml has pretty poor windows support.
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.
Android isn't even on the official list of OS supported, recently I fixed the build system for Android, OCaml is just not a mobile language(yet)
> 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?
Then it would be Windows and not Mac OS.
Is Mac OS any popular outside USA?
It's certainly popular in the UK. Especially for developers and students. Of course if you're doing mobile (iOS) dev you're pretty much forced to use macs.
I'm not really sure you can call macs "popular" even here in the US.... they're a professional luxury for the most part. I say this with three macs within reach of me.
>I say this with three macs within reach of me.
Well, they're a steady 10% of the PC market, which would make 1 in 10 computer owners in the US have one. Perhaps more have Macs than any other PC brand (if we break them down individually, e.g. Dell, HP, Asus, Microsoft, etc.).
Any coffeeshop is choke full of Mac laptop yielding people. Any university the same. Most developer conferences (Java, Rails, JS, Python, Golang, etc) is 50%+ Macs on the audience (and close to 80% on the . Stack Overflow poll puts Mac desktop use by devs at 27% (Windows 45%/Linux 26%).
Well, they're a steady 10% of the PC market, which would make 1 in 10 computer owners in the US have one. Perhaps more have Macs than any other PC brand (if we break them down individually, e.g. Dell, HP, Asus, Microsoft, etc.).
Any coffeeshop is choke full of Mac laptop yielding people. Any university the same. Most developer conferences (Java, Rails, JS, Python, Golang, etc) is 50%+ Macs on the audience (and close to 80% on the . Stack Overflow poll puts Mac desktop use by devs at 27% (Windows 45%/Linux 26%).
I mean this is fair but I don’t see much point in comparing Apple to a single commodity pc manufacturer, no disrespect intended (I love my xps 13). I suspect coffee shops and universities are simply full of the professional class I implied earlier, which makes sense to me.
Also, go to a community college and count the number of macs there. There’s a clear class bias here.
Also, go to a community college and count the number of macs there. There’s a clear class bias here.
>Also, go to a community college and count the number of macs there. There’s a clear class bias here.
Sure, since a PC would be more affordable, and in higher performance needs have more bang for the buck.
The Macs are for other kind of niceties (not raw performance per buck) and make different tradeoffs, plus cost more.
Sure, since a PC would be more affordable, and in higher performance needs have more bang for the buck.
The Macs are for other kind of niceties (not raw performance per buck) and make different tradeoffs, plus cost more.
The subject of the conversation is developers, who are almost by definition luxurious professionals.
It really depends on the programming culture. Game developers and many enterprise software developers almost universally develop on windows. I’ve had conversations with some people from those areas who have been shocked at the idea software developers use macs - they personally don’t know anyone who does.
But web development shops (especially node/react/etc), consulting, and SV startups seem to pretty consistently use macs.
It’s hard to intuitively tell how popular any of this stuff is in absolute terms because we’re all individually trapped in filter bubbles based on the kind of programmers we interact with.
But web development shops (especially node/react/etc), consulting, and SV startups seem to pretty consistently use macs.
It’s hard to intuitively tell how popular any of this stuff is in absolute terms because we’re all individually trapped in filter bubbles based on the kind of programmers we interact with.
[deleted]
> Game developers and many enterprise software developers almost universally develop on windows.
Anyone doing mobile game development knows the pain of trying to develop for iOS without using a mac.
Anyone doing mobile game development knows the pain of trying to develop for iOS without using a mac.
They seem exceedingly popular in academia, it seems that most university students and professors posses them, even in computer science departments.
Of course it is.
> 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.
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.
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.
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.
OCaml has multicore now and seems to be doing well. Latest report: https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047/1
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.
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.
I keep a 32-bit x86 Mac alive as a hobby project, and I've noticed the same thing. Debian seems to be the only Linux distribution with a maintained and up-to-date x86 port.
edit: I don't want to take up more space in this thread, but would like to thank Vogtinator and saagarjha for pointing out other options for 32-bit Linux distributions.
edit: I don't want to take up more space in this thread, but would like to thank Vogtinator and saagarjha for pointing out other options for 32-bit Linux distributions.
openSUSE Tumbleweed supports i586 and up.
Tumbleweed is just great!!! That comes from a Arch and FreeBSD veteran.
Alpine Linux supports it.
Well, even many mid-tier phones already have 4 GB RAM now.
The demise of 32-bit was/is inevitable for personal computing.
The demise of 32-bit was/is inevitable for personal computing.
ARM 32 bit is supported by OCaml. Just not for iOS/MacOS since the 32 bit iOS devices are ancient by now.
> 32 bit iOS devices are ancient by now
The last iPhone with a 32-bit processor appears to be the iPhone 5c, last produced in 2015. As I type this on a laptop from 2015, I have to question your definition of "ancient".
The last iPhone with a 32-bit processor appears to be the iPhone 5c, last produced in 2015. As I type this on a laptop from 2015, I have to question your definition of "ancient".
iPhone 5c uses technology from 2012; it was already terrible to use as it approached its end-of-life in 2017. Old phones just don’t really have the lifespan that computers do. (In contrast, my iPhone SE–which is using 5-year-old technology as well–is still an excellent phone.)
I think that’s increasingly not the case. I’m writing this message on an iPhone 6s which honestly still feels great. I had the battery replaced a couple years ago but aside from that I haven’t had any problems with it - all the apps I run on it feel smooth and responsive. (And in some cases better than my desktop since they aren’t running through electron.)
If not for the camera and iOS support inevitably ending, I don’t see much reason to upgrade.
If not for the camera and iOS support inevitably ending, I don’t see much reason to upgrade.
I think the iPhone 6S is actually the oldest phone to which this applies. It was a big step up in processor speed from the 6, and I think it marked the point at which phone cpus hit "fast enough". Hopefully apple continue to support the 6S for at least a couple more years, because I don't think there's any technical reason why they can't.
Notably it has also 2GB of RAM, when the older devices have 1.
One of the kids' phones is an SE which is pretty much the same internals as the 6S and it's still good.
One of the kids' phones is an SE which is pretty much the same internals as the 6S and it's still good.
The definition of "ancient" is probably not the same for your laptop and for a planned-obsolescence apple mobile device
Ancient, unsupported, and shrinking as older devices are broken or unused and no new device is built. There aren’t many reasons to target 32-bit iPhones, unless it’s a hobby.
32-bit iPhones run iOS 10, so if you have a deployment target set that far back you should support them.
Right, I meant in the context of bringing Open Source tools to 32-bit ARM platforms. I don't think the people holding on to their iPhone 5Cs would bother with OCaml. Of course, if a hacker wants to do it, it's great.
I too am typing it from a 2015 computer.
It's not just about electronic waste, many low power embedded platforms are still ARM 32 bit.
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?
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.
Depends on the kind of software. POSIX compatible C requires few, if any, source changes. Code that makes direct syscalls will need more work.
It's worth pointing out that MacPorts still has a lot of modern tools and utilities working for PowerPC Macs. This is despite PowerPC Macs being 'officially' stuck on GCC 4.2 (unless you install newer... through MacPorts), ancient Mac OS X frameworks and barely any developers have a PowerPC machine at hand (because why would they).
MacPorts also mostly supports Apple silicon. It's pretty cool!
Hah, and arm servers were already gaining an economic edge before Apple’s consumer product switch.
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.
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
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
Time for OCaml mobile :)
This is cool stuff, love to see functional programming growing and developing.
This is cool stuff, love to see functional programming growing and developing.
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?
What is the current state? Does ocaml support bitcode?
Rust had bitcode support since 2018: https://github.com/rust-lang/rust/pull/48896
Good. One more reason to look at rust. Main motivation is webassembly for me
There is an OCaml interpreter that does run a bitcode, is that what you're referring to?
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.
[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.
OCaml compiler isn't LLVM based and LLVM bitcode is not supported.
When they released the first arm64_32-based watch they rebuilt all existing apps on the app store for that architecture from bitcode.
There is no support to bitcode, but there is no major advantage to support it, so it doesn't seems to be worthy
tvOS and watchOS require bitcode, but yes I agree that's not major advantage compared to work required to support it.
... to the language which lacks multi-threading
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...
https://github.com/prismlab/parallel-programming-in-multicor...
It should land pretty soon I imagine.