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.
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."
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.
>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.
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.
>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.
> 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.
> 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 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.
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.
> 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.
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.
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".
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.
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.
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.
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).
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.
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.
> 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...?
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.
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.
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 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).
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?
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?
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.
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.
"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.
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.
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.
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.
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.
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.
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.
frenchie4111|1 year ago
peeters|1 year ago
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.
gavinray|1 year ago
Here's what I imagine it's like working on the Copilot team:
tristan957|1 year ago
[0]: https://marketplace.visualstudio.com/items?itemName=Codeium....
ctoth|1 year ago
[0]: https://web.archive.org/web/20060617163047/http://www.alexho...
Suppafly|1 year ago
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.
creata|1 year ago
heavyset_go|1 year ago
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.
throwaway19972|1 year ago
Who cares about intention? Anti-competitive behavior is anti-competitive behavior.
solardev|1 year ago
Extend. <-- We are here.
Extinguish.
Microsoft. Microsoft never changes. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Forgeties79|1 year ago
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.
duskwuff|1 year ago
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.
nosioptar|1 year ago
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.
Deukhoofd|1 year ago
kelnos|1 year ago
This is one of the things MS got sued for back in the 90s. They shouldn't be allowed to do this again.
nolok|1 year ago
kburman|1 year ago
RandomThoughts3|1 year ago
> moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity
It’s not an either/or. That’s the same thing. The second part is the anticompetitive practice.
Giving advantage to your own teams so they can be there first and uncontested is approximately as anticompetitive as it can get.
chrsig|1 year ago
this strikes me as most likely. it is anti-competitive, but it's probably not their motive.
nikeee|1 year ago
Lramseyer|1 year ago
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.
cbhl|1 year ago
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".
npteljes|1 year ago
aithrowawaycomm|1 year ago
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.
Log_out_|1 year ago
throwaway48476|1 year ago
sirspacey|1 year ago
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.
waveBidder|1 year ago
timcobb|1 year ago
Arainach|1 year ago
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.
rty32|1 year ago
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.
ghuntley|1 year ago
[deleted]
p1necone|1 year ago
mr90210|1 year ago
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.
kelnos|1 year ago
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...?
replete|1 year ago
cobertos|1 year ago
Jcampuzano2|1 year ago
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.
__float|1 year ago
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!
wincy|1 year ago
lacker|1 year ago
What is Cursor doing that they couldn't do as an extension?
swyx|1 year ago
Eikon|1 year ago
What better way to get primary real world usage before stabilizing?
spankalee|1 year ago
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.
torginus|1 year ago
quyleanh|1 year ago
Others can choose to use or not use vscode. If they concern about the telemetry, build themselves or use other code editor then.
unknown|1 year ago
[deleted]
vanchor3|1 year ago
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).
epolanski|1 year ago
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?
pzmarzly|1 year ago
tristan957|1 year ago
wiz21c|1 year ago
(and that's why I use emacs...)
epolanski|1 year ago
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.
zb3|1 year ago
troyvit|1 year ago
rvz|1 year ago
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
afandian|1 year ago
canucker2016|1 year ago
see https://en.wikipedia.org/wiki/Atom_editor
_imnothere|1 year ago
[1]: https://news.ycombinator.com/item?id=41691577
htk|1 year ago
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.
gigel82|1 year ago
tristan957|1 year ago
nextworddev|1 year ago
unknown|1 year ago
[deleted]
unknown|1 year ago
[deleted]
sporedro|1 year ago
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.
veblen|1 year ago
zokier|1 year ago
https://survey.stackoverflow.co/2024/technology/#1-integrate...
unknown|1 year ago
[deleted]
beretguy|1 year ago
vouaobrasil|1 year ago
naught0|1 year ago
https://github.com/neovim/neovim/wiki/Installing-Neovim/921f...
favflam|1 year ago
grigio|1 year ago
insane_dreamer|1 year ago
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.
datavirtue|1 year ago
rcarmo|1 year ago
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?
zb3|1 year ago
rcarmo|1 year ago
ekvintroj|1 year ago
dmart|1 year ago
neilv|1 year ago
dagaci|1 year ago
oigursh|1 year ago
greatgib|1 year ago
unknown|1 year ago
[deleted]
dsnr|1 year ago
sbussard|1 year ago
[deleted]
de6u99er|1 year ago
dartos|1 year ago
When did they stop?
rty32|1 year ago
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)
jimbob45|1 year ago
rapind|1 year ago
sub7|1 year ago
Maybe the vi crew is actually onto something.
hggigg|1 year ago
isatty|1 year ago
0cf8612b2e1e|1 year ago
bitwize|1 year ago
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.
scotty79|1 year ago
I don't care for it being in the news though.
postalrat|1 year ago
nilsherzig|1 year ago