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.
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
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.
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.
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?
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
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.
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?
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 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.
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.
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.
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?
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:
nindalf|5 years ago
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.
EduardoRFS|5 years ago
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
nicoburns|5 years ago
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.
mattgreenrocks|5 years ago
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.
heavyset_go|5 years ago
babaganooj|5 years ago
monadic2|5 years ago
blargmaster33|5 years ago
[deleted]
saagarjha|5 years ago
EduardoRFS|5 years ago
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|5 years ago
This is cool stuff, love to see functional programming growing and developing.
cageface|5 years ago
weitzj|5 years ago
What is the current state? Does ocaml support bitcode?
EduardoRFS|5 years ago
sanxiyn|5 years ago
UncleOxidant|5 years ago
alderz|5 years ago
ahnick|5 years ago
ChrisMarshallNY|5 years ago
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.
MaxBarraclough|5 years ago
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/
momothereal|5 years ago
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.
dathinab|5 years ago
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.
berkut|5 years ago
secondcoming|5 years ago
scott31|5 years ago
gmfawcett|5 years ago
https://github.com/prismlab/parallel-programming-in-multicor...
smabie|5 years ago
nephanth|5 years ago