The project is proprietary and won't be open sourced.

No. It's purely for teaching about compiler development and design, that's it.

In fact, I will be using it to show you how can you lower directly to machine code with it.

Wow...

I was not talking about the compiler but the toolchain.

If you want the extensions, you are saying you don't care about portability. Which is fine, but one of the reasons I made Odin is because GNU C is not available everywhere.

I understood but even then that argument doesn't really make sense as I said in the article. It's kind of agnostic for the language.

That's because of the Windows file system (NTFS) being a lot slower than the defaults on Mac and Linux. So what works well on Windows doesn't work well on *nix, and vice versa.

Well there is now `radlink.exe` which comes with the rad debugger, and for many projects, it is faster than `link.exe`.

For my stuff, I've not found it significantly faster, but I know others have.

I do cover that point already.

bsky.app/profile/ging...

odin-lang.org/docs/faq/#wh...

It is possible to target the MSVC toolchain from Linux (even if it is not straightforward), and then even "test" it with "Proton" but that's not the same as testing it on an actual Windows machine.

At least develop for a platform you have, at least have a VM/emulator for it.

Regarding the cross-linking from Linux aspect, this is one thing that kind of annoys me. I understand why many people want to do cross-linking, but if you don't have a Windows machine to test on, that's the equivalent of not even testing your code.

P.S.

I'd also argue that some people want to use MinGW for "ideological" reasons, either out of hate/spite for Microsoft of some kind (not wanting to use Windows and wanting to cross-linking from Linux), or because MinGW is open source and MSVC isn't.

There are some tools out there (see github.com/Data-Oriente...) that allow you to download a standalone MSVC compiler/linker/etc without having install Visual Studio; contains only the bare minimum components.

Most people appear to want MinGW just to minimize the download requirement, but in short, you are going to need to download the Windows SDK (and other libraries) any way. This is the problem of developing on Windows—you effectively need to use Microsoft’s "stuff".

MinGW is also kind of a mess in itself. So outside of libc(++), you will suffer.

For C, some libraries that have a C interface may rely on specific C++ symbols directly; assuming the existence due to toolchain ABI assumptions. This does happen in practice, even if it is rare.

For C, they are "meant to be" ABI compatible in theory, but in practice they are not for non-obvious reasons.

For C++, their ABIs are incompatible. Most 3rd-party libraries that are precompiled will also assume the MSVC toolchain, and not MinGW.