4 ms·

Introducing SourceKit-LSP

61 points by mbroncano 8y ago

sdegutis 8y ago
> SourceKit-LSP is built on top of sourcekitd 23 and clangd 23 for high-fidelity language support, and provides a powerful source code index as well as cross-language support. That's pretty much been Apple's motto for a while: need language support for anything other than compiling the language, like IDEs or documentation generation? Why not add it directly into the compiler? This has pros and cons, but personally I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable.
- geodel 8y ago
  Seems Apple as a company is not totally hijacked by Javascript people. I am happy that Apple took some stand against Java/Flash/Javascript when it interfered with quality of user experience.
  - nerdponx 8y ago
    I think in this case Javascript just happens to be the most portable programming language right now.
    - azinman2 8y ago
      Python and Perl too....
      - nerdponx 8y ago
        Python and Perl don't (yet) run in a browser. Also Javascript is probably somewhat "faster" (than CPython, at least) due to its JIT.
        lizmat 8y ago
        Perl 6 runs on Chrome: https://perl6.github.io/6pad/ https://perl6.github.io/6pad/ Other browsers will follow soon.
- xenadu02 8y ago
  > I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable. That is not at all what Microsoft has done. C# LSP support is driven by their C# Roslyn compiler. Are you confusing this with their VS Code editor? LSP solves a completely different problem: MN (editorslanguages) by providing a glue layer that compilers and editors can plug into. The whole point of these things is to keep a single source of truth; why would you (poorly) reinvent a compiler for Swift when you can just use the actual Swift compiler?
- setr 8y ago
  >Why not add it directly into the compiler? afaict, most, if not everything, that the LSP is expected to put out is information that is already known to the compiler, as its required for compilation and error'ing. The LSP is just a standardized way to extract that information from the compiler, instead of re-implementing the work in the IDE.
- favorited 8y ago
  Those tools aren't added to the compiler, they're standalone pieces of software which use the LLVM toolchain as libraries. And that's an LLVM principle, not Apple's. LLVM and its related tools have always been designed to be used as libraries, not simply executables.
- woolvalley 8y ago
  It's simple code reuse... you know that compilers are made of many modules and have stages right? Why reinvent writing a code -> lexer-> ast parser for your indexer when you already have a well tested and fast one in llvm? Did you know for example, that when you build your app in xcode that it uses that partial build product to also feed the indexer, so you don't have to scan the same code twice? https://www.tutorialspoint.com/compiler_design/compiler_design_phases_of_compiler.htm https://www.tutorialspoint.com/compiler_design/compiler_desi...
peterkelly 8y ago
I've recently started adding support for the Language Server Protocol (LSP) in a language project I'm working on, and it's a godsend. If you're not familiar with it, it's basically an editor- and language-agnostic protocol for implementing typical IDE behaviours like error highlighting, code completion, hover information, find references, etc. It solves the M*N problem in which every language would have to have a separate plugin tailored towards the APIs of every editor; now you just write either to be LSP compliant and it takes care of 90% of integration effort (writing the language server itself of course is still a lot of work). Although it's still necessary to do a little plumbing work to integrate into each editor, this is largely boilerplate that differs little between languages. Most of the functionality resides in a JSON-RPC server implemented in your language of choice. I've found it particularly useful when used in conjunction with the Monaco code editor [1] (the engine that powers Visual Studio Code), along with a supporting plugin for talking to a remote LSP server [2]. These make it possible to build interactive coding environments into a web app which include many of the typical editing features you're used to in IDEs. It's great to see Apple along with other language vendors adopting this as a standard. [1] https://github.com/Microsoft/monaco-editor https://github.com/Microsoft/monaco-editor [2] https://github.com/TypeFox/monaco-languageclient https://github.com/TypeFox/monaco-languageclient
- alexashka 8y ago
  I think it's a positive, but I also question what the point is. What I'd like, is a better IDE, not an IDE that can provide features I've had for 30 years, for 30 different languages, in a consistent manner. I dont' want 30 languages, and 1 basic lowest common denominator ide. I want 2-3 languages, and excellent ides that push the boundaries of the unique features of each language.
  - zapzupnz 8y ago
    It's not like those sorts of IDEs don't exist. Swift and ObjC have Xcode, C# has VS, Java has IntelliJ, etc. > What I'd like [...] not an IDE that can provide features [...] in a consistent manner How is providing consistent support for many languages a bad thing? This I don't understand. People love their tools, for better or worse, so why should being forced to change tools be the only workflow? Your beloved one-IDE-for-a-couple-of-languages already exist and have done for years, so no need to be a Grinch.
sqs 8y ago
Very excited to see this. We will use this project to add Swift support to Sourcegraph soon so you can get hovers, go-to-definition, find-references, etc., when browsing code on GitHub/GitLab/Bitbucket/Phabricator/Sourcegraph/etc. https://github.com/sourcegraph/sourcegraph/issues/979 https://github.com/sourcegraph/sourcegraph/issues/979
KingMob 8y ago
LSP seems like an interesting concept, but it would be nice if it included more support for REPLs. I'm thinking of things like "evaluate highlighted section" or "recompile function under cursor".

