51–60 of 139 posts
Offtopic, but I'm distracted by the opening example: > After all, you don’t want to be building your iPhone app on literal iPhone hardware. iPhones are impressively powerful, but you wouldn't know it from the software lockdown that Apple holds on it. Example: https://www.tomsguide.com/phones/iphones/iphone-16-is-actual... There's a reason people were clamoring for Apple to make ARM laptops/desktops for years before A…
Why does this person have such negative views of GCC and positive bias towards LLVM?
"And no, a “target quadruple” is not a thing and if I catch you saying that I’m gonna bonk you with an Intel optimization manual. " https://github.com/ziglang/zig/issues/20690
I like the code editor style preview on the right. Enough to forgive the slightly clunky scroll.
It also doesn't really tell me anything about the content, except where I'm going to see tables or code blocks, so I'm not sure what the benefit is.
Given the really janky scrolling, I'd like to have a way to hide it.
This article should be ignored, since it disregards the canonical origin of target triples (and the fact that it's linked to `configure`): https://git.savannah.gnu.org/cgit/config.git/tree/ The `testsuite/` directory contains some data files with a fairly extensive list of known targets. The vendor field should be considered fully extensible, and new combinations of know machine/kernel/libc shouldn't be considered in…
But that doesn't mean the article should be ignored in its entirety. LLVM's target triple parsing is more relevant for several projects (especially given that the GNU target triple scheme doesn't include native Windows, which is one of the most common targets in practice!). Part of the problem is that for many people "what is a target triple" is actually a lead-in to the question "what are the valid targets?", and trying to read config.guess is not a good vehicle to discover the answer. config.guess isn't also a good way to find about target triples for systems that aren't designed to run general-purpose computing, like if you're trying to compile for a GPU architecture, or even a weird x86 context like UEFI.
But for the rest of us, I'm so glad that I can just cross compile things in Go without thinking about it. The annoying thing with setting up cross compilation in GCC is not learning the naming conventions, it is getting the correct toolchains installed and wired up correctly in your build system. Go just ships that out of the box and it is so much more pleasant.
Its also one thing that is great about zig. Using Go+zig when I need to cross compile something that includes cgo in it is so much better than trying to get GCC toolchains setup properly.
I like the code editor style preview on the right. Enough to forgive the slightly clunky scroll.
> Go originally wanted to not have to link any system libraries, something that does not actually work It does work on Linux, the only kernel that promises a stable binary interface to user space. https://www.matheusmoreira.com/articles/linux-system-calls
Why does this person have such negative views of GCC and positive bias towards LLVM?
I have intense respect for the history of gcc, but everything about using it screams that it's stuck in the past. LLVM has a lot of problems, but it feels significantly more modern. I do wish we had a "new LLVM" doing to LLVM what it did to gcc. Just because it's better doesn't mean it's perfect. Basically, you can respect history while also being honest about the current state of things. But also, doing so requires…
Earlier quoted context omitted.
I have intense respect for the history of gcc, but everything about using it screams that it's stuck in the past. LLVM has a lot of problems, but it feels significantly more modern. I do wish we had a "new LLVM" doing to LLVM what it did to gcc. Just because it's better doesn't mean it's perfect. Basically, you can respect history while also being honest about the current state of things. But also, doing so requires…
Honestly, I love that both exist with their respective world views.