3 ms·

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visu

by junon 3y ago

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP was born. It has a lot of problems. It only really works well with VS Code (yes, there are exceptions, but not many, and they aren't paid for by a mega corporation). This is Microsoft's way. They try to sway the developer community through force, not persuasion. [0] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

throwaway50182 3y ago
What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I really don't understand what you think they should've done instead. Do you think that the world where every compiler has its own API is better? You're still free to do so - just develop an extension for VSCode and/or all the other IDEs instead of a single LSP server implementation.
- Xophmeister 3y ago
  To be cynical, I guess we're at the "embrace and extend" part; "extinguish" hasn't happened yet, but it could. Microsoft controls the LSP and VS Code is very popular; thus Microsoft has all the leverage in the LSP space. I'm not sure what "going rogue" would look like, on Microsoft's part, but with all the power, it could do so without adversely affecting itself.
  - eddythompson80 3y ago
    To be more cynical all products from all companies are in the “embrace and extend” phase
- prometheon1 3y ago
  What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes sense, as GitHub Codespaces and vscode.dev now have features that are difficult to get in competitors. Maybe at some point they will try to Extinguish all local development and push everyone to use a cloud version of VSCode? (See e.g. Python integration in Excel) The truth is probably a lot more complex, but we can't rule out anything yet.
  - throwaway50182 3y ago
    By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.
    - prometheon1 3y ago
      Windows and Office are both mentioned as products that are leveraged to do EEE on Wikipedia: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... They are not extinguishing their own products, but using their products to extinguish alternatives. The example I mentioned actually fits the wikipedia definition quite well in my opinion.
    - mjw1007 3y ago
      CSS was to a large extent a Microsoft project (when the time came to introduce stylesheets it was more-or-less Opera and Microsoft against Netscape, and Microsoft had many more users than Opera). Nonetheless Microsoft managed to use CSS to achieve a great deal of user lock-in by refusing to conform to the standard they co-authored.
      - throwaway50182 3y ago
- lozenge 3y ago
  The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. (Unless you put in per-language effort like the olden days). If you create an LSP, it will work best in VS Code. As well, Microsoft is building a wealth of VS Code-only features and LSPs (locking out VSCodium), by the end, they will have taken from open source and not given anything back.
  - samfundev 3y ago
    > The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. This is not true since LSPs can add extensions to the existing API. For example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md https://github.com/rust-lang/rust-analyzer/blob/master/docs/... > If you create an LSP, it will work best in VS Code. Any editor can work just as well as (or even better than) VS Code.
- follower 3y ago
  > They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. This was something that had puzzled me for a while until just today when reading another post on the original linked article's site. It seemed odd that after MS had used Atom/VSCode to essentially "suck all the air out" of the FLOSS/free editor space that they would then "share" something like LSP which seemed to then make it easier for other editors to (at least potentially) offer a similar standard of support for languages that had LSP implementations. (Because from a purely technical POV I do see LSP as a positive development in the editor space.) But what I'd apparently missed was something mentioned in an earlier "Why LSP?"[0] post by the same author: > "[...] Microsoft, who were a vendor of both languages (C# and TypeScript) > and editors (VS Code and Visual Studio), and who were generally losing > in the IDE space to a competitor (JetBrains)." and, so: > "...launched LSP to increase the value of their platform in other domains > for free (moving the whole world to a significantly better IDE equilibrium > as a collateral benefit)." Thus, assuming this is accurate, the actual target in this case was JetBrains and "sharing" LSP was seen as a reasonable "cost" in order to get additional leverage. Given that I haven't generally paid attention to any of the C#/TypeScript/JetBrains worlds that was an angle that I'd missed. The assumption on my part that "sharing" LSP still wasn't likely to be an "altruistic" act on the part of MS was primarily driven by the fact that they hadn't really given up on proprietary/control they'd simply moved the demarcation point to be at the LSP implementation level (e.g. the plugin for Python) & "marketplace" access (e.g. remote plugin) etc (e.g. telemetry). And by defining/retaining control of LSP they've inserted themselves in the path between other editors & LSP implementations which inherently has value (e.g. by being the "reference"/default implementation[1]). Anyway, that was an aspect of the context for LSP that I wasn't aware of before today, so thought it might be of interest to some. (Obviously the majority of today's developers see no issue with the actions of MS in any of this, so, if that's you feel free to agree to disagree & leave the rest of us to tilt at windmills in peace--after all, why would we stop now? :D ) [0] https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is-great https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is... [1] Which is one of the reasons I'd really like rust-analyzer to one day change to target an editor implemented in Rust by default. VS Code doesn't need any more value added to it for free but any Rust-based editor would benefit from being a "First Class" rust-analyzer citizen & thus strengthen the wider Rust ecosystem.
hardware2win 3y ago
Visual Studio was a meme? It is still top IDE matched by maybe just JB
- junon 3y ago
  Because up until (relatively) recently, you couldn't even compile code on Windows without VS.
- alfalfasprout 3y ago
  I was going to say-- visual studio is phenomenal. The profiler is incredible to use.
nobleach 3y ago
You can say a lot about Microsoft the company. You can even take digs at Visual Studio Code and its "telemetry reporting". But LSP is one of the best things that's come out of that whole ordeal. It's far from perfect. But as a Vim user, we've had nothing this good until now. I used TernJS for JavaScript and some other handy plugins for other language specific stuff... and it was such a pain. LSP made things far more uniform. And they gave it away to the community! They didn't force anyone to use it.
- kstrauser 3y ago
  I agree. I primarily use(d) Emacs, and while it’s had good support for certain languages for decades, now it handles younger languages like TypeScript and Rust exactly as well as Microsoft’s editors do. That’s freaking magical.
  - tuukkah 3y ago
    Microsoft does not use LSP for its own language TypeScript. They have something that works better for VSCode: tsserver. When TypeScript evolves, Microsoft updates tsserver and VSCode as needed. To get the updates to Emacs, someone needs to make the respective changes to a third-party TypeScript LSP first. And it won't work as well because LSP isn't as good.
    - kstrauser 3y ago
      Ugh, I didn't realize that.
    - nobleach 3y ago
      typescript-tools for NeoVim uses tsserver

by junon 3y ago

throwaway50182 3y ago

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I really don't understand what you think they should've done instead. Do you think that the world where every compiler has its own API is better? You're still free to do so - just develop an extension for VSCode and/or all the other IDEs instead of a single LSP server implementation.

Xophmeister 3y ago
To be cynical, I guess we're at the "embrace and extend" part; "extinguish" hasn't happened yet, but it could. Microsoft controls the LSP and VS Code is very popular; thus Microsoft has all the leverage in the LSP space. I'm not sure what "going rogue" would look like, on Microsoft's part, but with all the power, it could do so without adversely affecting itself.
- eddythompson80 3y ago
  To be more cynical all products from all companies are in the “embrace and extend” phase
prometheon1 3y ago
What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes sense, as GitHub Codespaces and vscode.dev now have features that are difficult to get in competitors. Maybe at some point they will try to Extinguish all local development and push everyone to use a cloud version of VSCode? (See e.g. Python integration in Excel) The truth is probably a lot more complex, but we can't rule out anything yet.
- throwaway50182 3y ago
  By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.
  - prometheon1 3y ago
    Windows and Office are both mentioned as products that are leveraged to do EEE on Wikipedia: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... They are not extinguishing their own products, but using their products to extinguish alternatives. The example I mentioned actually fits the wikipedia definition quite well in my opinion.
  - mjw1007 3y ago
    CSS was to a large extent a Microsoft project (when the time came to introduce stylesheets it was more-or-less Opera and Microsoft against Netscape, and Microsoft had many more users than Opera). Nonetheless Microsoft managed to use CSS to achieve a great deal of user lock-in by refusing to conform to the standard they co-authored.
    - throwaway50182 3y ago
lozenge 3y ago
The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. (Unless you put in per-language effort like the olden days). If you create an LSP, it will work best in VS Code. As well, Microsoft is building a wealth of VS Code-only features and LSPs (locking out VSCodium), by the end, they will have taken from open source and not given anything back.
- samfundev 3y ago
  > The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. This is not true since LSPs can add extensions to the existing API. For example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md https://github.com/rust-lang/rust-analyzer/blob/master/docs/... > If you create an LSP, it will work best in VS Code. Any editor can work just as well as (or even better than) VS Code.
follower 3y ago
> They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. This was something that had puzzled me for a while until just today when reading another post on the original linked article's site. It seemed odd that after MS had used Atom/VSCode to essentially "suck all the air out" of the FLOSS/free editor space that they would then "share" something like LSP which seemed to then make it easier for other editors to (at least potentially) offer a similar standard of support for languages that had LSP implementations. (Because from a purely technical POV I do see LSP as a positive development in the editor space.) But what I'd apparently missed was something mentioned in an earlier "Why LSP?"[0] post by the same author: > "[...] Microsoft, who were a vendor of both languages (C# and TypeScript) > and editors (VS Code and Visual Studio), and who were generally losing > in the IDE space to a competitor (JetBrains)." and, so: > "...launched LSP to increase the value of their platform in other domains > for free (moving the whole world to a significantly better IDE equilibrium > as a collateral benefit)." Thus, assuming this is accurate, the actual target in this case was JetBrains and "sharing" LSP was seen as a reasonable "cost" in order to get additional leverage. Given that I haven't generally paid attention to any of the C#/TypeScript/JetBrains worlds that was an angle that I'd missed. The assumption on my part that "sharing" LSP still wasn't likely to be an "altruistic" act on the part of MS was primarily driven by the fact that they hadn't really given up on proprietary/control they'd simply moved the demarcation point to be at the LSP implementation level (e.g. the plugin for Python) & "marketplace" access (e.g. remote plugin) etc (e.g. telemetry). And by defining/retaining control of LSP they've inserted themselves in the path between other editors & LSP implementations which inherently has value (e.g. by being the "reference"/default implementation[1]). Anyway, that was an aspect of the context for LSP that I wasn't aware of before today, so thought it might be of interest to some. (Obviously the majority of today's developers see no issue with the actions of MS in any of this, so, if that's you feel free to agree to disagree & leave the rest of us to tilt at windmills in peace--after all, why would we stop now? :D ) [0] https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is-great https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is... [1] Which is one of the reasons I'd really like rust-analyzer to one day change to target an editor implemented in Rust by default. VS Code doesn't need any more value added to it for free but any Rust-based editor would benefit from being a "First Class" rust-analyzer citizen & thus strengthen the wider Rust ecosystem.

hardware2win 3y ago

Visual Studio was a meme? It is still top IDE matched by maybe just JB

junon 3y ago
Because up until (relatively) recently, you couldn't even compile code on Windows without VS.
alfalfasprout 3y ago
I was going to say-- visual studio is phenomenal. The profiler is incredible to use.

nobleach 3y ago

You can say a lot about Microsoft the company. You can even take digs at Visual Studio Code and its "telemetry reporting". But LSP is one of the best things that's come out of that whole ordeal. It's far from perfect. But as a Vim user, we've had nothing this good until now. I used TernJS for JavaScript and some other handy plugins for other language specific stuff... and it was such a pain. LSP made things far more uniform. And they gave it away to the community! They didn't force anyone to use it.

kstrauser 3y ago
I agree. I primarily use(d) Emacs, and while it’s had good support for certain languages for decades, now it handles younger languages like TypeScript and Rust exactly as well as Microsoft’s editors do. That’s freaking magical.
- tuukkah 3y ago
  Microsoft does not use LSP for its own language TypeScript. They have something that works better for VSCode: tsserver. When TypeScript evolves, Microsoft updates tsserver and VSCode as needed. To get the updates to Emacs, someone needs to make the respective changes to a third-party TypeScript LSP first. And it won't work as well because LSP isn't as good.
  - kstrauser 3y ago
    Ugh, I didn't realize that.
  - nobleach 3y ago
    typescript-tools for NeoVim uses tsserver