Let's put it another way: There's a comment stating that the project requires complex and involved configuration, and it's a problem. A link is provided in res

Let's put it another way: There's a comment stating that the project requires complex and involved configuration, and it's a problem. A link is provided in response that demonstrates it to be the opposite. Turns out, as a reply states, it is equally an issue, possibly because of an assumption that a VM-based language must come with a significant amount of required configuration ceremony (even though counter-points to this, like Go, exist). .NET is configurable, GC modes can be changed, at startup or on the fly (within certain limitations), compiler options can be adjusted, but the default approach is for the users to do as little input as possible unless something does not perform to their expectations. > Running .net implies a lot, brings a lot of conventions and configuration with it, that's very dense. Dense and powerful and useful. But is it's own universe. > that it presents itself as a neutral blackbox binary [0] > .NET has orders of magnitude more carried assumptions & confirmation than Python. [1] This was posted without verifying whether these statements are true or not, presented as fact. It is not unreasonable to be upset if it happens every single time. You could compare this to how Ruby community feels that whenever Ruby-related projects are discussed, someone is bound to come and point out how it has terrible performance and is therefore unusable (I was guilty of this as well). Emotional embellishments and holier than thou attitude are insufficient to reframe this. When facts change, I change my mind, and if a statement turns out to be incorrect, I stand corrected, and it has been a great boon for acquiring all kinds of tidbits of technical knowledge here so far. At the end of the day, this is an informal setting, therefore the rules of HN and internet etiquette apply first and foremost. [0]: instead of easier to use pre-built docker images, quickstart guide ends up pointing to just cloning the source code, and doing build+run (dotnet run -c Release). This is as far as it gets from a blackbox binary. [1]: it only makes the assumptions that are safe to make, which are the same most other platforms are subject to - that certain POSIX and Linux (or macOS/FreeBSD) APIs and glibc or musl are available, that the runtime is present in the $PATH (or not, if an application is published as self-contained or natively compiled), that sort of thing.