The reason people buy RHEL is because you can get support for any problems. Consumers are not gonna get that so they might as well just run CentOS Stream for example.
1. Fedora in collaboration with GCC maintainers keep GCC on the bleeding edge so it can be used to compile the whole Fedora corpus. This validates the compiler against a set of packages which known to work with the previous GCC
2. I think the rust team also builds all crates on crates.io when working on `rustc`. It seems they created a tool to achieve that: https://github.com/rust-lang/crater
I would assume the .NET guys have something similar already but maybe there’s not enough open code to do that
Rust also has the advantage of having no ABI. Binary interface is a whole lot more difficult to maintain than code interface.
C# has multiple technologies built to deal with ABI (though it probably all goes unused these days with folder-based deployments, you really need the GAC for it to work).
In many cases the build output also has hardcoded paths unfortunately
so doing `brew install` inside a container with the proper volumes it’s not sufficient to fix the issue. Everything would have to run from within the container as well.
However there is no official roadmap regarding C23 support, and now with the whole safety discussion going on and Secure Future Initiative, probably will never happen.
Additionally clang is a blessed compiler at Microsoft, it is included on Visual Studio, so whatever MSVC doesn't support can be done in clang as alternative.
They have added one feature (typeof) from C23, so maybe they will add the rest when they release C++26. Or maybe they won't. Microsoft is an expert in inflicting the cruelty of providing just enough hope.
C++26? There are having issues with delivering C++23, since the whole change in security focus with Rust, Go, C#, Java first, C and C++ for existing codebases, and most likely one of the reasons Herb Sutter is no longer at Microsoft.
Oh wow, I don't write C++, so I didn't know how bad the situation was. My recollection that MSVC always implemented C++ standards posthaste is clearly outdated.
Yup, we are never getting C23. Good thing C11 is decent enough, I guess.
I think he's referring to C specifically, not C++. It's true that modern versions of MSVC are compliant (and they're also typically faster at implementing features than gcc and clang), but for the longest time there were subtle differences in their C library. To this day I don't think they support VLAs, which are technically standard C (At least until recently, I'm not sure about the latest versions, hopefully someone more knowledgeable can say more).
For C (not C++), MSVC got C17 in 2020, apart from VLAs - which are never planned. No real roadmap for if/when it will get C23 - which is not just fully implemented in GCC, but the default used standard.
The irony is that Microsoft was the very last MS-DOS compiler vendor to support C++ in their C tooling with Microsoft C/C++ 7 in 1992, that changed with the release of Visual C++ in 1993.
Haha. That sounds like something Sonnet 3.6 would do, it learned to cheat that way and it's an absolute pain in the ass to make it produce longer outputs.
Okay, but at that point why bother with the intermediate OCI images? Especially with nix, if you're gonna use Nix you may as well build the OS directly (i.e. use NixOS).
OCI isn't a particularly good image format, the only thing it has going for itself is that it's the thing Docker uses. I would absolutely not be surprised if 90% of future bootc OCI images are built with Dockerfiles.
reply