71–80 of 103 posts
Earlier quoted context omitted.
> 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?
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.
Earlier quoted context omitted.
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.
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 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.
Earlier quoted context omitted.
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 well most developers aren't actually using Linux. Then it would be Windows and not Mac OS. Is Mac OS any popular outside USA?
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 devel…
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.
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?
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?
There is no support to bitcode, but there is no major advantage to support it, so it doesn't seems to be worthy
Earlier quoted context omitted.
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.
The subject of the conversation is developers, who are almost by definition luxurious professionals.
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.
Earlier quoted context omitted.
> 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".
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.)
If not for the camera and iOS support inevitably ending, I don’t see much reason to upgrade.
Earlier quoted context omitted.
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 well most developers aren't actually using Linux. What??
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...