I feel this is more a mindset thing and less about the langauge/ecosystem. It's not that hard figuring out how to call the C# compiler and what actually goes into compiling a C# project. Yet, even though I know all this and how MSBuild works, and how solution files work, and parts of the default SDK MSBuild targets ... I still like that things just work out of the box.

At work I maintain most of the project files and some of the surrounding tooling for our product and being able to clone the repository and opening the solution without having to configure or do anything else is still very high on the priority list since it makes starting out easy, it makes just opening up the project and making a small change easy, etc. Some of us switch between languages, products and projects multiple times a day and this sort of thing is a major help in not spending as much time setting up things.

On the other hand, even though I very much like understanding things beneath the surface, I'm still very much lost in how JS bundlers work¹ and Java with Gradle or Maven is also very mysterious to me. Probably also a function of the frequency and time I spend on setting up those things beyond just writing code.

___________

¹ It also doesn't help there there's lots of things that simply cannot work in the browser, e.g. importing CSS or JSON files as JS modules, that the bundler makes magically work in some way.

I have problems with both. Trusting Visual Studio to build everything means you don't have any idea how to build anything without it. Once you get to C, for some reason you're now writing a makefile to tell the compiler how to feed files to the linker and wrangling with getting it working cross-platform. Or you throw CMake at the problem, but that requires some background knowledge about the ecosystem.

Compared to `cargo build` or `go build`, the GUI-first nature of .net and the build-your-own-toolchain approach of C feel like they're extreme examples of different ends of the spectrum.

Other way around for me. I started out as a c/c++ developer working on the command-line with gcc/gdb and emacs and makefiles. I did over a decade of that, and I'd agree that there is a kind of satisfaction to building "from the ground up" on the bare metal.

But my last two decades have been pretty much all .net and I live a lot of each day in visual studio. I feel a couple of orders of magnitude more productive in .net and I find it hard to imagine why I would want to use any other tools at this point. For getting stuff done, .net is hard to beat.

> C and starting from the ground up with just a text editor and a compiler was quite eye opening.

yes, yes it is. Its fine for teaching, but my word when you're dropped into a large project with no context, it really really sucks. especially if someone is doing "clever" stuff (I'm looking at you research engineer writing "optimised" c++)

I was dropped into a Unity VR project with a C++ plugin than called out to a fancy backend. Unity is a bit of a arse to use because so many information is locked in videos.(thank fuck for LLMs) Everything being c# turned out to be really rather good. Especially if you have a working intellitune.

Dropping out to c++ on the back end was utterly frustrating. cryptic errors, random stack traces, lots of tears. All of that can get into the sea.

For me, .NET Core has been largely solving this problem over time. In classic .NET Framework it was nearly impossible to make something without Visual Studio's arcane templates. The `dotnet` command simplifies a lot of that, and projects have a lot less boilerplate.

> and this is exactly the thing I didn't like.

It is something that you do learn to like when you understand what is going on, but actually just want to fix a problem.

Not that the way the C compiler, linker, execution environment has any significant connection to how C# works. But you have seen the computer on a different level. By the way, seeing the operating system is another level entirely and writing one was an eye opening moment for me that I can only recommend.

Sure, C/C++ is interesting not learn how the toolchain works, but that's a different goal from successfully compiling software with large dependency trees.

Xdebug (php debugger) is not very popular imho.

I think because PHP devs are most likely JS devs too and the developer experience becomes different for every language. Logging works everywhere.

Sorry, I didn't mean PHP just works. I mean "it just works" is what PHP devs say about their stack.

I mean you can always use the dotnet CLI if you want

Perhaps more to the point, you can also use the filesystem view and edit the config files manually rather than by GUI magic if you prefer (or if you need to diagnose a problem in a solution resulting from different projects having people do different magic GUI things, because comparing files side by side is much easier.)