Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity? It takes a lot more time/energy to push public APIs and it's probably a very different team than the team developing the copilot extension. Seems a bit like a "don't attribute to malice..." kind of moment to me
> Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?
Wouldn't another way of saying that be "the Copilot development team is leveraging their Microsoft ownership to create products in a way not available to the general marketplace?"
The goal might not be to squash competition, but blessing one client with special treatment not available to others can still be anti-competitive.
Whether that would fall afoul of any regulation is beyond my expertise. Naively, most companies have internal APIs that are not generally available. But then most companies don't have paid public marketplaces on their platform.
Is it even not available to competitors? Visual studio is open source. Didn't cusor fork it and is building it features directly into the fork? Not doing something like this would make Copilot at a disadvantage.
Sort of. The core is, and the installable binaries with telemetry and properietary extensions are not.
The open source, telemetry-free version of VSCode is called VSCodium: https://vscodium.com/
> Didn't cusor fork it and is building it features directly into the fork?
Yes, in their recent interview with Lex Fridman they argued that life as an extension is too limiting.
The main reason we criticise Microsoft for doing this and not them is just their size and market dominance.
Why jump through hoops to make competitors better able to hotwire their own AI into VSCode, or hotwire Copilot into their own IDE, when it's easier to iterate fast and remain unpredictable?
> Why jump through hoops to make competitors better able
Because that is the competitive philosophy that allowed VS Code win in this space. It fits with that great quote from Bill Gates: "A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it."
By having VS Code give a priority to another MS/GitHub product that they aren't willing to give competitors, they're diminishing VS Code's value as a platform, and encouraging competitors to build their own IDEs rather than building on top of it.
But Cursor had to fork, so as a developer wanting to use them, you need to give up VS Code and install a new code editor, and you can’t just install a plugin. Very few can maintain a fork and get enough people to use their fork. Also what happens if you have two products that needed a fork? You can’t use them both.
I don’t know if it’s legal or not, IANAL, but it feels definitely anti competitive.
Seems like the only sensible comment in this thread so far.
Here's what I imagine it's like working on the Copilot team:
> Mgmt: "We need this feature, and we need in 2 weeks."
> Devs: "That feature is not technically possible."
> Mgmt: "Well, figure out a way to make it possible. That's _your_ problem."
That is exactly the sort of management that has landed many a company in hot mater before, including Microsoft.
Whether the managers remain ignorant by malice of incompetence is irrelevant. Directing your subordinate to do something that they should reasonably know would break the law or be anticompetitive is still illegal.
The see no evil defense is a piss poor defense that is more likely going to be used to show you knew exactly what was going on.
This doesn't fly when you're a company the size of Microsoft with the kind of influence and power they have. You can't just ignore the possibility or effects of engaging in anti-competitive behavior simply because it's convenient for you. That's not how it works.
Why not? They're survived for decades just shrugging off the law and paying off whatever minor fine there is years later. They started that model, now embraced by everyone from Google to Apple to Uber. Build it fast, get rich, worry about legality later.
Microsoft: we’ve just committed to an investment of two zillion dollars in co-pilot!
Microsoft to investors: don’t worry, you’ll get two zillion dollars of “value” launching next week , AND we won’t have to pay the bill for years! There’s even a chance our lawyers will win, and we will never have to pay!
Microsoft to devs: sorry, we spent two zillion on product so your profit sharing is going to take a bit hit. Thanks for your hard work!
The few people I know in the Copilot team(s) (not necessarily VS Code) are laser focused on prioritizing features based on customer demand, not top-down guidance :)
>Everyone is reading this as intentional anti-competitive practices.
Even if it is anti-competitive, I don't care. Why should VS Code have to support alternative AI assistants in their software? I understand why people would want that, but I'm not sure why microsoft has some sort of ethical or legal burden to support it. Plus it's open source, competitors can take it for free and add their own co-pilots if they want.
Are other extensions like Codeium[0] allowed to publish under the same rules? I'm not saying your comment is incorrect, but unless Copilot competitors can get the same treatment, it seems extremely unfair and anti-competitive.
They're allowed to fork VSCode and integrate their own service. Cursor did that.
VSCode is provided fully free as in beer and freedom. I don't see how this is different from Red Hat Linux integrated with RHEL services. VSCodium is your CentOS.
> VSCode is provided fully free as in beer and freedom
No, VSCode is a proprietary text editor/IDE from Microsoft. Code-OSS is provided fully free as in beer and freedom, and is currently what resides at https://github.com/microsoft/vscode.
Why would Microsoft not want other AI agent extensions to get the same benefits, which would benefit all AI agent users?
Edit: I have removed the portion of the comment which discussed the throwaway account.
Probably not. Please suggest to extension authors to dual-publish their extensions to OpenVSX and VSMarketplace. So far all authors I engaged with were happy do to so (except for Microsoft of course, who are the only benefactor of this wallet garden situation).
I also have an extension that I dual publish. I was surprised to see it’s getting as many downloads on OpenVSX as on the VSCode marketplace. I’m just glad it’s useful to more people for marginally no cost.
I think Cursor just mirrors the VSCode marketplace on their own servers. They used to have an ugly work around for installing extensions, but now it just works and I see links to https://marketplace.cursorapi.com/ inside of Cursor's extension browser.
Eh not quite. Famously, you can fork VSCode, but you can't use the VSCode Extension Marketplace if you do, which loses a lot of the network effect benefits of the VSCode ecosystem. (As far as I know Cursor is flat out violating Microsoft's terms of service with respect to the extension marketplace).
And a lot of the licenses for flagship Microsoft VSCode extensions for languages like C/C++ and Python don't allow using them outside of VSCode/Extension Marketplace so open source forks are crippled by default.
I believe this also blocks you from using Microsoft's proprietary language extensions, and they have been steadily switching the default language packages from OSS to proprietary.
Yes. You famously cannot use the C/C++ language server bundled in the C/C++ extension or Pylance. Who knows what other development tools they will lock behind their fork to the detriment of open source communities. Also you can't use their Remote Extension suite.
Red Hat provides support for their packages. If you're not paying for support, you don't get access to the repos. That makes sense to me. What does Microsoft gain by creating a walled garden? They don't provide support. All that they provide is hosting. The Eclipse Foundation provides hosting for free for OpenVSX, which is an amazing service to the community of people using VSCode forks that aren't allowed to access the VSCode Marketplace. Microsoft should either relax the ToS on the Marketplace or acknowledge OpenVSX as the one and only marketplace for extensions.
Hanlon's razor falls apart when it's used outside of personal relationships and in situations where billions of dollars are on the line.
There is no functional difference between a Microsoft that's really excited about Copilot so that it quickly integrates it into their products and a Microsoft that's hellbent on making sure Copilot gets to use secret APIs others can't.
> It takes a lot more time/energy to push public APIs
And, once an API is public, it becomes a lot harder to make changes to it. Iterating with a private API, then making it public once you've figured out the problem space, is a valid and useful approach.
Iterating on a private API is fine. Allowing your internal AI assistant to publish to the extension store while consuming those private APIs while prohibiting any competitors from doing so is not.
So was IE, back in the day, when they first "embraced" the web.
Today's "embrace" is of the web dev ecosystem, which before VSCode's dominance consisted of Jetbrains, other IDEs, text editors, etc.
Now with VScode and Github, they control much of the dev ecosystem, shrink competitors' marketshares by making them free to end-users (subsidized by other Microsoft businesses), expand them with new capabilities (even before secret APIs), etc.
It is really a shame to me that everyone believes Microsoft has changed and would never behave like they did in the 90s and prior. They haven't changed. They just decided -- for a time -- that another strategy was in their best interests. They're deciding that again, and going back to their EEE playbook.
(It also occurs to me that a lot of people here probably aren't old enough to remember 20th-century Microsoft...)
I don't care if it's malicious or not. The fact remains that this team is using their position inside Microsoft to make use of tools in another product that a competing product wouldn't get to use.
This is one of the things MS got sued for back in the 90s. They shouldn't be allowed to do this again.
> Everyone is reading this as intentional anti-competitive practices.
I think its fair to assume anticompetitive intent due to their history of anticompetitive behavior. Admittedly, in old enough to remember the crap they pulled all through the 90s.
> While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?
this strikes me as most likely. it is anti-competitive, but it's probably not their motive.
Won't really help ya. As outlined at https://ghuntley.com/fracture/ as soon as you compile "VSCode" (MIT) the ecosystem fractures in a bad way (tm) including no-license to run majority of MSFT extensions (Language LSPs, Copilot, Remote Development). If you are a vendor producing a MIT fork then one needs to iterate the graph and convince 3rd party extension authors to _not use the MSFT extensions_ as dependencies _and_ to publish on open-vsx.
This is how Cursor gets wrecked in the medium/long term. Coding agent? Cool. You can't use Pylance with it etc. VSCode degrades to being notepad.exe. MSFT uses Cursor for product research and then rolls out the learnings into Copilot because only Copilot supports all of "Visual Studio Code" features that users expect (and this is by design)
Further enshittifying Windows and Office. I'd say this task must have run its course by now, but Microsoft always seems to find a way to make products worse.
Thank you. This needs to be said & should be reported.
If we want a world that isn’t massively hostile to devs, like it is for most companies, this is the kind of advocacy we need and I’d love to see more people in tech putting it out there.
While I can understand the part about hidden APIs, as they're in flux and experimental, the part that's weird about it to me is the "you can totally build it and share it just not on our marketplace" part. That just sounds to me like they're trying to bar their competitors from the VSCode Marketplace, making installing and updating a lot harder for users.
Also regarding the wording "Proposed API": This seems like it's just some kind of incubator for APIs before marking them as stable. So that copilot thing may just be their incubator project. It may be not though.
Not malicious, but still selfish. It's important to remember that the copilot extensions are an extremely effective way of monetizing VScode. So it seems more like they're kind of compromising on their API usage rules in order to get to market quicker. But allowing themselves to use the APIs before anyone else is in a way anti-competitive, because the only way one could compete would be to use the unfinished APIs. But that requires users to go through more hoops to install your extension.
I should also mention that I am a VScode extension developer and I'm one of the weirdos that actually takes the time to read about API updates. They are putting in a lot of effort in developing language model APIs. So it's not like they're outright blocking others from their marketplace.
>Seems a bit like a "don't attribute to malice..."
I'm not saying you are wrong or that the rest of your comment isn't pretty valid, but a lot of people attribute malice to microsoft out the gate because they have history of operating out of malice.
I would think this is less team velocity and more about LSP/etc. I am not an expert on how this is developed, but I imagine it will take at least a couple of years for the dust to settle to decide on good public API abstractions for LLM codegen, and they don’t want to introduce anything public that they have to maintain in concert with 3rd parties.
That’s not to say the general concern about GitHub-VSCode smothering competition isn’t valid, but I agree that it’s probably not what’s happening here.
Frankly if they shipped it with `enabledApiProposals` I'd even go further and assume that they actually _intend_ to release public APIs once they've baked.
Like, why go through the extra work of gating it under `enabledApiProposals` and using the public manifest flag when you could put code in VSCode itself that is like "oh if this extension is installed let me just run some secret code here in the binary".
Disclaimer: I used to work at Microsoft. These days I work at a competitor. All words my own and represent neither entity.
Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files). This was drilled into the heads of everyone, including what I assume are 90% of VP+ people currently at the company, for a very long time.
For them to do this is a conscious decision to be anticompetitive.
What a coincidence, I was just browsing Microsoft's Go fork (for FIPS compatibility, basically replacing Go crypto with OpenSSL and whatever API Windows has, just like there's a Google's fork that uses BoringSSL), and found this patch:
Upstream Go tricks Windows into enabling long path support by setting an
undocumented flag in the PEB. The Microsoft Go fork can't use undocumented
APIs, so this commit removes the hack.
So, even if they fork something, they have to strictly follow this guideline and remove undocumented API usage. I wonder if this only applies to Windows APIs though.
> Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files).
I thought that only applied to private Windows APIs?
The antitrust case was about the Windows monopoly specifically, so other MS products calling Windows private APIs was in its scope. But, this is more comparable to another MS product calling a private Visual Studio API – I don't believe that was in the scope of that antitrust case. Did Microsoft have policies and processes against that scenario too?
The settlement was (presumably, I've never read it) about not using a monopoly in one area to gain influence in another, so I would not be surprised if Windows was the primary focus, but the overall message was fairly universal, and it makes sense: Microsoft builds platforms and overwhelmingly those platforms rely on other parties, so don't leverage anything internal/unfair as that hurts the platform.
This means that Office shouldn't use private Windows APIs and pin itself to the taskbar. It means that Surface shouldn't have special integrations (whether with Windows, Copilot, or whatever) that aren't available to third parties. It means that Azure shouldn't build things that are only available to Office. You build for the platform. The push was originally around a legal mandate, but it turns into a culture.
> The push was originally around a legal mandate, but it turns into a culture.
Whatever the scope of the legal mandate was, it expired over a decade ago now.
Culture can change over time. Even if Microsoft had this culture strongly when you worked there, it might have become much weaker in the years since. Within a corporation, culture can also vary a lot between different teams/divisions/etc - maybe it is still strong in some parts of the company but gone in others.
In 2011 [Erich Gamma] joined the Microsoft Visual Studio team and leads a development lab in Zürich, Switzerland that has developed the "Monaco" suite of components for browser-based development, found in products such as Azure DevOps Services [0]
Very interestingly, just yesterday I discovered that VSCode has a set of APIs for adding SSH tunneling, and under normal circumstances you must launch vscode with special flags to be able to use them. Somehow their built-in JavaScript debugging extension can use these APIs without any issues.
And you can hardly find any public information about these APIs. Well, unless someone asks -- As of 2 years ago, they didn't have any plans to "finalize" these APIs, i.e. make them public. You are advised to find other workarounds (which do work).
Yeah I love the paternalistic “it’s for your own safety” arguments.
> Why did my payment not go through?
> Why was my comment removed?
> Why is my binary flagged as malware?
> Why did my app fail review?
> Why is my 10yo account suspended?
The answer of yesteryear was “we’d love to tell you but then we’d help the bad guys”. The answer today is “we don’t even know because we replaced the human moderators with a black box AI”.
I really don't get why people are mad about this. I get it, people don't like MS but theres really no surprises here, nor is it really all that bad. They put time, effort and money into developing VSCode. Its open source so if you want to use these API's you can in a forked version. And of course if you're developing something thats free for everyone to use, and its not forcing you to use it, I don't see an issue with using private API's.
And while some make the alegory to IE its not the same since its not pre-installed on every machine, nor are they forcing you to use it. So while yes they have a lot of market share, they have nothing stopping you from forking it yourself or just using a different editor.
It's unfortunate because there _is_ an existing large ecosystem around the official Visual Studio Code product. (The extension "store" cannot be used with forks.)
The VS Code team has kept some APIs in this "preview" mode for many many years. https://github.com/microsoft/vscode/issues/59921 is just one example, which has been requested since early 2018!
Because people are concerned that the embrace, extend, extinguish of Microsoft will rear its ugly head and we’ll all have been bamboozled again to use closed source software.
I've not been unable to understand why people trust a corporation with 20 years of demonstrable embrace, extend, extinguish and other tactics, and with not even a word of repentance or even contrition, to not do this again. I think we should be assuming it's in the corporate culture to do this again unless they at the very least publicly say they intend to do otherwise. (Of course, talk is cheap, but if you want to rebuild trust, it's the first step.)
Although I pretty much disagree with their entire design value system even on the technical and UI levels (especially the latter), and can't see why anyone puts up with Windows. But clearly many people do, so obviously I'm missing something.
People have been bamboozled, but maybe not the way you're implying.
Microsoft is only doing open source since it proved to be an extremely useful way of doing things, not because they turned into an altruistic company that started caring more about making the world a better place rather than making money.
It's felt for a long time to me that MS has been slowly boiling the frog with VSCode - injecting little bits of proprietary/non open source functionality at a time. I want to switch to something else but the community at large for the languages I develop in is pretty centered on VS code (Rust and Typescript mostly), and it's a really good editor. Obviously not helped by Typescript being stewarded by MS too.
> the community at large for the languages I develop in is pretty centered on VS code (Rust
Oh, huh, really? I didn't know that. I've always done Rust in neovim with coc.nvim and rust-analyzer (well, ever since the latter existed, anyway), and that's been more than sufficient.
JetBrains has a Rust IDE now, though it's not free. What else is out there...?
Zed, neovim ... both excellent. Sublime Text is still good, but they need to keep up. Haven't tried Lapce, Helix etc. If it has LSP + tree sitter, that's a really good start.
I pay for Golang, it took me some time to acknowledge that an IDE is slower than a lightweight code editor such as VSCode, but it feels great to use a tool entirely crafted for a language.
After doing some VS Code extension development, I don't really understand what this could enable that isn't already possible. You can run arbitrary code on the client side from a VS Code extension, you can run a full web application inside the VS Code UI, you can read and change developers' files in any way you want.
What is Cursor doing that they couldn't do as an extension?
have you tried their cmd+k and Composer experiences? those are new ui paradigms not implementable in extension. native integration that "feels" third party is not going to stand out.
What is this Cmd+K / Composer experience? For me Cmd+K is the first hotkey in the multi-key bindings that I believe ship by default. Searching for Composer just suggests the PHP Composer extension that I assume isn't what you mean.
I don't necessarily see anything particularly malicious to be honest.
Before you introduce public APIs you need a use case and someone to spearhead them and copilot is doing that.
As for Microsoft not allowing installs of stuff like live share on other forks I guess it is because they are seen as different products and not part of the vsc codebase itself.
I would understand if extension authors would complain about not being able to access the same apis (might be the case) but at the end of the day they can still fork and do whatever they prefer.
Lots of companies out there thrive on forking vsc, from gitpod, stackblitz, cursor and many others. But they can't possibly expect to have all proprietary plugins too.
What other code editor has ever been so impactful and open in the last decades?
I don’t see any problem here. They spend money, effort, time to develop their products. Why do they need to give that products for free to everyone, or even their competitors?
Others can choose to use or not use vscode. If they concern about the telemetry, build themselves or use other code editor then.
> Why do they need to give that products for free to everyone, or even their competitors?
It is "free". Anyone can make an extension using the API features. However they do not allow anyone other than themselves to bring it to market (i.e. the official extension marketplace).
This is the real answer to this. They know they can coordinate with the Copilot team to change or remove API usage much quicker than third party extensions.
I bet they'd love if there were a way to have trusted testers that they could _force_ to make timely updates like they likely can with Copilot.
Maybe they should look into Chrome's Origin Trial system and make time-limited API tokens so that extension developers know that features relying on experimental APIs will break, even if the API itself doesn't. That seems to keep causal usage at bay and make sure that trial developers stay on top of things.
This, there are APIs in Windows today, that were added temporarily in one of the early betas of Windows 95 as a stopgap measure. By the time MS got around to replacing them with proper versions, they found that big applications were already using them.
Huh, I assumed that MS Live Share and GH Copilot extensions were already using some secret APIs in the past, since I never saw any open source extension being able to do what they do. I guess I was wrong before, and this only starts being the case now?
Exactly. I'm not sure why I clicked on this article given that [Giant Corp] introducing hidden [Anything] into [Free Product] isn't exactly a surprise is it?
To everyone talking about EEE, what can they extinguish here, code editors?
If they get too annoying, like really forcing copilot or something like that, there are several other editors to choose from. Until this day comes I'm having a positive experience with VSC.
Ladies and gentlemen, I present to you the miracle called Lazyvim (terminal based IDE). Once you go lazy, you don’t come back. I can’t stand vs code now. The mouse even works in Lazyvim.
There are comments questioning whether this is a malicious practice or not, I remind you that we are talking about Microsoft, they have always taken the ‘Embrace, extend, and extinguish’ approach.
"Hidden APIs" is clickbait; VS Code is open source. Unless they're saying the published VS Code binaries are somehow altered to offer the APIs that are not otherwise available in the open source repository (which is not the case).
VSCode is not open source. Code-OSS is open source and is what is published at https://github.com/microsoft/vscode. VSCode is a proprietary application you download from Microsoft that is a distribution of Code-OSS with Microsoft branding and presumably some proprietary changes.
VS Code + GitHub + OpenAI exclusivity deals + Copilot = The best tools available for close to free.
To use the latest features they will only be found on MS branded tools like the ones above.
With the competition getting eliminated with total MS coverage of the developer ecosystem with almost everyone sitting on GitHub using VSCode and OpenAI.
Monopoly with close to no competition all without any regulatory scrutiny has been achieved internally. With the extending being the extinguish.
I honestly don't see the issue here (Full disclosure: I work for Microsoft, but in professional services, not in product - and nevertheless fully expect to be downvoted to oblivion).
If these aren't finished, that most likely means that they still haven't stabilized enough to go through the full support and release pipeline--that usually means documenting them, publishing a couple of reference development samples, doing a public announcement, i.e., the full nine yards of fostering adoption of the product feature.
Which you typically will only do once the "preview" is stable and flexible enough to pass muster.
This doesn't affect the fact that it's anticompetitive at all. MS wouldn't use this argument if that made their extension worse, it only works one way.
Yep, downvoted to oblivion alright. Took all of five minutes, and doesn't reflect at all well on radical HN folk's ability to empathize with people working hard to ship actual product.
You working hard doesn't change the facts. Velocity doesn't excuse anti-competitive behavior. I would've thought the DoJ case against Microsoft would've taught you that you can't just do whatever you want because it's convenient for you, especially when it has an effect on your competitors.
This isn't about feelings. This is about a multi-billion dollar corporation doing whatever it wants, yet again, to the detriment of other players in the market. Empathy doesn't have a place here.
It really is tiring to see people who earn hundreds of thousands a year crying about a lack of empathy. What a joke.
Why are you making this personal? Do you know me? Do you know where I live, or how much I really earn?
(Spoilers: One of the ass-ends of Europe, not that much - _certainly_ not anywhere near what my US counterparts earn, even "adjusted" to local terms)
Or do you hate Microsoft so much that you think that frees you from, you know, having basic human decency?
I suppose you've found this to be great excuse to go on a crusade and avoid having a civil discussion with another person (and, to be honest, insulting them in the process). Bravo.
I started with emacs back in the VT220 days (we didn't have tmux/screen in VAXen, nor in Ultrix, and the mail reader was great), moved to vim in the Slackware years, and now switch between VS Code and nvim on my Mac without any qualms. Sometimes I even run nvim inside the VS Code terminal for quick edits.
I am this close to running VSCode inside a VM. The plugins have seemingly no sandboxing. Microsoft has repeatedly demonstrated they view my analytics as their right. Why should I trust this to access my home?
There are just certain technologies my brain says "fuck, no" to. GNOME. The Great Banality Laser (whose official name was once Twitter). Visual Studio Code.
The fullness of time usually proves my brain's initial impressions right, as it seems to be doing now with Visual Studio Code.
I can still remember the monthly paroxysm of bliss that radiated throughout Hackernews, regular as clockwork, timed with Microsoft's monthly VS Code drops. Glad to see it enter its trough of disillusionment, at least on Hackernews.
There was that bit a few years back where the HN folk saw Satya as the second coming of Microsoft and anything even slightly critical or suspicious of Microsoft was downvoted to oblivion as highly implausible. I think people are still coming down from that high.
He's not the messiah, he's a naughty businessman!
(Note: I shot my HN account then because the majority of the MS stuff on here was utterly intolerable for many of us who have been MS devs/users since day zero and have the mental scarring)
Edit: remind me to post this when MS staff are still asleep next time...
I mean, Microsoft has been very clear about their business model of VSCode -- similar to Chromium, the base product is free and you can do whatever you want (and indeed there are lots of products reusing the core of VSCode), but extension marketplace/remote/GitHub Copilot are proprietary. It sounds like a fair deal to me -- Microsoft can't just do open source without expecting to get something in return.
Now, coming back to private APIs, it's hard to know whether this is because Microsoft intentionally wants to keep competition out, or it is just hard to standardize/finalize APIs. I do know that VSCode development team takes extreme care when it comes to their APIs -- new features can take years before they are ready (most recenly coverage APIs, for example), and they don't want to release something when it's not ready, and I respect that. And to be fair, they have a number of "inline completion" APIs standardized as both VSCode APIs and LSP protocol (upcoming). I'm sure there is a lot to be desired, but it should be a nuanced discussion instead of simply "Microsoft bad".
(I am a VSCode extension & LSP author, not affiliated with Microsoft at all)
What's the harm here if the APIs are temporary and they don't have a history of elongating the lives of temporary APIs like this? They've stated the purpose of these "proposed APIs" and we have no evidence from the last decade to believe they'd renege on their stated goals.
The harm is that third-party developers aren't allowed to publish extensions that use "proposed APIs", but Copilot doesn't have to follow these rules because Microsoft both develops the extension and runs the Extension Marketplace website. Microsoft is therefore able to add functionality to their extension that third-party developers can only add by forking VS Code. VS Code forks lose access to the Extension Marketplace, and many Microsoft-published extensions (such as Pylance and LiveShare) will only run on official Microsoft builds of VS Code, not forks.
Microsoft seems to have most fooled with vscode.. The only other IDE’s worth touching imo are Jetbrains and they have most likely been hit by the fact vscode costs $0 and is “good enough”.
Microsoft has already made it difficulty to compete with their “free” by giving away enough and locking down parts that would allow competition to easily fork it (Python LSP, Extensions marketplace).
Vim and Emacs seem to be thriving but I wouldn’t call them drop in replacements.
Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity? It takes a lot more time/energy to push public APIs and it's probably a very different team than the team developing the copilot extension. Seems a bit like a "don't attribute to malice..." kind of moment to me
> Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?
Wouldn't another way of saying that be "the Copilot development team is leveraging their Microsoft ownership to create products in a way not available to the general marketplace?"
The goal might not be to squash competition, but blessing one client with special treatment not available to others can still be anti-competitive.
Whether that would fall afoul of any regulation is beyond my expertise. Naively, most companies have internal APIs that are not generally available. But then most companies don't have paid public marketplaces on their platform.
Is it even not available to competitors? Visual studio is open source. Didn't cusor fork it and is building it features directly into the fork? Not doing something like this would make Copilot at a disadvantage.
> Visual studio is open source
Sort of. The core is, and the installable binaries with telemetry and properietary extensions are not.
The open source, telemetry-free version of VSCode is called VSCodium: https://vscodium.com/
> Didn't cusor fork it and is building it features directly into the fork?
Yes, in their recent interview with Lex Fridman they argued that life as an extension is too limiting.
The main reason we criticise Microsoft for doing this and not them is just their size and market dominance.
Why jump through hoops to make competitors better able to hotwire their own AI into VSCode, or hotwire Copilot into their own IDE, when it's easier to iterate fast and remain unpredictable?
> Why jump through hoops to make competitors better able
Because that is the competitive philosophy that allowed VS Code win in this space. It fits with that great quote from Bill Gates: "A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it."
By having VS Code give a priority to another MS/GitHub product that they aren't willing to give competitors, they're diminishing VS Code's value as a platform, and encouraging competitors to build their own IDEs rather than building on top of it.
That just tells you where in the EEE lifecycle you are.
https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...Embracing, extending, and extinguishing their own tool?
Please consider what you are going to say before you say it.
No, an ecosystem and culture of open source software development tooling.
> The open source, telemetry-free version of VSCode is called VSCodium
The open source, telemetry-free version of VSCode is called VSCode. The VSCodium people simply build it for you and package it for you.
You're mistaken, Visual Studio Code is open source not Visual Studio, they're different
But Cursor had to fork, so as a developer wanting to use them, you need to give up VS Code and install a new code editor, and you can’t just install a plugin. Very few can maintain a fork and get enough people to use their fork. Also what happens if you have two products that needed a fork? You can’t use them both.
I don’t know if it’s legal or not, IANAL, but it feels definitely anti competitive.
> Visual studio is open source.
No it’s not. Visual Studio is a proprietary product and the latest version is Visual Studio 2022.
Visual Studio Code is open source, and it is about as close to Visual Studio as Lightning is to Lightning Bug.
I agree. Apple has been doing this for years as well.
Seems like the only sensible comment in this thread so far.
Here's what I imagine it's like working on the Copilot team:
That is exactly the sort of management that has landed many a company in hot mater before, including Microsoft.
Whether the managers remain ignorant by malice of incompetence is irrelevant. Directing your subordinate to do something that they should reasonably know would break the law or be anticompetitive is still illegal.
The see no evil defense is a piss poor defense that is more likely going to be used to show you knew exactly what was going on.
Sounds like when Slack started taking marketshare from Skype for Business and they pushed out Teams as fast as possible.
This doesn't fly when you're a company the size of Microsoft with the kind of influence and power they have. You can't just ignore the possibility or effects of engaging in anti-competitive behavior simply because it's convenient for you. That's not how it works.
It's not sensible at all.
Why not? They're survived for decades just shrugging off the law and paying off whatever minor fine there is years later. They started that model, now embraced by everyone from Google to Apple to Uber. Build it fast, get rich, worry about legality later.
Government: "We fine you two zillion dollars. You should have listened to the dev."
Microsoft: we’ve just committed to an investment of two zillion dollars in co-pilot! Microsoft to investors: don’t worry, you’ll get two zillion dollars of “value” launching next week , AND we won’t have to pay the bill for years! There’s even a chance our lawyers will win, and we will never have to pay! Microsoft to devs: sorry, we spent two zillion on product so your profit sharing is going to take a bit hit. Thanks for your hard work!
[dead]
The few people I know in the Copilot team(s) (not necessarily VS Code) are laser focused on prioritizing features based on customer demand, not top-down guidance :)
Who decides what customer demands? Is it a free for all environment where people just push whatever they want into the trunk?
>Everyone is reading this as intentional anti-competitive practices.
Even if it is anti-competitive, I don't care. Why should VS Code have to support alternative AI assistants in their software? I understand why people would want that, but I'm not sure why microsoft has some sort of ethical or legal burden to support it. Plus it's open source, competitors can take it for free and add their own co-pilots if they want.
> Plus it's open source, competitors can take it for free and add their own co-pilots if they want.
They can and they do. The process is working.
I think you’ve made a good point here, its not like they force you to have vscode. I feel like it wont be super popular here thoguh
>Why should VS Code have to support alternative AI assistants in their software?
Because of the dominant position of Microsoft in various markets.
[delayed]
Does Microsoft have a monopoly (or large enough market share) on text editors?
It's hard to find a good answer here but there's some strong indication that Microsoft is pretty dominant with code editors.
Are other extensions like Codeium[0] allowed to publish under the same rules? I'm not saying your comment is incorrect, but unless Copilot competitors can get the same treatment, it seems extremely unfair and anti-competitive.
[0]: https://marketplace.visualstudio.com/items?itemName=Codeium....
They're allowed to fork VSCode and integrate their own service. Cursor did that.
VSCode is provided fully free as in beer and freedom. I don't see how this is different from Red Hat Linux integrated with RHEL services. VSCodium is your CentOS.
> VSCode is provided fully free as in beer and freedom
No, VSCode is a proprietary text editor/IDE from Microsoft. Code-OSS is provided fully free as in beer and freedom, and is currently what resides at https://github.com/microsoft/vscode.
Why would Microsoft not want other AI agent extensions to get the same benefits, which would benefit all AI agent users?
Edit: I have removed the portion of the comment which discussed the throwaway account.
Does throwaway account negates the arguments though?
I think there can be an inherent bias to the argument which should be known, and not hidden away. Nevertheless, I removed that portion of the comment.
Either way, no, a fork is not simple because forks cannot access the VSCode Marketplace.
Exactly. That's what Cursor did, and (I think) Microsoft will agree with that and maybe even welcome developers to do this.
Has Microsoft allowed Cursor to access the VSCode Marketplace? As far as I know, it is against the ToS for any editor other than VSCode to access it.
Probably not. Please suggest to extension authors to dual-publish their extensions to OpenVSX and VSMarketplace. So far all authors I engaged with were happy do to so (except for Microsoft of course, who are the only benefactor of this wallet garden situation).
I find that many of the extensions I use do dual publish. I also dual publish my own extension for people because walled gardens are not cool.
I also have an extension that I dual publish. I was surprised to see it’s getting as many downloads on OpenVSX as on the VSCode marketplace. I’m just glad it’s useful to more people for marginally no cost.
I think Cursor just mirrors the VSCode marketplace on their own servers. They used to have an ugly work around for installing extensions, but now it just works and I see links to https://marketplace.cursorapi.com/ inside of Cursor's extension browser.
Any idea how they got the data? I would imagine that just downloading all the data is also against the ToS.
> I would imagine that just downloading all the data is also against the ToS.
It is.
I use both vsc and cursor, cursor imported automatically all my vsc extensions and settings and theme and everything.
Fortunately most ToS are not legally enforceable, but only amount to a public statement of "we are threatening to block your IP if you do this"
There's an entire mechanism to build custom VSCode based applications right there ready to be used. They did more than could be expected.
Eh not quite. Famously, you can fork VSCode, but you can't use the VSCode Extension Marketplace if you do, which loses a lot of the network effect benefits of the VSCode ecosystem. (As far as I know Cursor is flat out violating Microsoft's terms of service with respect to the extension marketplace).
And a lot of the licenses for flagship Microsoft VSCode extensions for languages like C/C++ and Python don't allow using them outside of VSCode/Extension Marketplace so open source forks are crippled by default.
I believe this also blocks you from using Microsoft's proprietary language extensions, and they have been steadily switching the default language packages from OSS to proprietary.
Yes. You famously cannot use the C/C++ language server bundled in the C/C++ extension or Pylance. Who knows what other development tools they will lock behind their fork to the detriment of open source communities. Also you can't use their Remote Extension suite.
Correct
OpenVSX. Again this is just the same as RHEL repos behind license login.
Red Hat provides support for their packages. If you're not paying for support, you don't get access to the repos. That makes sense to me. What does Microsoft gain by creating a walled garden? They don't provide support. All that they provide is hosting. The Eclipse Foundation provides hosting for free for OpenVSX, which is an amazing service to the community of people using VSCode forks that aren't allowed to access the VSCode Marketplace. Microsoft should either relax the ToS on the Marketplace or acknowledge OpenVSX as the one and only marketplace for extensions.
It doesn't matter much whether it's "intentional" or "malicious", though. It's still anticompetitive behavior.
So basically the same way XMLHttpRequest was born[0]?
[0]: https://web.archive.org/web/20060617163047/http://www.alexho...
Hanlon's razor falls apart when it's used outside of personal relationships and in situations where billions of dollars are on the line.
There is no functional difference between a Microsoft that's really excited about Copilot so that it quickly integrates it into their products and a Microsoft that's hellbent on making sure Copilot gets to use secret APIs others can't.
> Everyone is reading this as intentional anti-competitive practices
Who cares about intention? Anti-competitive behavior is anti-competitive behavior.
> It takes a lot more time/energy to push public APIs
And, once an API is public, it becomes a lot harder to make changes to it. Iterating with a private API, then making it public once you've figured out the problem space, is a valid and useful approach.
Iterating on a private API is fine. Allowing your internal AI assistant to publish to the extension store while consuming those private APIs while prohibiting any competitors from doing so is not.
Embrace.
Extend. <-- We are here.
Extinguish.
Microsoft. Microsoft never changes. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
where's the embrace step? vscode is their own product in the first place.
So was IE, back in the day, when they first "embraced" the web.
Today's "embrace" is of the web dev ecosystem, which before VSCode's dominance consisted of Jetbrains, other IDEs, text editors, etc.
Now with VScode and Github, they control much of the dev ecosystem, shrink competitors' marketshares by making them free to end-users (subsidized by other Microsoft businesses), expand them with new capabilities (even before secret APIs), etc.
VSCode is embracing Eclipse team and Eclipse way of opensource IDE ecosystem.
Arguably VS Code was their way of "embracing" what GitHub were doing with Atom.
It is really a shame to me that everyone believes Microsoft has changed and would never behave like they did in the 90s and prior. They haven't changed. They just decided -- for a time -- that another strategy was in their best interests. They're deciding that again, and going back to their EEE playbook.
(It also occurs to me that a lot of people here probably aren't old enough to remember 20th-century Microsoft...)
I don't care if it's malicious or not. The fact remains that this team is using their position inside Microsoft to make use of tools in another product that a competing product wouldn't get to use.
This is one of the things MS got sued for back in the 90s. They shouldn't be allowed to do this again.
I would maybe entertain that idea in a vacuum, but that's Microsoft and they already did that in both Windows and Office before so no.
> Everyone is reading this as intentional anti-competitive practices.
I think its fair to assume anticompetitive intent due to their history of anticompetitive behavior. Admittedly, in old enough to remember the crap they pulled all through the 90s.
> While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?
this strikes me as most likely. it is anti-competitive, but it's probably not their motive.
fork vscode, do whatever you want. merge back when ready.
Won't really help ya. As outlined at https://ghuntley.com/fracture/ as soon as you compile "VSCode" (MIT) the ecosystem fractures in a bad way (tm) including no-license to run majority of MSFT extensions (Language LSPs, Copilot, Remote Development). If you are a vendor producing a MIT fork then one needs to iterate the graph and convince 3rd party extension authors to _not use the MSFT extensions_ as dependencies _and_ to publish on open-vsx.
This is how Cursor gets wrecked in the medium/long term. Coding agent? Cool. You can't use Pylance with it etc. VSCode degrades to being notepad.exe. MSFT uses Cursor for product research and then rolls out the learnings into Copilot because only Copilot supports all of "Visual Studio Code" features that users expect (and this is by design)
If MS didn't owned VS code. What would they be doing?
Building VS Code :)
Further enshittifying Windows and Office. I'd say this task must have run its course by now, but Microsoft always seems to find a way to make products worse.
Thank you. This needs to be said & should be reported.
If we want a world that isn’t massively hostile to devs, like it is for most companies, this is the kind of advocacy we need and I’d love to see more people in tech putting it out there.
While I can understand the part about hidden APIs, as they're in flux and experimental, the part that's weird about it to me is the "you can totally build it and share it just not on our marketplace" part. That just sounds to me like they're trying to bar their competitors from the VSCode Marketplace, making installing and updating a lot harder for users.
Also regarding the wording "Proposed API": This seems like it's just some kind of incubator for APIs before marking them as stable. So that copilot thing may just be their incubator project. It may be not though.
Not malicious, but still selfish. It's important to remember that the copilot extensions are an extremely effective way of monetizing VScode. So it seems more like they're kind of compromising on their API usage rules in order to get to market quicker. But allowing themselves to use the APIs before anyone else is in a way anti-competitive, because the only way one could compete would be to use the unfinished APIs. But that requires users to go through more hoops to install your extension.
I should also mention that I am a VScode extension developer and I'm one of the weirdos that actually takes the time to read about API updates. They are putting in a lot of effort in developing language model APIs. So it's not like they're outright blocking others from their marketplace.
Check my comment elsewhere (it's now bobbing up and down). Some things just take time, no need to assume malicious intent.
Seems like a false dichotomy. Move fast is just a public undocumented unstable API.
>Seems a bit like a "don't attribute to malice..."
I'm not saying you are wrong or that the rest of your comment isn't pretty valid, but a lot of people attribute malice to microsoft out the gate because they have history of operating out of malice.
I would think this is less team velocity and more about LSP/etc. I am not an expert on how this is developed, but I imagine it will take at least a couple of years for the dust to settle to decide on good public API abstractions for LLM codegen, and they don’t want to introduce anything public that they have to maintain in concert with 3rd parties.
That’s not to say the general concern about GitHub-VSCode smothering competition isn’t valid, but I agree that it’s probably not what’s happening here.
Frankly if they shipped it with `enabledApiProposals` I'd even go further and assume that they actually _intend_ to release public APIs once they've baked.
Like, why go through the extra work of gating it under `enabledApiProposals` and using the public manifest flag when you could put code in VSCode itself that is like "oh if this extension is installed let me just run some secret code here in the binary".
Yeah, the fact that they have direct access to VScode is anti-competitive. It doesn't require intent, it's baked in to the org structure.
Could be, but definitely worth flagging at the top of HN for everyone to see!
Disclaimer: I used to work at Microsoft. These days I work at a competitor. All words my own and represent neither entity.
Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files). This was drilled into the heads of everyone, including what I assume are 90% of VP+ people currently at the company, for a very long time.
For them to do this is a conscious decision to be anticompetitive.
What a coincidence, I was just browsing Microsoft's Go fork (for FIPS compatibility, basically replacing Go crypto with OpenSSL and whatever API Windows has, just like there's a Google's fork that uses BoringSSL), and found this patch:
https://github.com/microsoft/go/blob/microsoft/main/patches/...
Upstream Go tricks Windows into enabling long path support by setting an undocumented flag in the PEB. The Microsoft Go fork can't use undocumented APIs, so this commit removes the hack.
So, even if they fork something, they have to strictly follow this guideline and remove undocumented API usage. I wonder if this only applies to Windows APIs though.
> Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files).
I thought that only applied to private Windows APIs?
The antitrust case was about the Windows monopoly specifically, so other MS products calling Windows private APIs was in its scope. But, this is more comparable to another MS product calling a private Visual Studio API – I don't believe that was in the scope of that antitrust case. Did Microsoft have policies and processes against that scenario too?
The settlement was (presumably, I've never read it) about not using a monopoly in one area to gain influence in another, so I would not be surprised if Windows was the primary focus, but the overall message was fairly universal, and it makes sense: Microsoft builds platforms and overwhelmingly those platforms rely on other parties, so don't leverage anything internal/unfair as that hurts the platform.
This means that Office shouldn't use private Windows APIs and pin itself to the taskbar. It means that Surface shouldn't have special integrations (whether with Windows, Copilot, or whatever) that aren't available to third parties. It means that Azure shouldn't build things that are only available to Office. You build for the platform. The push was originally around a legal mandate, but it turns into a culture.
> The push was originally around a legal mandate, but it turns into a culture.
Whatever the scope of the legal mandate was, it expired over a decade ago now.
Culture can change over time. Even if Microsoft had this culture strongly when you worked there, it might have become much weaker in the years since. Within a corporation, culture can also vary a lot between different teams/divisions/etc - maybe it is still strong in some parts of the company but gone in others.
vscode is developed by VPs borged from github, no? those wouldn't know. not that I approve such things, certainly not.
vscode predated github acquisition by several years
> vscode is developed by VPs borged from github
Other way around:
In 2011 [Erich Gamma] joined the Microsoft Visual Studio team and leads a development lab in Zürich, Switzerland that has developed the "Monaco" suite of components for browser-based development, found in products such as Azure DevOps Services [0]
0. https://en.wikipedia.org/wiki/Erich_Gamma
1. https://microsoft.github.io/monaco-editor/
Very interestingly, just yesterday I discovered that VSCode has a set of APIs for adding SSH tunneling, and under normal circumstances you must launch vscode with special flags to be able to use them. Somehow their built-in JavaScript debugging extension can use these APIs without any issues.
https://github.com/microsoft/vscode/blob/main/src/vscode-dts...
And you can hardly find any public information about these APIs. Well, unless someone asks -- As of 2 years ago, they didn't have any plans to "finalize" these APIs, i.e. make them public. You are advised to find other workarounds (which do work).
https://github.com/microsoft/vscode-discussions/discussions/...
This is much less "harmful" than Copilot though, I guess.
They are private, _for a reason_. I can't expand further. It's not less harmful.
I have discovered a truly marvelous reason for them being private, which this margin is too narrow to contain [0].
[0] https://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem#Fermat...
Yeah I love the paternalistic “it’s for your own safety” arguments.
> Why did my payment not go through?
> Why was my comment removed?
> Why is my binary flagged as malware?
> Why did my app fail review?
> Why is my 10yo account suspended?
The answer of yesteryear was “we’d love to tell you but then we’d help the bad guys”. The answer today is “we don’t even know because we replaced the human moderators with a black box AI”.
I see what you did there (Y)
People must not be familiar with you, or your intimate knowledge with this entire situation.
I'd love if you could expound, and/or share any thoughts about Eclipse Theia.
I really don't get why people are mad about this. I get it, people don't like MS but theres really no surprises here, nor is it really all that bad. They put time, effort and money into developing VSCode. Its open source so if you want to use these API's you can in a forked version. And of course if you're developing something thats free for everyone to use, and its not forcing you to use it, I don't see an issue with using private API's.
And while some make the alegory to IE its not the same since its not pre-installed on every machine, nor are they forcing you to use it. So while yes they have a lot of market share, they have nothing stopping you from forking it yourself or just using a different editor.
It's unfortunate because there _is_ an existing large ecosystem around the official Visual Studio Code product. (The extension "store" cannot be used with forks.)
The VS Code team has kept some APIs in this "preview" mode for many many years. https://github.com/microsoft/vscode/issues/59921 is just one example, which has been requested since early 2018!
Because people are concerned that the embrace, extend, extinguish of Microsoft will rear its ugly head and we’ll all have been bamboozled again to use closed source software.
I've not been unable to understand why people trust a corporation with 20 years of demonstrable embrace, extend, extinguish and other tactics, and with not even a word of repentance or even contrition, to not do this again. I think we should be assuming it's in the corporate culture to do this again unless they at the very least publicly say they intend to do otherwise. (Of course, talk is cheap, but if you want to rebuild trust, it's the first step.)
Although I pretty much disagree with their entire design value system even on the technical and UI levels (especially the latter), and can't see why anyone puts up with Windows. But clearly many people do, so obviously I'm missing something.
Trust in what way? Trust is not required to use something. If it provides utility, then that is for many the end of story, no trust involved.
People have been bamboozled, but maybe not the way you're implying.
Microsoft is only doing open source since it proved to be an extremely useful way of doing things, not because they turned into an altruistic company that started caring more about making the world a better place rather than making money.
It's felt for a long time to me that MS has been slowly boiling the frog with VSCode - injecting little bits of proprietary/non open source functionality at a time. I want to switch to something else but the community at large for the languages I develop in is pretty centered on VS code (Rust and Typescript mostly), and it's a really good editor. Obviously not helped by Typescript being stewarded by MS too.
> the community at large for the languages I develop in is pretty centered on VS code (Rust
Oh, huh, really? I didn't know that. I've always done Rust in neovim with coc.nvim and rust-analyzer (well, ever since the latter existed, anyway), and that's been more than sufficient.
JetBrains has a Rust IDE now, though it's not free. What else is out there...?
Zed, neovim ... both excellent. Sublime Text is still good, but they need to keep up. Haven't tried Lapce, Helix etc. If it has LSP + tree sitter, that's a really good start.
VSCodium is VSCode without the Microsoft EULA and extra stuff. Most extensions are available in the app, others through openvsx.org
Webstorm and RustRover by JetBrains.
I pay for Golang, it took me some time to acknowledge that an IDE is slower than a lightweight code editor such as VSCode, but it feels great to use a tool entirely crafted for a language.
After doing some VS Code extension development, I don't really understand what this could enable that isn't already possible. You can run arbitrary code on the client side from a VS Code extension, you can run a full web application inside the VS Code UI, you can read and change developers' files in any way you want.
What is Cursor doing that they couldn't do as an extension?
have you tried their cmd+k and Composer experiences? those are new ui paradigms not implementable in extension. native integration that "feels" third party is not going to stand out.
What is this Cmd+K / Composer experience? For me Cmd+K is the first hotkey in the multi-key bindings that I believe ship by default. Searching for Composer just suggests the PHP Composer extension that I assume isn't what you mean.
search cursor composer
I don't necessarily see anything particularly malicious to be honest.
Before you introduce public APIs you need a use case and someone to spearhead them and copilot is doing that.
As for Microsoft not allowing installs of stuff like live share on other forks I guess it is because they are seen as different products and not part of the vsc codebase itself.
I would understand if extension authors would complain about not being able to access the same apis (might be the case) but at the end of the day they can still fork and do whatever they prefer.
Lots of companies out there thrive on forking vsc, from gitpod, stackblitz, cursor and many others. But they can't possibly expect to have all proprietary plugins too.
What other code editor has ever been so impactful and open in the last decades?
I don’t see any problem here. They spend money, effort, time to develop their products. Why do they need to give that products for free to everyone, or even their competitors?
Others can choose to use or not use vscode. If they concern about the telemetry, build themselves or use other code editor then.
> Why do they need to give that products for free to everyone, or even their competitors?
It is "free". Anyone can make an extension using the API features. However they do not allow anyone other than themselves to bring it to market (i.e. the official extension marketplace).
Seems pretty common that a platforms owner would actually try new apis with their own stuff.
What better way to get primary real world usage before stabilizing?
This is the real answer to this. They know they can coordinate with the Copilot team to change or remove API usage much quicker than third party extensions.
I bet they'd love if there were a way to have trusted testers that they could _force_ to make timely updates like they likely can with Copilot.
Maybe they should look into Chrome's Origin Trial system and make time-limited API tokens so that extension developers know that features relying on experimental APIs will break, even if the API itself doesn't. That seems to keep causal usage at bay and make sure that trial developers stay on top of things.
This, there are APIs in Windows today, that were added temporarily in one of the early betas of Windows 95 as a stopgap measure. By the time MS got around to replacing them with proper versions, they found that big applications were already using them.
I suppose this is somewhat related to previous discussion[1], Microsoft has shown it's true color for multiple times, why even bother trusting them?
[1]: https://news.ycombinator.com/item?id=41691577
Huh, I assumed that MS Live Share and GH Copilot extensions were already using some secret APIs in the past, since I never saw any open source extension being able to do what they do. I guess I was wrong before, and this only starts being the case now?
Microsoft VSCode, as far as I know, is not purely what is published under https://github.com/microsoft/vscode.
Microsoft gives a product for free. It is free to add whatever features it wants in it. No?
(and that's why I use emacs...)
Plenty of companies thrive on the forks, stackblitz, cursor, gitpod and many others.
But you can't expect from Microsoft to also open and share every single tool for vsc itself, you're still free to implement it though.
Exactly. I'm not sure why I clicked on this article given that [Giant Corp] introducing hidden [Anything] into [Free Product] isn't exactly a surprise is it?
But we'll be better off if we pressure them not to do that.
To everyone talking about EEE, what can they extinguish here, code editors?
If they get too annoying, like really forcing copilot or something like that, there are several other editors to choose from. Until this day comes I'm having a positive experience with VSC.
This seems like a good time to mention Zed. Recent discussion: https://news.ycombinator.com/item?id=40928893
From some members of the Atom team, a code editor before VSCode showed up. Electron sprouted from the Atom project.
see https://en.wikipedia.org/wiki/Atom_editor
Ladies and gentlemen, I present to you the miracle called Lazyvim (terminal based IDE). Once you go lazy, you don’t come back. I can’t stand vs code now. The mouse even works in Lazyvim.
Given how Cursor etc built a direct competitor business on top of VSCode, understandable
I am thinking of uninstalling VSCode and using something else because they are too invested in AI.
I'll just leave this riiight here
https://github.com/neovim/neovim/wiki/Installing-Neovim/921f...
+1 for Neovim + lazyvim.
https://www.lazyvim.org
Has VS Code dominated the code editor market? If not, is this a prerequisite for discussing anti-competitive issues?
It definitely is very popular. Domination depends on your viewpoint.
https://survey.stackoverflow.co/2024/technology/#1-integrate...
Not sure why this is a problem.
VS Code doesn't have a lock on market share for IDEs the way say Google does on search.
There are plenty of other options either with or without CoPilot.
The horror!
EEE Embrace Extend Extinguish 2024 version
There are comments questioning whether this is a malicious practice or not, I remind you that we are talking about Microsoft, they have always taken the ‘Embrace, extend, and extinguish’ approach.
"Hidden APIs" is clickbait; VS Code is open source. Unless they're saying the published VS Code binaries are somehow altered to offer the APIs that are not otherwise available in the open source repository (which is not the case).
VSCode is not open source. Code-OSS is open source and is what is published at https://github.com/microsoft/vscode. VSCode is a proprietary application you download from Microsoft that is a distribution of Code-OSS with Microsoft branding and presumably some proprietary changes.
How dare they add undocumented APIs to a product they pay to develop and give away for free.
WordPerfect and Lotus 1-2-3 have entered the chat.
Extend to Extinguish - Round 3. [0][1]
VS Code + GitHub + OpenAI exclusivity deals + Copilot = The best tools available for close to free.
To use the latest features they will only be found on MS branded tools like the ones above.
With the competition getting eliminated with total MS coverage of the developer ecosystem with almost everyone sitting on GitHub using VSCode and OpenAI.
Monopoly with close to no competition all without any regulatory scrutiny has been achieved internally. With the extending being the extinguish.
[0] https://news.ycombinator.com/item?id=38280513
[1] https://news.ycombinator.com/item?id=34612959
I honestly don't see the issue here (Full disclosure: I work for Microsoft, but in professional services, not in product - and nevertheless fully expect to be downvoted to oblivion).
If these aren't finished, that most likely means that they still haven't stabilized enough to go through the full support and release pipeline--that usually means documenting them, publishing a couple of reference development samples, doing a public announcement, i.e., the full nine yards of fostering adoption of the product feature.
Which you typically will only do once the "preview" is stable and flexible enough to pass muster.
I mean, it's not as if there isn't a huge API surface for the editor (the sample extensions repo is huge - https://github.com/microsoft/vscode-extension-samples), and there are already samples out there to extend the Copilot functionality: https://github.com/joyceerhl/vscode-mssql-chat (I wrote my own based off this one for a personal project)
So maybe consider that those things just take time to build out fully before assuming the worst?
This doesn't affect the fact that it's anticompetitive at all. MS wouldn't use this argument if that made their extension worse, it only works one way.
Yep, downvoted to oblivion alright. Took all of five minutes, and doesn't reflect at all well on radical HN folk's ability to empathize with people working hard to ship actual product.
You working hard doesn't change the facts. Velocity doesn't excuse anti-competitive behavior. I would've thought the DoJ case against Microsoft would've taught you that you can't just do whatever you want because it's convenient for you, especially when it has an effect on your competitors.
This isn't about feelings. This is about a multi-billion dollar corporation doing whatever it wants, yet again, to the detriment of other players in the market. Empathy doesn't have a place here.
It really is tiring to see people who earn hundreds of thousands a year crying about a lack of empathy. What a joke.
Why are you making this personal? Do you know me? Do you know where I live, or how much I really earn?
(Spoilers: One of the ass-ends of Europe, not that much - _certainly_ not anywhere near what my US counterparts earn, even "adjusted" to local terms)
Or do you hate Microsoft so much that you think that frees you from, you know, having basic human decency?
I suppose you've found this to be great excuse to go on a crusade and avoid having a civil discussion with another person (and, to be honest, insulting them in the process). Bravo.
Your "HN folk's ability to empathize with people working hard" made it personal...
What dirty, dastardly and deviously, deceptive deceiving and clearly damnable practice of Microsoft yet again.
Embrace, extend, extinguish.
Some people said: "look microsoft changed, it is not the same as before", and "but vscode is open source, what are you complaining"...
Enshittify
[flagged]
I had to block all network traffic from VSCode that shit is spyware out of the box.
Maybe the vi crew is actually onto something.
vi crew here. We had dark mode since before it was fashionable.
vi/emacs crew was never wrong. Imagine willingly using a Microsoft product.
I started with emacs back in the VT220 days (we didn't have tmux/screen in VAXen, nor in Ultrix, and the mail reader was great), moved to vim in the Slackware years, and now switch between VS Code and nvim on my Mac without any qualms. Sometimes I even run nvim inside the VS Code terminal for quick edits.
I am this close to running VSCode inside a VM. The plugins have seemingly no sandboxing. Microsoft has repeatedly demonstrated they view my analytics as their right. Why should I trust this to access my home?
There are just certain technologies my brain says "fuck, no" to. GNOME. The Great Banality Laser (whose official name was once Twitter). Visual Studio Code.
The fullness of time usually proves my brain's initial impressions right, as it seems to be doing now with Visual Studio Code.
I can still remember the monthly paroxysm of bliss that radiated throughout Hackernews, regular as clockwork, timed with Microsoft's monthly VS Code drops. Glad to see it enter its trough of disillusionment, at least on Hackernews.
Sent from my iPhone
I was with you on the first two. VS Code is the best developer experience I had since Delphi and Kate.
I don't care for it being in the news though.
Lloks like Microsoft is going back to it's old ways. I am not surprised tbh.
Going back?
When did they stop?
True!
There was that bit a few years back where the HN folk saw Satya as the second coming of Microsoft and anything even slightly critical or suspicious of Microsoft was downvoted to oblivion as highly implausible. I think people are still coming down from that high.
He's not the messiah, he's a naughty businessman!
(Note: I shot my HN account then because the majority of the MS stuff on here was utterly intolerable for many of us who have been MS devs/users since day zero and have the mental scarring)
Edit: remind me to post this when MS staff are still asleep next time...
People on HN seem to be either very anti-corporatist or love to white knight big tech
There’s no in between.
Hey I'm right in the middle: I use a Mac and use open source software on it, while moaning how shitty both are.
Enlightened enough to know that open source is good, but smart enough to realize that it’s a pain.
I’ve embraced the pain and have been using Linux as my daily driver for like 5 years.
Yeah not happening here. I am Adobe and Apple's bitch.
I mean I'd really like to but the software I use just isn't there.
the inbetweeners who are here aren't motivated to post about being in-between, which is why it reads that way, unfortunately.
The classic internet engagement bias.
It’s possible to be both critical of Microsoft’s past and also pleased at their last decade of efforts in OSS with things like vscode and typescript.
It’s possible to do both of those and still not trust MS.
I don’t believe that vscode will be this free mostly open editor forever. I’m expecting to see vscode pro or something any day.
Typescript can, very cynically, be seen as an on-ramp for vscode, as vscode has pretty much the best typescript suppor.
Luckily that’s why we have OSS licenses, if/when they do that there will be a community fork.
I mean, Microsoft has been very clear about their business model of VSCode -- similar to Chromium, the base product is free and you can do whatever you want (and indeed there are lots of products reusing the core of VSCode), but extension marketplace/remote/GitHub Copilot are proprietary. It sounds like a fair deal to me -- Microsoft can't just do open source without expecting to get something in return.
Now, coming back to private APIs, it's hard to know whether this is because Microsoft intentionally wants to keep competition out, or it is just hard to standardize/finalize APIs. I do know that VSCode development team takes extreme care when it comes to their APIs -- new features can take years before they are ready (most recenly coverage APIs, for example), and they don't want to release something when it's not ready, and I respect that. And to be fair, they have a number of "inline completion" APIs standardized as both VSCode APIs and LSP protocol (upcoming). I'm sure there is a lot to be desired, but it should be a nuanced discussion instead of simply "Microsoft bad".
(I am a VSCode extension & LSP author, not affiliated with Microsoft at all)
This. LSP is a great example of something that also takes a while to flesh out because the problem space spans a lot (syntax, autocomplete, etc.)
It worked out so well for them with the browser… oh wait.
IE had over 50% market share for over 10 years. It was likely a major factor for Windows holding the desktop OS monopoly.
What's the harm here if the APIs are temporary and they don't have a history of elongating the lives of temporary APIs like this? They've stated the purpose of these "proposed APIs" and we have no evidence from the last decade to believe they'd renege on their stated goals.
> What's the harm here if the APIs are temporary
The “if” is carrying a lot of weight.
It gives Microsoft a solid competitive edge and a form of vendor lock-in in their otherwise mostly open product.
We don’t know that they’ll be temporary forever.
> They've stated the purpose of these "proposed APIs"
Just like how they said recall would not be a required feature, but is a dependency of the file explorer in the next version of windows?
Microsoft will say whatever looks good for them, obviously.
> last decade
But we do from the last 11+ years ;)
I’d always err on the side of not trusting giant monopolistic corporations with a history of garnering good will to cash in on it later.
Especially when that company has been very aggressively inserting itself in nearly every JS projects dependency/software delivery pipelines.
I gain nothing by trusting them, but I stand to lose my project’s independence from them.
The harm is that third-party developers aren't allowed to publish extensions that use "proposed APIs", but Copilot doesn't have to follow these rules because Microsoft both develops the extension and runs the Extension Marketplace website. Microsoft is therefore able to add functionality to their extension that third-party developers can only add by forking VS Code. VS Code forks lose access to the Extension Marketplace, and many Microsoft-published extensions (such as Pylance and LiveShare) will only run on official Microsoft builds of VS Code, not forks.
Microsoft seems to have most fooled with vscode.. The only other IDE’s worth touching imo are Jetbrains and they have most likely been hit by the fact vscode costs $0 and is “good enough”.
Microsoft has already made it difficulty to compete with their “free” by giving away enough and locking down parts that would allow competition to easily fork it (Python LSP, Extensions marketplace).
Vim and Emacs seem to be thriving but I wouldn’t call them drop in replacements.