[HN Gopher] OCaml: Add support to iOS/Mac ARM64
___________________________________________________________________
OCaml: Add support to iOS/Mac ARM64
Author : wczekalski
Score : 214 points
Date : 2020-07-28 14:47 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| scott31 wrote:
| ... to the language which lacks multi-threading
| nephanth wrote:
| Ocaml has multithreading support now though (it was merged
| recently iirc)
| yawaramin wrote:
| Not yet, but it's being prepared to merge.
| gmfawcett wrote:
| 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...
| saagarjha wrote:
| 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.
| EduardoRFS wrote:
| 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
| nindalf wrote:
| 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.
| blargmaster33 wrote:
| Since Linus cucked to the SJW everything he say is suspect.
| nicoburns wrote:
| > 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.
| babaganooj wrote:
| 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?
| saagarjha wrote:
| Depends on the kind of software. POSIX compatible C requires
| few, if any, source changes. Code that makes direct syscalls
| will need more work.
| DCKing wrote:
| 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).
| saagarjha wrote:
| MacPorts also mostly supports Apple silicon. It's pretty
| cool!
| monadic2 wrote:
| Hah, and arm servers were already gaining an economic edge
| before Apple's consumer product switch.
| EduardoRFS wrote:
| 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
| asveikau wrote:
| 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.
| EduardoRFS wrote:
| 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)
| enedil wrote:
| Most OCaml developers might be actually using Linux though.
| slezyr wrote:
| > 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?
| nicoburns wrote:
| 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.
| monadic2 wrote:
| 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.
| unreal6 wrote:
| They seem exceedingly popular in academia, it seems that
| most university students and professors posses them, even
| in computer science departments.
| freehunter wrote:
| The subject of the conversation is developers, who are
| almost by definition luxurious professionals.
| josephg wrote:
| 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.
| tambourine_man wrote:
| Of course it is.
| nix23 wrote:
| >But well most developers aren't actually using Linux.
|
| What??
| the_af wrote:
| 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).
| EduardoRFS wrote:
| 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
| pjmlp wrote:
| > everyone uses Linux for server
|
| And here I am deploying .NET and C++ solutions on Windows
| Servers, strange definition of "everyone".
| yawaramin wrote:
| Chill dude, 'everyone' doesn't mean 'literally everyone
| on the planet', it's a figure of speech :-)
| nix23 wrote:
| 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
| -_-...
| CurtHagenlocher wrote:
| 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.
| nix23 wrote:
| Thanks, peoples from HN would not have understood that,
| big thumps up!
| the_af wrote:
| 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.
| non-entity wrote:
| I wouldn't think so, from what I've read OCaml has pretty
| poor windows support.
| scythe wrote:
| They at least aren't using Linux on ARM laptops/desktops,
| which has been a year away for around a decade now.
| mattgreenrocks wrote:
| 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 wrote:
| OCaml has multicore now and seems to be doing well. Latest
| report: https://discuss.ocaml.org/t/multicore-ocaml-
| june-2020/6047/1
| heavyset_go wrote:
| 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.
| cesarb wrote:
| 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.
| heavyset_go wrote:
| 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.
| Vogtinator wrote:
| openSUSE Tumbleweed supports i586 and up.
| nix23 wrote:
| Tumbleweed is just great!!! That comes from a Arch and
| FreeBSD veteran.
| saagarjha wrote:
| Alpine Linux supports it.
| the_duke wrote:
| Well, even many mid-tier phones already have 4 GB RAM now.
|
| The demise of 32-bit was/is inevitable for personal
| computing.
| petre wrote:
| It's not just about electronic waste, many low power embedded
| platforms are still ARM 32 bit.
| wczekalski wrote:
| ARM 32 bit is supported by OCaml. Just not for iOS/MacOS
| since the 32 bit iOS devices are ancient by now.
| yjftsjthsd-h wrote:
| > 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".
| wczekalski wrote:
| I too am typing it from a 2015 computer.
| kergonath wrote:
| 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.
| saagarjha wrote:
| 32-bit iPhones run iOS 10, so if you have a deployment
| target set that far back you should support them.
| saagarjha wrote:
| 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.)
| nephanth wrote:
| The definition of "ancient" is probably not the same for
| your laptop and for a planned-obsolescence apple mobile
| device
| alderz wrote:
| 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.
| secondcoming wrote:
| Agreed. We moved to GH from Bitbucket and code reviews is the
| only thing that Bitbucket did better.
| ChrisMarshallNY wrote:
| 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.
| skrtskrt wrote:
| 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.
| aspenmayer wrote:
| 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.
| emmelaich wrote:
| I suggest https://www.gerritcodereview.com/
| aspenmayer wrote:
| Thank you, I'm going to look into this more.
| momothereal wrote:
| 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_af wrote:
| 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...
| fotta wrote:
| 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.
| outadoc wrote:
| 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 wrote:
| 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?
| alderz wrote:
| 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.
| dathinab wrote:
| 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.
| MaxBarraclough wrote:
| 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/
| vmchale wrote:
| Time for OCaml mobile :)
|
| This is cool stuff, love to see functional programming growing
| and developing.
| weitzj wrote:
| 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 wrote:
| There is an OCaml interpreter that does run a bitcode, is that
| what you're referring to?
| Gaelan wrote:
| 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.
| wczekalski wrote:
| OCaml compiler isn't LLVM based and LLVM bitcode is not
| supported.
| plorkyeran wrote:
| When they released the first arm64_32-based watch they
| rebuilt all existing apps on the app store for that
| architecture from bitcode.
| sanxiyn wrote:
| Rust had bitcode support since 2018: https://github.com/rust-
| lang/rust/pull/48896
| EduardoRFS wrote:
| There is no support to bitcode, but there is no major advantage
| to support it, so it doesn't seems to be worthy
| sanxiyn wrote:
| tvOS and watchOS require bitcode, but yes I agree that's not
| major advantage compared to work required to support it.
___________________________________________________________________
(page generated 2020-07-28 23:00 UTC)