Odin has poor support for Windows:
Additionally, the issue has a build script using a different compiler and the asker basically said it wasn't good enough for them.
[0]: https://www.jetbrains.com/lp/devecosystem-2021/cpp/
According to this survey, Visual Studio is preferred by 24% of respondents, just behind VsCode and CLion. And MSVC is the 3rd most popular compiler, just behing gcc and clang. And keep in mind these results are across all C++ developers, not just windows developers.
Your source does not support your claim at all.
Even though vscose and Visual Studio are reported as popular IDEs, you're not talking about IDEs. You're discussing compilers and compiler toolchains, which is not the same thing as a IDE. Microsoft's msvc compiler is not the same as Microsoft's Visual Studio. Visual Studio is an IDE which, among other things, uses msbuild and msvc compiler.
The poll you quoted states that 78% use GCC regularly, followed by clang being used regularly by 43%. Microsoft's msvc compiler is in 3rd place at 30%. The same poll also points out that 55% uses cake and 36% use Makefiles regularly, and Visual Studio projects showing up in 3rd place with 31%.
> by far a highly preferred environment for C++ programming on Windows
The survey doesn't split the responses up by OS. That's besides the point, I'm not trying to say MSVC is the most popular toolchain. I'm refuting the claim that if you only support MSVC on Windows that constitutes "poor windows support".
> Microsoft's msvc compiler is in 3rd place at 30%.
Yes, and the question for this was "Which compilers do you regularly use?". 78% + 43% + 30% = 151% which is greater than 100%. I'm assuming this means that respondents were allowed to select multiple answers. It seems to make sense to me that people that use MSVC commonly use other compilers when developing for Unix, but the reverse isn't true nearly as much in my experience. Besides that, MSVC is in 3rd place and pretty close to the same amount of users as clang which was the proposed alternative. In that case it really doesn't matter which one you choose to support because you'll be supporting about the same number of people either way.
Anyways, this doesn't matter to the claim that I was trying to refute. OP said that Odin has poor Windows support and pointed to an issue that basically said if you only support MSVC on Windows that's not good enough. As a Windows developer, that seems like an odd stance to take imo. This survey shows that a third of developers use MSVC across all domains, including Unix. This seems to imply that if you support MSVC, you're at least supporting a large percentage of devs.
Also, I didn't mention the build systems because that's irrelevant. You can use CMake and Make with MSVC or whatever compiler you have installed. I say this as someone that regularly uses CMake and/or Make to compile projects on Windows using MSVC.[0][1]
[0]: https://learn.microsoft.com/en-us/cpp/build/reference/creati...
You're the only one here complaining about MSVC. Have you stopped to consider why Rust and Odin and so many other languages are happily depending on MSVC instead of the alternatives? Or does none of that matter and your opinion is the only correct opinion?
There was no ad-hominem. OP pointed out your initial claim contrasts with the facts.
> Rust defaults to the MSVC toolchain. Surely you knew that. (...)
This reads like a non-sequitur. The claim you've replied to was that Odin had poor windows support, and OP pointed out that Rust also supported Windows without msvc toolchains.
> You're the only one here complaining about MSVC.
Sorry, you're clearly speaking while oblivious to the discussion. The message you've replied to includes a link to a ticket asking Odin to shed it's dependency on msvc. It's clearly titled "move away from msvc".
https://github.com/odin-lang/Odin/discussions/2047
I believe you owe OP an apology.
incompatible? incompatible with what? Ive been using it for years with no problem.
> You're the only one here complaining about MSVC.
The ad-hominem isn't advancing your cause lol.