This feels more like an internal turf war inside Microsoft. The general open source strategy with .NET Core and VS Code has been running long enough that I don't think it's just a smoke screen. But there's probably plenty of different interests inside Microsoft that are at least partially in conflict.
The Azure side probably doesn't care about selling Visual Studio, but they care about developer mindshare and reputation. The Visual Studio side seems to be in a more difficult position, I assumed they can just live from the enterprise/everyone else split and focus on enterprise-y stuff to still sell Visual Studio. But it looks a bit to me like VS Code and the .NET cli have become more of a competition than they'd like.
And the worst mistake here might not have been pissing off the .NET community, but pissing of the people working on .NET for Microsoft. I mean in the end this is the same, but pissing off the people working on .NET would result in a much more thorough destruction of trust with the community in the end.
But I have zero inside knowledge here, might just be weird decisions driven by internal politics or whatever.
There are people on record that it was the Azure division head Scott Guthrie who gave permission to open source ASP.NET Core (which at the time was part of Azure). Later the asp.net team merged with the .net team and brought the open sourcing with them.
VS has no place anymore. The velocity and mindshare is with VS Code. VS with its visual designers had its place .. but desktop is dead and Xamarin competes with frameworks without costly IDEs.
As a very longtime iOS and Linux dev turned Windows and .NET dev (with some rust on the side) - who has used VSCode, VS, and Xamarin for multiple years - no.
There is a place for a featureful IDE with robustly implemented build, debug, and package management capabilities working out of the box with multiple languages and entrenched technologies.
I do very much like VSC and use it all the time for anything involving text, markdown, cross-platform C++, javascript, and even rust...but Visual Studio is as much of the Windows or .NET dev's toolkit as Xcode is a part of a dev in the Apple ecosystem.
VSCode is great. However, there is plenty of space for VS: it is also very strong, and has a long history of deep and extensive integration into very mature technologies. VS is still getting better year over year and while I see VSCode as competitive in some spaces, it is no contest in others. If VSCode is to replace VS, it has a very long tail of issues to address, the resolution of which would probably raise both boats anyways.
I agree, and the competition is at this point more between VS and other full-featured IDEs like JetBrains Rider, which is my tool of choice for .Net-development.
But, what I didn't know until this recent debacle, is how there is a theory that the reason the .Net-tooling in VSCode is so bad is the same reason we had this watch-debacle. There was some discussion on that in the other HN-thread: https://news.ycombinator.com/item?id=28968231
I think in this case it's more like "let's not implement something for one language".
In VS the Solution Explorer lists Project Items, not files. Eg it lists DLL References. This means the entire tree view goes through the IVsProject interfaces and you open Solutions and Projects, not folders.
VS Code works on files only and doesn't have a project system that can specify file nesting rules. The simple ask in the PR could be implemented, but it seems arbitrary and other languages will ask for their own rules. (Vue?)
I've only ever used VS for hobby/side projects, and even 10 years ago it was leaps and bounds better than what I have to use for my professional day to day work now (code completion, debugger are the two things that I miss basically every day).
The tools that I use now have these features, but they're such a joke in comparison. The code completion has no notion of "code", it's just looking for similar words.
I use VS and VS Code for different things today. VS is much better for something it's made for like a C# project with a solution/projects, and VS code is great as something that works with an existing file structure like an old Java project or a folder full of random Python scripts.
VS Code still has good code completion/etc but it doesn't seem able to match the instant responsiveness of VS.
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.
I'll add my 0.02$ for rider too.. it even works (in EAP) for m1 arm... I do use vs code and rider depending on if I'm debugging something on the server or need to save the small amount of ram I've got on my air for debugging in the browser.. but m1 Rider is FAST.. far faster than even rider in linux on my xps with 32gb of ram
This is what keeps me on Visual Studio. It's free for personal and open-source use, so I use it at home.
Since I know it and am familiar with it, I make my employer pay for a commercial license at work. In the grand scheme of things, it is not that expensive in a commercial setting.
VS Code is great, but I do not think it is a comprehensive replacement for Visual Studio proper when doing full stack .NET development.
Intellisense is not that good. Intellicode is missing. Managing nugget packages is not so well integrated. It's harder to debug and investigate memory leaks. I can't see code coverage in the editor or run tests with right click straight from the method I want to test.
It's usable for sure but the development it's not as fast as in Visual Studio.
I still use VS Code if I want to modify some files like XML, json, yaml, and I don't want to fire another instance of Visual Studio for that.
VS used to be heavy and bloated. But that was a long time ago. I use VS since 2010 version. It improved by leaps and bounds since then. New 2022 version is almost as fast as VSCode, if you have a good PC.
Microsoft's official C#/.NET extensions for VS Code use OmniSharp to provide IntelliSense, so I think they are becoming a lot more friendly on that front.
As others have already pointed out, OmniSharp is "good enough", but what's built into Visual Studio is still a lot better.
I get the all products pack every year personally and it's worth every penny. One of the two software packages i break my "no subscriptions" rule for, and the only one i'm not even salty about doing so.
They all kinda support editing all languages - syntax highlighting ect. but the ui/menus/tools/refactoring/etc are all tailored in each app the the desired language
I happily pay for rider license every year. When you make so much money as a dev, investing in the tool you use every single day makes a lot of financial sense. Even if it makes you 1 or 2% more productive than VS it pays for itself (in my experience the speed boost alone is so worth it)
You can use the EAP builds for free in exchange for some stability issues, which in my experience have affected me all of 0 times. You can even download EAP builds from the toolbox for convenience by clicking on Rider and switching to the "Versions" tab.
EAP is free, and the subscriptions also work as a one-time payment by giving you permanent access to the latest-at-subscription-start version when accruing a year's worth. So you can pay 1 year and not renew, and it's the same as just buying the thing.
It's not really about the cost. It's about the principle of having to pay any amount of money to be able to do development work at all with your preferred choice of OS/editor.
Attaching a price to your ability to onboard a language with your favorite workflow changes how you view that language and the motives of its maintainers when compared to the alternatives for that platform. Java has no such barrier to adoption on Linux, for example, because IntelliJ happens to have a community edition.
Visual Studio's community edition is something entirely different from IntelliJ's community edition. IntelliJ is open source[1] but Visual Studio is proprietary with tricky license terms[2] that limit it to companies of a certain size, among other things.
Note that Rider already supports C/C++ on Windows with the Rider for Unreal Engine fork. This fork is planned to get merged into mainline Rider sometime next year.
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.
I doubt that. Unless you specifically target win32 and its non-core replacements (like classic full-fat C#) there is nothing that VS has to offer that outdoes other programs.
For the non-web world specifically, the part that was Windows Server and Windows Desktop is simply a dead end outside of niches. And within the niches, comparisons are not all that relevant since... they are niches. If you have a specific job for a specific tool, then trying to compare that with something that does not meet those specifics isn't all that helpful.
Most of my C/C++ work that remains doesn't even target windows anymore since there is no purpose for it. The super small subset that does is just things like device drivers, and that's more a property of the OS than of the project itself.
I do not think Windows desktop is a niche. It doesn't have the same percent of development it used to, but in absolute numbers it didn't decline.
Many people are using the Windows desktop and many old and new software is being developed.
Speaking of which, I feel the need to rant a bit: developing for Windows using QT is much more nicer than with any MS framework. MFC is a nightmare. Windows Forms was deprecated in favor of WPF which no one cares about. From C# you can't use Direct X or Vulkan with ease.
Maybe MAUI will bring a better experience. But they need to do something for C/C++, too. Maybe buy the rights to use QT and integrate it with Visual Studio if they don't want to develop a good framework. Or buy the framework from Embarcadero (the one used by C++ buulder). But don't force people into MFC mess. I presume that even their own developers hate MFC with passion.
Winapi was ok in the 80s. MFC was ok in the 90s but we are in 2020s.
That's probably why people 'like' certain tools, they are still working inside that context or environment and then there are no other tools that do that thing well.
But that doesn't make the tool a great tool in absolute terms. That is also the problem with this type of comparison, some people come up with arguments that are tangential at best. If you use literally anything else (anything that is not winapi, win32, forms, mfc, wpf or some legacy xaml) then Visual Studio is just a limited experience at best, and a steaming pile of crap in most cases.
This goes for more software obviously, if you want to write C# but try to do that in Xcode, you're going to have a bad time. Same for when you need to write a Kubernetes controller in Go, that's going to suck really badly in VS or XC.
There are a few remaining systems that really benefit from unmanaged languages and strong OS-integrated tooling (the niches that were mentioned), but the mass development practises going on today are basically non-desktop and specifically non-windows-desktop. This means that a tool that was designed to be specifically for windows-desktop (or macOS-desktop for that matter) is unlikely to be optimised for anything else.
Windows Desktop as-is might not be a niche, but building local native desktop applications is. Even if you target Windows Desktop right now for a new application, it's likely that it's going to be some crappy CEF/Electron thing. And yes, that's crappy, but it also means you get to use much more of the knowledge/mindshare/community that is out there which is bigger than all desktops combined.
VSCode is still pretty sparse on the debugging side of things. I've tried to chase down heap corruption with it and the lack of data views, complex watch/breakpoints really limit it in that scenario.
CLion is getting there, it's not quite as good yet but was still much better than VSCode.
> The tools that I use now have these features, but they're such a joke in comparison. The code completion has no notion of "code", it's just looking for similar words.
Presumably you are not using anything built on the Eclipse, Jetbrains or NetBeans with any language they support? (PHP, Java, Kotlin, Python)
Because out of the box and without any extras all these three beat Visual Studio easily once you start doing anything advanced except GUI, and NetBeans had a reasonable story to sell even there.
On refactoring the story is if not night and day then at least dusk and broad daylight.
Try to polygot programming on JetBrains without extras, meaning managed / C / C++.
Similar to what is going on here with Microsoft, they refuse to support what Eclipse and Netbeans do for free, as means to sell Clion licenses, and then make you run two IDEs in parallel.
Correct, although for many (most?) of Jetbrains products it is free for students and one can apply for licenses for open source work.
That said, for most .Net devs I know the first thing they do after installing Visual Studio is installing Resharper just to get it up to the same level that IntelliJ (including the open source community edition), NetBeans and Eclipse (both open source) provide out of the box.
To be honest, not needing to write legacy C# and C/C++ applications have replaced VS for me.
It's not a replacement for VS itself in that regard, but the activities that used to be bound to that IDE moved on over the years.
Whenever I have to load some old project into VS, it feels old, slow and clunky compared to other tools. The limitations on the structuring on-desk, metadata, building, linking etc. are very annoying as well for projects that ended up having more than just generic Windows Desktop targets (or even if they are highly specific editions/versions). I suppose that might be because other tooling outside of the process of the 'write-debug-release' chain has moved to broader and more interchangeable concepts where VS has remained basically the same for the last decade.
I mean at this point I have truly no idea what I'm talking about. But I would always bet on Azure against Visual Studio in a fight. The earning potential for Azure is simply far, far higher than for Visual Studio. AWS has shown that the cloud is a recipe for printing money, and I trust Microsoft to follow the money.
Yes. And IMHO Azure wins. But there are managers, goals and compromises. IMHO this was a compromise. The Azure division is interested in a universal available runtime. The tooling group provides a free editor but had goals of earning VS licenses.
I can only guess but I think Big Scott, lesser Scott and Julia will have a meeting soon. The .NET community is at a boiling point and they should really avoid a community which takes dev productivity in their own hands. Because that is the garantueed end of visual studio.
> The .NET community is at a boiling point and they should really avoid a community which takes dev productivity in their own hands. Because that is the garantueed end of visual studio.
sounds like .NET is almost the kind of thing I'd use then, because in a world without Visual Studio, I might not be punished for choosing to use .NET but not VS
I've always thinked of MS as filled with old fashioned managers, caring only about legacy stuff and killing any good initiative MS Research came out with.
I was amazed they'd try something new like cloud. I thought they will stick to the desktop and and MS Office until someone will snatch it from their dead cold hands. But Ballmer went and Nadella came. I still think that the company has a lot of Ballmers hidden in a lot of places, waiting for the opportunity to pull the breaks if they sniff that something interesting might happen.
People keep saying this, but they obviously have no idea. Desktop isn’t dead and nowhere near it. Just because web and mobile app developers think so doesn’t make it true.
There are several industries in which desktop applications are a must. Any application with the needs of multiple windows automatically rules out web and mobile stacks, even if they happen to work on desktops.
I would say most industries. Anything that requires creating any kind of digital content (images, videos, CAD models, electronic schematics, chip design, PCB layout, etc), most of the scientific software, all rely on the computational power and the speed of the desktop applications.
People probably refer to generic functionality like personal PIM (which boils down to webmail, Facebook products and Google products) as no longer being desktop-based.
While there are industries that still use local compute and local rendering, that is exactly what it's about: industries. You might have image and video and audio manipulation. There could be hardware control. Maybe there is 'appliance'-like functionality such as POS and vending systems. But those aren't really the mass-desktop scenario that it used to be. That is mainly 'work' usage.
There is this section that you can carve out that does still exist in the traditional form and that is gaming. But that essentially turns the 'desktop' into a gaming console.
Legacy configurations that require things like an actual mouse pointer and multiple windows (or that dreaded MDI document-window-in-a-window interface) are generally left in two categories:
1. bad implementations
2. niche implementations
The first one means investment to fix, which is generally not going to happen if there is no commercial incentive for a commercial piece of software. The second one is a niche and doesn't represent desktops in general.
Desktop dead. That would be a nightmare scenario for me as I much prefer coding desktop based apps/games compared to web things. I code web things professionally. It's where the money is. But the fun is in desktop/mobile/console apps/games.
It would be more precise to say: Desktop business apps are dead. That is almost 100% true. Some lingering ghosts still exist.
At work we are replacing a huge app which had a C# UI with a micro service based app with a React UI.
While the backed is nice, that React UI feels like crap compared to the old UI. The only reason we are using an React UI being that "it's modern".
Not every app should be an web app.
Electron has full support for multiple windows, and you can even do it with a regular browser app if you get a little creative (windows can talk directly to other windows they create, and/or all windows could talk to the same server and receive push updates via websocket)
Can you elaborate? The last time I looked into this (including a little now) showed that, yes, you can create multiple windows, but there are not good solutions for communicating between the windows. Electron's own documentation shows two, options between local storage and Electron's IPC mechanism. From what I've read, IPC is not good for more complex multiple window apps. So one needs to use a local network communication method.
And old apps written in C++ and running on a Pentium 3 will beat the crap out the Electron app which will feel sluggish even on modern hardware.
The only reason Electron exists is to enable Javascript developers do desktop apps without learning other languages and frameworks. Electron is not a solution for desktop development, it's a solution for lazy developers.
As a long-time .NET Developer, there's no way in hell you're replacing my Visual Studio with Visual Studio Code. I'll sooner switch to Rider (which I have a license for and like to use on a Mac.) VSCode is a text editor on steroids. Visual Studio is an IDE. Full stop.
I'm in the same boat. I use VSCode for JavaScript and that is only because I'm required to by my workplace. Otherwise I'd be using Webstorm.
VS is on a whole other level than VSCode when it comes to C#. I suspect that many people here haven't really used the IDE features and VS' debugger for more than simple breaking and inspecting a variable.
Yes, if you have a hobby project, you can use VSCode instead of VS Community Edition just fine. But if you are dealing with concurrency errors, performance analysis, dump analysis, and very, very large projects, you can't use VsCode. VS' GUI is also a lot more flexible than VSCode's. In VS I can have a lot more information present where in VSCode I need to constantly switch windows.
There's some new smart code suggestion features on VS2022 that I've never seen anywhere else before. But talking about VSCode, it depends. For C# development it doesn't replace VS at all, far from it. Omnisharp is not good enough. There's scenarios and scenarios. I code game development things with C# on VS. And I work professionally coding JS stuff with VSCode. Different scenarios.
I use the community version. VS Code, while being extremely good, is still far behind VS. I love using VS, as a solo developer. The integration it has WRT .NET projects is amazing.
VS Code is not a replacement for an IDE. While I only know IntelliJ, I assume VS must be similar. In short, VS Code is a replacement for Notepad, and not for an IDE. It's not as well integrated, not as thought-out and capable. The only thing that saves it IMO is the remote server mode.
VS is my daily driver and I absolutely agree that VS Code doesn’t come anywhere close to a fully fledged IDE like VS.
But VS Code is far more just a text editor and that you can run and debug many languages in it in my opinion means it meets the criteria of an IDE.
If I was forced to switch from VS to VS Code I would be miserable and feel handicapped, but infinitely more productive than just having a text editor and the dotnet CLI.
So VS Code is absolutely a “replacement” for VS, but only for a poor man with a very limited set of required features.
All the above being said, I don’t ever see VS Code truly replacing VS, but it’s a competent IDE considering its both cross platform and free as in beer.
Visual Studio does a lot more than just visual designers. The integration for .NET is fantastic. And I love Visual Studio Code for everything else :) Visual Studio still has value.
Visual Studio's debugger alone makes it worth. It's not that it's the most powerful debugger (not like WinDbg), but it's so polished for most things I would typically do, also mixed callstacks for certain languages, Parallel Stacks and certain other features.
I still like very much the experience of developing on Visual Studio. And it's not about visual designers because I don't do Windows Forms and WPF. Intellisense and intellicode do a wonderful job with code suggestions, there are lots of tools for formatting, debugging, jumping through code, refactoring, each accessible through shortcuts. It makes the development much faster for me compared to using a text editor.
And when .NET MAUI will ship, I guess we will have a visual designer for that.
VS has enabled fast and lazy development for me. I don't have to memorize if a type has a method or property or what parameters a method has. I just type a dot and the IDE will tell me everything I need to know. It's good for concentrating on business logic instead of details of frameworks and libraries, but less good for interview questions if you come around people which have fixation on details.
Desktop for the bulk of generic CRUD apps is dead. But that has always been the case because that's not the main benefit of having a desktop.
Same for 'what was your first computer', there is a whole generation (or maybe two of them at this point) that started out with smartphones and didn't get to the 'using a desktop' level until much later when preparation for work life required it.
It's basically the old, "Let's run it up the flagpole and see if anyone salutes it." If no one complained about hot reload being a proprietary feature after being presented as a free improvement in the SDK then they wouldn't have reversed gear.
Hot reload was removed from the .NET 6 code at request of Julia Liuson, corporate vice president of Microsoft's Developer Division. She probably hoped she will sell a few more licenses of Visual Studio by gimping the open source tooling.
> The Visual Studio side seems to be in a more difficult position, I assumed they can just live from the enterprise/everyone else split and focus on enterprise-y stuff to still sell Visual Studio.
While VS is my daily driver and I prefer it to Code and Rider, I have no idea how they make a profit. _No one_ buys the retail sticker priced SKUs, you either go through MSDN or Microsoft Partner Network and pay a fee hundred € for access to basically everything Microsoft puts out.
A hot-button issue gets corrected now, but then they continue to make subtler moves. Why say you love open-source if you keep the juicy bits of Visual Studio Code closed-source? More like you love open-source... for making money.
Microsoft is a big company with changing microcultures all the time. They alone as a whole should not take credit for their open-source endeavors. In general, big contributor names should be emphasized more, so that we know when they leave Microsoft or the project.
> Why say you love open-source if you keep the juicy bits of Visual Studio Code closed-source? More like you love open-source... for making money.
I really dislike this mindset. Sure, it's disappointing that some pieces of VSCode aren't open-sourced, but man, they open-sourced an entire IDE and plugin ecosystem. That's such a fantastic contribution to the open source community, and yet I see comments like yours that treat it as if it's negligible and somehow want even more? Why is it that, say, Intellij never has to deal with this level of scrutiny? The work MS did even includes a bunch work on existing plugins they don't even own - I know this because my plugin was one which they got their engineers to do a couple months of volunteer work on.
If MS wants to retain a few small pieces of tech to pay the engineers that make a fantastic IDE and ecosystem free and open source for everyone, so be it. You say "making money" as if it's some great evil - how do you think all those open source engineers get paid?
IntelliJ does not have a long history of abusing its monopoly positions to the detriment of its users and developers, nor does it own the biggest default open source code collaboration platform. I think anyone who is not heavily skeptical of Microsoft’s long term intentions here (whether they are explicit goals or just natural outgrowths of being a monopolist) is either shockingly ignorant or willfully naive.
Things will get ugly sooner or later, to the dev industry’s detriment. Insisting that one of the biggest tech companies on earth, with a history of abusing its power, go further than smaller companies is not unfair. In order to retain trust, Microsoft needs to put restraints on its own behavior and be open about it.
I doubt that Microsoft was looking to get into the "advanced text editor" business. Their biggest money maker is Azure, they made a text editor that promotes Azure.
It's becoming less open source now. And they lock away the APIs they use so that you can't reimplement the functionality yourself. Many interesting parts of the Python extension are closed source. AI autocomplete too. Remote development is closed source. What will they pick next? Conditional breakpoints? In-IDE HTML preview?
If you use Proposed APIs you can't publish your extension on the Marketplace and your user needs to run a fork of VS Code, or the nightly build. Either way, your user loses access to the Microsoft closed source extensions which are DRMd to only work with official VS Code build. Like the remote development extensions I mentioned, Pylance, GitHub PR commenting etc.
Also, sticking to existing APIs is an inherent disadvantage when Microsoft can add whatever APIs meet their exact needs. Nobody could build Remote Development or Live Share until ms did because the APIs didn't exist.
IntelliJ doesn't pretend to be anything it's not. VSCode does act as a bit of a trojan horse with its proprietary extensions. I do think it's a bit of a smokescreen
This. Thousand time this. I will never understand the entitlement of some people. The only explanation at hand is that they probably just don't understand the way the world works?
Inexorably, the locus of making money moves from using one's skill and ability to build software to skimming rent off enormous capital investments: billions of ad impressions, billions of e-commerce transactions, millions of cloud cpus,
Somebody built awesome software and dares charging money for it? Bring on the tar and feathers!
The key difference between the two situation is, that the vs code team does it juicy features as a secret project. Dotnet watch was developed, tested and licensed in the public and stripped out last second.
VS Code behavior you can accept as a open core or commercial plugin thing. The other thing was just a theft.
I want to extend in this a bit: Scott, Damian, Scott, David, Rich, Immo ... If you read this: fight for a clear ahead of time separation of commercial and non commercial features. Many of us can understand that Microsoft still sells dev tools but we do not like bad communication and stuff taking away which have been there already (at the same time we also think that .NET can only become truly awesome when free tools exists ... because für your competition these exists).
The reason why I feel somewhat encouraged is because my understanding is that this exact group of people fighting to keep this in is why it was reverted. I have no idea who knew what when or how anyone would have reacted without public scrutiny but David Fowler has been hyping hot reload since at least May on Twitter and it seems obvious to me that he and many other team members were 100% behind the planned dotnet watch hot reload approach. Maybe public outcry gave them the ammunition to fight this fight, and I may be naive, but I have a hard time thinking that at least some of that group wasn’t against this decision from the beginning (though who knows if they even learned about it much in advance of it being public).
This is reductive, but I am going to repeat the idea that you should not be trusting Microsoft in the first place.
Their GitHub acquisition, VSCode, and CodeSpaces are clearly a moat-building towards making GitHub yet another version of Office 365 where you have to pay $$$ for developer tools. GitHub's workflow already bears little resemblance to a "real" Git workflow, and in 7-10 more years I predict that they will try to marginalize it until you can't actually make commits if you're not using the web UI.
Everything Microsoft-related should be considered closed-source and avoided if you have interest in Open Source as more than just a license. The management at Microsoft has way too many non-technical people focused on "user engagement" and "mindshare" for them to think in terms of OSS principles. They are not evil – they just don't "get" it. So I would strongly suggest avoiding any developer-focused products from Microsoft for the next 10 years if cross-platform parity or Open Source are high on your list of values.
If not, that's fine too. I advise buying and using a Windows laptop for a first-class Microsoft Developer Experience.
> GitHub's workflow already bears little resemblance to a "real" Git workflow,
Which is? Email lists? GitHub is much easier to deal with than scouring through email threads. It may work for Linux, GNU, and more, but it doesn’t for the majority of devs.
Email isn't the only way Git is used. In fact, email is explicitly external to Git; Got just cooperates well with it.
You know what else Git cooperates with better? Push, pull, rebase, squash, a whole world of branching strategies etc. GitHub's PR model is artificially gimped against many useful features of git, to the point where I suspect they actively hate users creating commits and want themselves to be the only ones who can make them. Their PR model actively fights any kind of commit-based review; to the point of erasing access to old, rewritten commits.
Even their diff model is proprietary — and inadequate. You can only diff individual files against previous pushes, and that too only if you manually marked each file as 'viewed'. Diff two tips (read: heads)? Forget about it. You can't have it. Do it out dumbed-down PR way, with a pileup of correction commits you can't squash properly, and be happy you were given the privilege.
Those are refs. Not commits. GitHub removes access to the old commits of a branch when the branch is force-pushed (say, after a rebase). I'm interested in comparing the branch in its current state against it's previous state.
tl;dr you can put commit hashes in the place where the parent comment put tags, and your exact use case actually has a dedicated link on the PR page.
The PR interface actually exposes this for force-pushes, but the UI discovery for this is horrible. It turns out that the "force-pushed" part in the little message in the github UI is actually a link. This link points to the diff between the old and the new HEAD of the branch.
Pressing the "force-pushed" link works fine for me on private repos too. It could be that they fixed this recently, I only found out about this feature ~a month ago. If it still does not work on private repos for you, maybe try reaching out for support. It could be that there's some bug you're hitting.
Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews?
All the git operations you listed work perfectly fine locally on a repo from github, it's only once you want to push to main you have to go through the review-gate and that's configurable.
Gitlab works mostly the same as Github, and for both of them you can configure the merge-strategy and PR requirements per repo. Next competitor in line would be Gerrit with a quite different approach, which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name and you don't need to fork the repo first, but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR.
In the end, they are all the same and you learn to work with it. None of them really fight against the core of git.
Reviewable is an example of a product that put in the extra work to support rebase. Its interface is more complex than GitHub s but that's partly from the rebase support and partly just the decision of their designer.
> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews?
GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit.
> All the git operations you listed work perfectly fine locally on a repo from github ...
Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with the assertion that GitHub wants to break that dependence.
> Gitlab works mostly the same as Github
False. GitLab lets me compare different versions of the same MR against each other. Without extra work. It's right there in the MR diff UI. That's literally what I wanted.
> ... for both of them you can configure the merge-strategy and PR requirements per repo.
Some configuration allowed. Not the same kinds. GitLab's squash-and-merge strategy actually works, even lets me set the commit message! GitHub built their incomplete implementation of sth similar only recently, to catch up with GitLab, but also stopped half-way. That last bit is what gives rise to the suspicion that started this thread: that GitHub doesn't really want to be Git-compatible and doesn't care about Git. GitLab, OTOH, introduced this feature, a long time ago, because it saw people were already using Git this way. I couldn't accept doing development in my company without some kind of auto-squash support.
> which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name
Gerrit has branch names, I don't know what you're talking about. In fact, it has better support than GitHub. I can push a locally created branch and ask for the branch to be reviewed, all from the `git` CLI. I can even change the branch name, push the new branch, delete the old branch (on remote, from local `git` CLI) and all of my changes and their reviews remain intact! The equivalent on GitHub would require me to close my current PR and open a whole new one!
> and you don't need to fork the repo first
This is a good thing. `git clone` is already a fork. I shouldn't have to make two forks, one of them through some external interface, and another through the `git` CLI, just to be able to work on sth. Git's branches are already excellent, there's no need for yet another way to keep separate versions of a repo.
> but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR.
No. I think your understanding not Git derives almost entirely, if not predominantly, from GitHub. And this is exactly what we're talking about in this thread. GitHub would like to impose their way of doing things on everyone, irrespective not what better ways exist (and have existed since before GitHub was born).
In Gerrit, each change is a commit on a branch. There are versions of commits, each of which is a patchset. This is good and desirable, because it leads to cleaner branches. I like this, I want this, and I've been using this since before GitHub was launched.
GitHub's only supported way is to create a commit for every tiny edit, irrespective of whether it's significant enough to be enshrined forever in the final branch as an independent commit of its own. This adds noise. Buncha commits with just the message 'Typo'. Ugh. Imagine running into one of these in a git blame, months later. Imagine looking at a git log. Just ugh.
And what's the alternative with GitHub? Squash all commits in a PR into a single one. So now I can't have more than one significant commit in the same PR. Okay, fine, whatever; can I at-least make one PR dependent on another one, like a commit that has a parent? Nope!
> In the end, they are all the same and you learn to work with it.
As I show above, they're not all the same. Can't learn to work with sth you need that's missing.
> None of them really fight against the core of git.
If I can just git push and git pull and get all my work done with just that, then yeah, none of them really fight against the core of git. But then why would I use them instead of a headless SSH server?
They all fight against Git, in different ways, when they decide to build custom UX for one workflow or the other. They're telling you what workflows they support. If your workflow can't fit into them, well then they can't do the job you want them to.
This is why both Gerrit and GitLab were built the way they are today: their users needed a certain workflow (feature) and they cared enough about those users that they grew to support such features. GitHub has ... other users ... it cares about more. Not the power users. But power users also are more likely to be defiant, to resist control.
The equivalent for fixing typos in a chain of commits in github is configure squash on merge, commit --fixup/--amend and finally push --force. Force pushing might ring some alarms and sound counter-intuitive, but as long as it's on an open PR that's not yet merged it's perfectly fine. In a way one could argue this is more git-native compared to Gerrits refs/for which does some server side processing of the Change-Id and whatnot to map it into one change. Biggest problem here is Githubs UI for indicating force-pushes is an abysmal line in the comment-list, instead of a showing all major updates to the branch in one place and mapping the comments to each of them.
Just small remark that I personally much prefer the Gerrit model over Github, both UI and the git interaction :) Just don't see either as any big barrier or deviation from git workflow, as long as you stay away from the github client of course.
I'm aware of these (and magit makes it seamless). The problem is with the force push that these necessitate.
> Force pushing ... it's perfectly fine
Not when it breaks the reviewers' process.
> In a way one could argue this is more git-native compared to Gerrits refs/for which does some server side processing of the Change-Id and whatnot to map it into one change.
It is that server-side mapping that allows comments and discussions on changes to carry over from one version to another. Unlike on GitHub, where I've had to re-raise the same comment after a force push. It sometimes feels like GitHub's treatment of force pushes make it a dark UX pattern to slip bugs by reviewers.
This problem is big enough that I sometimes simply can't review a branch on GH. Unlike on GitLab, where I can be sure my comments, even when outdated, won't simply vanish.
> Biggest problem here is Githubs UI for indicating force-pushes is an abysmal line in the comment-list, instead of a showing all major updates to the branch in one place and mapping the comments to each of them.
For a platform whose main selling point was "Look, pointy-clicky web interface!", this is a major problem. The PR discussions interface sometimes feels like it hates the humans interacting with it. You better not ever let it get too long!
Force pushes aren't the only thing it makes you hunt down, BTW. Got an old comment somewhere? Perhaps one that has been "outdated" by a force push (aside: this is server-side processing, BTW, and worse than Gerrit)? Well, good luck finding that in a sea of hidden comments.
> Just don't see either as any big barrier or deviation from git workflow,
'Git workflow' is not the same as 'GitHub workflow'. GitHub doesn't currently mind you using them for the former, but they'd much rather you do things the latter way.
Writing code isn't all there is that can be considered 'real work'. Reviewing code is also real work. Re-reviwing code after it has been checked in is also real work.
GitHub is a real hindrance for reviewing code, and the dumb practices its infantilised review system forces you into make it a nightmare to re-review code after check in.
I stopped caring about the phylosophy behind Open Source. I am interested if a particular piece of software will allow me to do my stuff easier, better, with lower costs and in a future proof way. Of course I would prefer the source code to be available but I can live without it.
This 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 infrastructure.
By now a lot language servers exist. They have various levels of quality, and the purpose built solutions like VS or the various Jetbrains products are often markedly superior.
But many of them are more than good enough for a lot of developers, and they allow turning even Vim into a full-featured, powerful editing environment. (Neovim 0.5 has built-in LSP support)
This all started out with VS Code, Typescript, and the LSP specification, and Microsoft deserves a lot of credit for kicking off this trend.
But something that probably started out as a way to popularize VS Code and Typescript has turned into a movement that makes the chosen editor much less crucial and more of a commodity.
This almost certainly wasn't the intended outcome, or at least a side effect that wasn't anticipated.
Hence also the recent steps to counter this trend, like restricting the new Python LSP or this newest .NET drama.
Microsoft earned back a lot of good-will from developers with Typescript, VS Code, .net core, Github, npm, .... Many younger devs have lost the mistrust and disgust that was common in certain spheres not that long ago.
They probably feel confident enough now to shift gears and aim for lock-in and control.
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.
On first hand it'd be weird to expect MS to do everything for free
On the other hand the way they handled it (initially they made it free, OSS and promised fanciness) is kinda poor.
On yet another hand maybe they just really sucked at communication, priorities and stuff this time? hard to say.
On yet another hand2 .NET maintainers are really open about a lot of stuff, it's easy to talk to them - let it be asp .net or roslyn/compiler project which makes me giving them the benefit of doubt
Of course I don't expect them providing everything for free. But I expect them to stick to their promises and commitments and not to widraw a feature once they committed to make it available.
>> We underestimated the number of developers that are dependent upon this capability in their environments across scenarios, and how the CLI was being used alongside Visual Studio to drive inner loop productivity by many.
That's a very odd way to say "modern developers don't use Visual Studio."
According to the Stack Overflow developer survey, Visual Studio is still the second most-used IDE by professionals. Granted, SO has a very strong .NET community so there may be some bias.
HN has a comparatively weak representation of C# and Visual Studio users (and "enterprise"/"big company" programmers as whole) so there is some inherent bias here against VS also.
IDE specifically, or editor in general? The former wouldn't really surprise me since most of the editors I see friends and coworkers using aren't really IDEs per se; I mostly see people using VS Code, Vim, Sublime, and maybe emacs occasionally. The only IDEs people I know ever talk about using besides VS are Jetbrains products and I guess Xcode for iOS dev.
This is not just for primary editor. So if I use VSCode as primary, IntelliJ for Java development and vim for server side/small file changes, I'll be counted in all 3.
I think it's possible to customize it to be an IDE in some cases, but at least for some languages, it's not one out of the box. I have no idea how most people use it, but it doesn't seem obvious to me that all or most users would necessarily use it as and consider it an IDE.
Well, out of the box, it really only supports JavaScript and TypeScript - and those two are at the level I'd consider to be an IDE (i.e. with debugging etc). Any other language requires an extension. But most major language extensions also provide a full suite of IDE services. Although sometimes that is spread across several different extensions - as with e.g. Java - but in that case, there's usually also an extension pack that gives you the unified experience.
Pretty encouraging sign given the drama the last few days. In addition to the community response, it’s pretty clear that a number of dotnet and MSFT team members went to bat hard for this. Really happy to see that they won out.
Encouraging? Microsoft demonstrated here that the move wasn't because of quality or that the change was unable to be in the OSS version, they demonstrated that they only act a certain way because of the backlash. If they would have stand their ground, they would have given the image that this change didn't live up to their wanted quality, instead this demonstrated that they are just giving up to peer-pressure because they don't want to lose "developer love".
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 create an open and vibrant ecosystem for .NET. As is true with many companies, we are learning to balance the needs of OSS community and being a corporate sponsor for .NET. Sometimes we don’t get it right. When we don’t, the best we can do is learn from our mistakes and be better moving forward.
>Thank you for all of your feedback and your contributions over the years. We are committed to developing .NET in the open and look forward to continuing to work closely with the community.
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
That's certainly one way to frame it; though, I think, a very narrow view.
They knew they were going to lose some 'developer love' when they originally made the decision. They went ahead anyway. So, your framing isn't adequate.
What made them walk back is when they realised _how much_ they'd lose. Which happened only because lots of people were outraged and vocally spoke against it. Far more than the number of people they were expecting.
It'd be naive to believe they didn't know they're going to lose some, especially given how long they've kept up their charade of 'MS :hearts: OSS'. What's more likely, and supported from evidence of their similar behaviour in other parts of their OSS charade, is that they thought they could get away with it this time too.
> What made them walk back is when they realised _how much_ they'd lose.
What's wrong with this arithmetic? Don't independent FOSS organizations have similar metrics when deciding on things? They want to progress while causing the least amount of grievance to the community, and when it exceeds expectations, they walk back?
For example, I hate Firefox's new tab UI; I think it's terrible, and one of the reasons I stopped using it. But, apparently I'm in the minority, so Mozilla Foundation is okay losing my love. Had the backlash exceeded Mozilla's expectations, wouldn't they have walked back? What's extra sinister about what Microsoft's doing here (besides other valid points of criticism)?
> What's wrong with this arithmetic? Don't independent FOSS organizations have similar metrics when deciding on things?
Math is never the problem; it's what you use it for.
> They want to progress while causing the least amount of grievance to the community ...
Except that's not what's happening here at all. Cannibalising a promised, existing OSS feature in favour of one's proprietary tool is not "progress". What caused them to back off wasn't a desire to minimise "grievance to the community", but harm to their self-image.
I'm not going to deign your sidetrack about another, actually Open Source product, making UX decisions, with a reply in connection to this charade of OSS.
I may have done a bad job articulating what I meant. My main point was that I feel (based on like 2nd and 3rd knowledge so could be totally wrong) that this had as much to do with public pressure as it did with a number of well known (and certainly many not well known) dotnet and Microsoft team members who fought for an OSS feature that they had been developing and promoting for most of this year.
> ... a number of well known (and certainly many not well known) dotnet and Microsoft team members who fought for ...
That wasn't enough. I'm sure they fought for it before the public did. It took the public calling out Microsoft's duplicity for them to change face. I'm sure the insiders' voices helped, but they weren't adequate.
IOW, Microsoft will absolutely do it again, if they think they can slip it past the public. Outrage can't be a driving force for very long, and they know that.
I'm so glad I'm not at Microsoft anymore. Her decisions might be great for Microsoft's profit margins, but my god does she hate people getting "stuff for free"
Open source leadership can only be handled well by people who have experienced and participated in Open Source. If Microsoft is serious about Open Source, they need to put in charge someone who's done this before. They have plenty of people who can lead this; Scott Hanselman, Miguel Icaza, Nat Friedman...
Whoever approved this in the first place has shown a shocking level of incompetence in understanding how the developer ecosystems have tilted in the last decade.
Actually Miguel Icaza would be very good as a head of .NET development. He's not only managed to build a large open source code base but he also managed to win money from it. He's also a good developer, so he knows how to please developers.
>Her decisions might be great for Microsoft's profit margins
On long term such decisions will hurt profit margins. I wouldn't hire managers that only think about short term, in an attempt to enlarge their bonuses.
It’s nice that they walked back on immediately blowing up the whole .NET ecosystem.
But it’s not like everything is fine again. The Foundation is apparently a bit of a mess and the C# debugger is STILL not available on VScode versions built from source.
That and that they would ever even consider doing this still discourages serious investment into .NET.
> we inadvertently ended up deleting the source code instead of just not invoking that code path.
Well, maybe it would be avoided if ability to review would not be blocked from start. And community would note it during code review.
(obviously, no one believes this explanation and we understand what was actual reason. And thanks to all - hopefully anonymous and which will stay anonymous as long as needed - Microsoft employees who gave real info to Verge)
If 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.
>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 community feel betrayed and fear the decision will have lasting effects on Microsoft’s open source efforts.
This is the kind of boneheaded, "my division above all" move that should see someone removed off any product decisions whatsoever.
Reminds me of the people at Android that keep pushing big carrier SMS group chat protocols, where everyone can tell from miles afar they are just a blind caterpillar sensing their way along some local optimum gradient descent in whatever mismatched incentive hell their big corp job has landed them.
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.
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.
Or the manager wrote a ticket to make the change, and the developer just did it as part of their job with no fanfare or minimal resistance seems like the most likely scenario
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.
What’s extensions do you have installed? VS 2019 significantly fixed performance issues, and I work with both C++ and C# projects much bigger than a few hundred lines of code. Debugging UWP and ASP.NET Core is a lot slower than debugging regular old WPF or SWF but that’s because of all the bloat during the deployment step.
If you have VisualAssist or Resharper installed, disable them and see the difference.
Yeah, I have no problem with cs or cpp files thousands of lines long. Granted, I'm loading the project from an NVMe disk, but I just don't see what you're running into.
Are you loading your projects from a network mount? Because the timings you're giving don't make any sense for those specs. I could believe it if the files aren't local though since VS does a lot of disk IO in the solution directory.
A company I worked for used network shares for years for C# projects. It was a tad bit slower loading the solution but if you didn't know, you'd never notice.
You can trace a lot of these problems to their bone-headed decision about a decade ago where they refused to see where things were going and kept rationalizing not moving to 64-bits.
I have some moderately sized solutions that take forever to open and chug to a halt and start paging like crazy with unresponsive UI if I don't disable all the code inspections and Intellisense. This is on a brand-new i7 with 32GB of RAM and a NVME SSD. It pegs itself at that 32-bit process memory limit and thrashes. It's worse if it is a modern web app with a bunch of JS involved.
And so I've used Rider almost exclusively for the past fifteen months or so...
And they promptly shot themselves in the foot with it as you now need 64bit components for their form designers, even if you exclusively build 32bit apps.
If you maintain an application with legacy form components that are only available in 32bit, you now need to continue using VS2019.
Granted, who builds 32bit in year 2022 but VS claims to support 32bit, which it actually doesn't fully.
There is still a chance that they will fix this before release but I highly doubt it.
Perhaps that's one of the reasons they have didn't switch to 64 bits earlier? If the IDE is a 64 bit process it can only render external components at design time if they are 64 bits. To be able to render 32 bit components at design time they would need to be hosted in another 32 bit process. I can see how that feature would be complicated and expensive to develop.
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.
As a small aside to the general discussion, I don't think I've ever seen an accepted reviews list that long. To me that in and of itself speaks volumes about how the development team feels about the business politics going on here.
I’m developing my own tools in my own language going forward. Between the two languages I use professionally (Swift & C#), there’s enough bloat and secret sauce going in the apparently open source sausage I’m still getting indigestion.
He admitted no such thing. He said there was a mistake in the "execution" of the decision, when it's the decision itself that's the problem, not the way they executed.
> We underestimated the number of developers that are dependent upon this capability in their environments across scenarios, and how the CLI was being used alongside Visual Studio to drive inner loop productivity by many.
"Hot Reload"
Every day we step closer to ANSI Common Lisp 1994 golden standard. May this mainstream change hasten the renaissance of Image based software.
I generally like Microsoft as a development stack, but this kerfuffle is reminding me of issues I've had trying to get the folks working on Graph API to understand why being able to access existing APIs with a different kind of credential than they currently support would be helpful.
If you're not familiar, there's two different ways to authenticate against Graph API - either directly with the user's credentials, which is good for webapps and user-interactive desktop stuff, and using application credentials, which are suited for server-side workers and daemons and things like that. All the Graph APIs have weird hodgepodges of permissions that are allowed, which sometimes make sense (getting the current user's profile at /me) and often don't make any sense at all, and are just not supported because they didn't bother.
If you've got a lot of time on your hands, you can whine and open UserVoice items and rally other people up and lobby, and sometimes they'll get off their asses and do something. Or not, like some of the Teams presence and calling APIs that have been unimplemented for three or four years now...
Yet more reason I'll continue avoiding anything MS, probably forever. Also makes me more thankful than ever for Emacs. VS Code is obviously part of their embrace/extinguish strategy, it's a nice editor, but I won't use it on principle.
If the only reason they walked back this decision is the backlash, they'll continue to try get away with whatever they can. Their culture obviously hasn't changed for the better.
I no longer have any skin in this game because I decided to move all our products and the whole stack away from Microsoft five years ago, which meant lower costs, ability to easily go all in on K8s, etc.
Nothing about their strategy since has made me regret that decision.
Kind of sad to see them flailing about and screwing up, burning goodwill from VS Code and the like.
Don't dismiss .NET itself so easily. As you can see from this incident, there are elements even within Microsoft that don't inherently value the open source nature of the .NET team! .NET Core/.NET 5+ are already open source and highly philanthropic in nature. That doesn't change just because a completely different team--the Visual Studio team--is profit-oriented.
I learned to program with C# back in 2007. I have been following .NET and C# for more than a decade now, I look back fondly at my time with the language and people there. However, if the team is having this much internal struggle why would I ever come back? Why would I stake my business on another Oracle when there are much better alternatives?
Can you point any useful, non-esoteric language with a thriving ecosystem where the internal team doesn't have problems? I don't think so. For real drama, check the history of some well-known compilers/suites (such as the whole gcc vs egcs debacle), you'd be amazed.
All languages have had problems, some are resolved, some are not.
Ruby I think has managed to avoid very material conflicts.
Python hasn't, it's a comparative shit-show.
Java had -huge- problems in the past but was able to move past them and is stronger for it.
C# is in wait and see territory for me. I -really- love the language and tools but if I had to start a new company today I would probably go with JVM stack until this sort of stuff is sorted out. A few years from now I hope I will be saying the same about it as Java.
Maybe it sounds egotistical but for me it is a perfect fit. I know they will support running .NET on Linux because of Azure. I know they will support cross platform development with MAUI because they want developers and market share. It's not like they force me to target Windows Server with only SQL Server available as a data store. I don't plan to give up Visual Studio. So I don't have any reason to abandon .NET and C#.
Also, C#/.NET is kind of jack of all trades, you can do anything but a small subset of development where having a garbage collector stays in your way.
As for alternatives, I dislike Java, Python is less performant and not usable for large projects, Rust, Nim, Haskell, Elixir are not as usable and well polished. Kotlin is nice but it does not have any benefit over C#.
I would love for Rust, Nim, Haskell, Elixir to pick up some steam, become more usable, have larger communities, much more libraries. But until then, C#/.NET is the sweeetspot for me. I still dabble in C/C++ from time to time and that makes me grateful C# exists. I am even inclined to double down on my .NET bet by starting using F# along with C# because it feels like a very nice language. It seems to enable even faster development while being more concise and needing less tests written.
Been using .NET since 2010. To this day I haven't found anything better overall (for my use cases). Experimented here and there, but in the end I always come back to C#. And it keeps getting better.
They fumbled the cell phone era
They half heartedly entered the hardware business with poor results.
They have a few golden gooses that could be disrupted at any time (Windows, Office).
The biggest asset is dotnet and if they fumble that they will go down hard.
I'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 .net 5 is much more cumbersome compared to eg. golang (important for startups).
Don't get me wrong - I do like C# - it is a nice language (at some point it was better than Java), but current Java and other jvm langs and tooling (lombok) are great too or better (Kotlin) and current web/cloud ecosystem is all but not .net related.
if you develop for windows desktop or some .net oriented organization (some do politicall decisions) use .net, but if you can make your own decision and you develop for web/cloud just don't use .NET
> even newest .net 5 is much more cumbersome compared to eg. golang (important for startups).
FYI .NET 6 + C# 10 has a ton of work invested into removing the "enterprise boilerplate" experience and making the language and frameworks more akin to node or go in terms of effort/LoC required to spit out a program:
Still Visual Studio is simply broken compared to IntelliJ (especially for web dev) and there is not even a fraction of libs available for .NET compared to Spring Boot (take a look here: https://start.spring.io/)
I have done both since they exist, alongside C++ and Web, and regardless of Microsoft tries to sell, UNIXy shops don't care about .NET Core.
Sure, C# is more pleasant to use than Java, and the language has almost C++ like capabilities for low level coding, but it lacks the 25 years of cross platform experience. And one can always include a native library if required, JNI might be boilerplate but it doesn't bite.
One cannot pick random .NET library and use it on .NET Core, most likely it is using .NET Framework APIs, COM or Win32 calls.
So already there, the ecosystem is reduced to the libraries whose authors have bothered to port to .NET Standard or Core.
Then issues like this, or how MAUI is being handled versus what Uno and Avalonia achieved on their own, show the ongoing power struggle.
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.
The real problem is just how damn expensive it is to build anything inside Microsoft. It makes it hard and harder to justify spending the money. AFAIK it’s only getting worse. I expect in time that more and more dark patterns will creep in.
Even if “now” they listened, they still don’t understand. Developers don’t live and breath Windows and VS. MS continues to push Windows experience first. Look at the joke of VS for Mac…
I don't know how "evil" they are, but this incident made me drop any plans of ever building a web project with .NET Core. I like C# and would love to find an excuse to use it, but I'm not relying on a framework that MS will intentionally cripple because of corporate interests.
This is good, but given the amount of terrible decisions in the last few weeks from Microsoft I've lost all trust in them. This will pass, and they'll sneakily do something else.
It's clear from the reaction of the well known alt.net people that this problem is strategic, and coming from above. Nothing in this move signifies a change in that strategy.
Weird take IMO. I don’t trust MS and strive to stay away from their products where possible. Their acquisitions of a lot of OSS stuff make that pretty hard these days, though…
But I find it weird to expect perfect decision making out of an organization with hundreds of thousands of employees with a global influence. I don’t know any individuals with perfect decision making skills, so when you take the union of that and add hierarchy, I certainly wouldn’t expect a system of perfection. Especially when perfection is defined by some relative/personal standard.
I agree with your opinions that Microsoft will do weird stuff going forward and that this decision means nothing. It’s also irrelevant to me since I don’t use .NET for absolutely anything.
But if your “trust” in an org is based on them not making “terrible decisions”, I think it may be impossible to actually trust any org. Since inevitably at scale every org will make bad choices. Not criticizing you, just thinking out loud.
Maybe I'm naive, but I fully buy the explanation of "we decided to not have it in the OSS version due to constrained resources" (if I'm parsing the discussion correctly). That was evidently not the smartest move, but attributing it to malice is taking it quite a step further.
It's not malice. Your non-technical boss who says "well, if we have 3 other developers developing that API with you, it should get it done in one fourth of the time, right?" is not malicious either. But this kind of a boss doesn't "get" it, and neither does Microsoft. They don't seriously understand the mindset behind an open source project, and I don't expect them to in the future either.
So I avoid all Microsoft technologies, especially the lock-in ones like Visual Studio and .NET. I recommend you do as well.
There is nothing "lock-in" about .NET Core/.NET 5+. In fact, as you can see from this whole Hot Reload kerfuffle, even Microsoft themselves doesn't always like the spirit of open source present on their own .NET team!
.NET Framework is another story, and was (and still is) tightly coupled to Windows. It's the entire reason .NET Core was started as a separate open source effort. Honestly, we're lucky .NET Core was even allowed to live as long as it has. Now, it's philanthropic culture is directly butting heads with the profit-oriented culture of the Visual Studio team.
That's the thing – I don't understand why people will chain themselves to caring about all this when you acknowledge that “Microsoft themselves doesn't always like the spirit of open source present on their own .NET team!”
Does .NET have some breakthrough features or support that other languages don't have? Are job opportunities better than, say, Java?
I'm not understanding the upside here of following the Microsoft version of Keeping Up with the Kardashians.
Can we trust Microsoft with open source? - https://news.ycombinator.com/item?id=28968231 - Oct 2021 (223 comments)