61 points by mbroncano 8y ago

> SourceKit-LSP is built on top of sourcekitd 23 and clangd 23 for high-fidelity language support, and provides a powerful source code index as well as cross-language support. That's pretty much been Apple's motto for a while: need language support for anything other than compiling the language, like IDEs or documentation generation? Why not add it directly into the compiler? This has pros and cons, but personally I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable.

geodel 8y ago
Seems Apple as a company is not totally hijacked by Javascript people. I am happy that Apple took some stand against Java/Flash/Javascript when it interfered with quality of user experience.
- nerdponx 8y ago
  I think in this case Javascript just happens to be the most portable programming language right now.
  - azinman2 8y ago
    Python and Perl too....
    - nerdponx 8y ago
      Python and Perl don't (yet) run in a browser. Also Javascript is probably somewhat "faster" (than CPython, at least) due to its JIT.
      - lizmat 8y ago
        Perl 6 runs on Chrome: https://perl6.github.io/6pad/ https://perl6.github.io/6pad/ Other browsers will follow soon.
xenadu02 8y ago
> I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable. That is not at all what Microsoft has done. C# LSP support is driven by their C# Roslyn compiler. Are you confusing this with their VS Code editor? LSP solves a completely different problem: MN (editorslanguages) by providing a glue layer that compilers and editors can plug into. The whole point of these things is to keep a single source of truth; why would you (poorly) reinvent a compiler for Swift when you can just use the actual Swift compiler?
setr 8y ago
>Why not add it directly into the compiler? afaict, most, if not everything, that the LSP is expected to put out is information that is already known to the compiler, as its required for compilation and error'ing. The LSP is just a standardized way to extract that information from the compiler, instead of re-implementing the work in the IDE.
favorited 8y ago
Those tools aren't added to the compiler, they're standalone pieces of software which use the LLVM toolchain as libraries. And that's an LLVM principle, not Apple's. LLVM and its related tools have always been designed to be used as libraries, not simply executables.
woolvalley 8y ago
It's simple code reuse... you know that compilers are made of many modules and have stages right? Why reinvent writing a code -> lexer-> ast parser for your indexer when you already have a well tested and fast one in llvm? Did you know for example, that when you build your app in xcode that it uses that partial build product to also feed the indexer, so you don't have to scan the same code twice? https://www.tutorialspoint.com/compiler_design/compiler_design_phases_of_compiler.htm https://www.tutorialspoint.com/compiler_design/compiler_desi...

peterkelly 8y ago

I've recently started adding support for the Language Server Protocol (LSP) in a language project I'm working on, and it's a godsend. If you're not familiar with it, it's basically an editor- and language-agnostic protocol for implementing typical IDE behaviours like error highlighting, code completion, hover information, find references, etc. It solves the M*N problem in which every language would have to have a separate plugin tailored towards the APIs of every editor; now you just write either to be LSP compliant and it takes care of 90% of integration effort (writing the language server itself of course is still a lot of work). Although it's still necessary to do a little plumbing work to integrate into each editor, this is largely boilerplate that differs little between languages. Most of the functionality resides in a JSON-RPC server implemented in your language of choice. I've found it particularly useful when used in conjunction with the Monaco code editor [1] (the engine that powers Visual Studio Code), along with a supporting plugin for talking to a remote LSP server [2]. These make it possible to build interactive coding environments into a web app which include many of the typical editing features you're used to in IDEs. It's great to see Apple along with other language vendors adopting this as a standard. [1] https://github.com/Microsoft/monaco-editor https://github.com/Microsoft/monaco-editor [2] https://github.com/TypeFox/monaco-languageclient https://github.com/TypeFox/monaco-languageclient

alexashka 8y ago
I think it's a positive, but I also question what the point is. What I'd like, is a better IDE, not an IDE that can provide features I've had for 30 years, for 30 different languages, in a consistent manner. I dont' want 30 languages, and 1 basic lowest common denominator ide. I want 2-3 languages, and excellent ides that push the boundaries of the unique features of each language.
- zapzupnz 8y ago
  It's not like those sorts of IDEs don't exist. Swift and ObjC have Xcode, C# has VS, Java has IntelliJ, etc. > What I'd like [...] not an IDE that can provide features [...] in a consistent manner How is providing consistent support for many languages a bad thing? This I don't understand. People love their tools, for better or worse, so why should being forced to change tools be the only workflow? Your beloved one-IDE-for-a-couple-of-languages already exist and have done for years, so no need to be a Grinch.

sqs 8y ago

Very excited to see this. We will use this project to add Swift support to Sourcegraph soon so you can get hovers, go-to-definition, find-references, etc., when browsing code on GitHub/GitLab/Bitbucket/Phabricator/Sourcegraph/etc. https://github.com/sourcegraph/sourcegraph/issues/979 https://github.com/sourcegraph/sourcegraph/issues/979

KingMob 8y ago

LSP seems like an interesting concept, but it would be nice if it included more support for REPLs. I'm thinking of things like "evaluate highlighted section" or "recompile function under cursor".