My paranoid takeaway from this: you need to create big drama every time Microsoft does something like this. This won't be sustainable in the long run.
You need to make drama until they learn the lessons.
.NET Hot Reload Support via CLI
231–240 of 267 posts
Re: .NET Hot Reload Support via CLI
#232I just wrote a comment on the other post about this. I wonder how this decision was made _behind the scenes_. Either some negotiation happened and the Visual Studio team got some concessions (smaller target?) or it was mandated from the top. Both alternatives do not bode well for the VS team.
The Verge has an article about this.[0] >The Verge understands that the decision to remove the functionality from .NET 6 was made by Julia Liuson, the head of Microsoft’s developer division. Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash. Engineers at Microsoft that have worked on .NET for years with the open source com…
If a manager has more power to make decisions than the majority of the engineers involved in a product taken together, then something is wrong with the organization.
Re: .NET Hot Reload Support via CLI
#233Earlier quoted context omitted.
The Verge has an article about this.[0] >The Verge understands that the decision to remove the functionality from .NET 6 was made by Julia Liuson, the head of Microsoft’s developer division. Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash. Engineers at Microsoft that have worked on .NET for years with the open source com…
Sounds like Liuson needs to be removed from Microsoft. I'm not usually looking for blood, but since they put this feature back it confirms that there was no good reason for it to be removed other than pure greed.
But there might be other people like her hidden somewhere. To solve it, they should rethink the way decisions are made. Allow engineers to take part in the decision process.
Re: .NET Hot Reload Support via CLI
#234Earlier quoted context omitted.
The Verge has an article about this.[0] >The Verge understands that the decision to remove the functionality from .NET 6 was made by Julia Liuson, the head of Microsoft’s developer division. Sources describe the move as a business-led decision, and it’s clear the company thought it would fly under the radar and not generate a backlash. Engineers at Microsoft that have worked on .NET for years with the open source com…
While I'm sure the business drove the decision, some developer had to make the pull request, no? What I wonder is whether a "lose your job if you don't do as I wish" gun was stuck to a developer's head, or did they find the right developer with the right permissions to push this change through in spite of resistance? The former option gives me shudders, while the latter saddens me. EDIT: grammar
Usually they open a ticket, some poor guy has to execute it unless he doesn't want to lose his job.
Re: .NET Hot Reload Support via CLI
#235Earlier quoted context omitted.
At this point, VS needs to be put under VSC management. You saw the same crap with Office vs everything new.
yep, modern Visual Studio is a terrible experience end-to-end it takes at least 3 minutes to start, the UI designer takes 30+ seconds to appear, and starting your process for debugging takes 10+ seconds every single autocomplete takes a few seconds to appear even opening a 100 line .c file takes 10+ seconds, and they KNOW its bad because it pops up a dialog with a progress bar! this is all on a azure "cloud" instance…
Not my experience. And I have multiple instances of VS open each time. The only times it can become less responsive is due to extensions such as ReSharper.
Re: .NET Hot Reload Support via CLI
#236This is not directly related, but I think Microsoft regrets the commoditization of language editing features via LSP. In hindsight, editor independent language IDE features driven via a client-server model are such an obvious idea - to the point that I wonder why it took so long for this model to emerge. It makes so much sense to build the IDE features a single time, ideally re-using parts of the compiler infrastruct…
LSP is a solid concept, but if you did want to commodify IDE features, it leaves a lot to be desired.
I am implementing an LSP for a pet language, and the state of the documentation is quite shocking. When I first read the "spec", I thought surely I must only be at the intro/marketing brief since so many details are missing.
This is a JSON-RPC protocol and the documentation for all the object types is written in typescript. There's nowhere you can go to see a list of all possible json messages in json. And as you get farther into it, it feels less like a generally designed protocol and more like an interface to vscode in particular.
In general I wanted to use SublimeText and nvim as test benches for my LSP, but in the end I gave up because there were too many subtle gotchas when not developing against vscode itself using the base test project MS provides.
Don't get me wrong, I think LSP has been a great thing for the industry, but I suspect the actual goal was to commodify this type of editor plugin so other competing editors would not gain an advantage over vscode, and to do that in such a way that the result will generally be better on vscode.
Re: .NET Hot Reload Support via CLI
#237If they want .NET to really go mainstream outside Windows, they have to back off pushing for VS so hard. So far, they have been more convincing in getting me back into .NET than they have getting me back into Visual Studio, locking .NET features inside VS would just alienate me from both.
I only got back to .NET web development (after a long period of doing game development) only because .NET core was much more nicer and usable outside of expensive and inflexible Windows Server.
Doing .NET development is a very nice experience now. Especially with the ability to do fronted web with Blazor and cross platform mobile development with .MAUI.
.NET became usable for any kind of development beside low level systems programming where the garbage collector is not suitable. I would love to see the addition of AOT with the possibility to do manual memory management when you need to.
Re: .NET Hot Reload Support via CLI
#238Earlier quoted context omitted.
The problem is they're showing they will behave as badly as they're allowed to. Not terribly good for trust if it takes backlash for them to act the right way.
At least they shoved that they can undo a bad decision if the community asks for it. This reads like an apology and recognizing they've made a mistake: >We are always listening to our customers’ feedback to deliver on their needs. Thank you for making your feedback heard. We are sorry that we made so many community members upset via this change across many parameters including timing and execution. >Our desire is to…
I mean of course it reads like that - MS and similar corporations pay PR people quite a lot of money to craft messaging to frame things in the best possible way. This is not your personal friend or colleague asking forgiveness when they messed up, it's a multinational corporation acting in their own best interest, just as they did when they tried to get away with moving this feature from free to paid
Re: .NET Hot Reload Support via CLI
#239Earlier quoted context omitted.
For many workloads (at least .NET), JetBrains Rider. For C/C++ on Windows, well, you have VS Code and also JetBrains CLion, but IMO CLion is surprisingly rougher than Rider, even though it's older. You can get stuff done though.
Good luck doing MFC, ATL, UWP, DirectX debugging with VSCode.
The "some workloads" also apply for that. I don't know about DirectX, but the other ones might be doable as long as you create the project once in VS and then (for MFC and ATL) hand edit the normally tool-generated partial classes. For UWP, you'd have to hand wrangle the XAML. You'd then invoke MSBuild for building. AFAIK there's nothing super special about MFC and ATL that would make debugging impossible, but it's true I've never tried it in VS Code.
Re: .NET Hot Reload Support via CLI
#240I've quite unique experience beeing .net dev turning into jvm ecosystem. My decision to switch was based on fact that web is growing and .Net is simply...not fitting there. Specifically what I mean is current VS is just not usable for web dev (comparing to Jetbrains tools), but what is even more important - there is nothing close to Spring Boot in terms of ecosystem richness (important for corpos) and even newest .ne…
From my experience, Go is much more boiler-plate-ish than C#. They wanted a very simple language with very simple libraries. But if the functionality is not builtin, you have to implement it yourself. Go is faster to learn but it will take more time to develop something.