12 ms·

Language Server Protocol implementation for Swift and C-based languages

232 points by Kryptoshi 8y ago

sgt 8y ago
I love the momentum around Swift these days, and the LSP looks very interesting.
- robertAngst 8y ago
  What momentum? From the Apple team? Sales and stock price are plummeting at Apple. And from another HN thread, developers are finding people/businesses are going back to web instead of App. Out of all the languages, Swift and Obj C are my 'how much longer until they go away?' languages. Is there anything showing growth? EDIT: Obligatory, Apple users can't handle talking about Apple.
  - kkarakk 8y ago
    the server side swift panel at apple's conf was supposedly so full there were people standing. people are definitely interested.
  - lupinglade 8y ago
    Have you used Swift? It’s not going away, it’s only going to grow.
    - miguelrochefort 8y ago
      Huh? What makes you think that?
    - lmm 8y ago
      Blind assertion is not an argument. What makes Swift a worthwhile/interesting/valuable language outside of the iOS ecosystem? As far as I can see it's yet another language with basically the ML featureset and nothing else; there are certainly worse starting points, but what reasons are there to adopt Swift that don't apply to OCaml or F#, both of which are more established (to say nothing of Rust/Haskell/Scala that actually offer substantive features that other ML-family languages don't have).
      - the_duke 8y ago
        Swift is kind of like Rust with garbage collection and more convenience baked in. It's a pretty nice language with a lot of adoption due to it being nicer and much more modern than ObjectiveC. It's not going anywhere. There are also companies like IBM pushing for Swift on the server. Personally the bad Linux support makes it uninteresting for me right now.
        lmm 8y ago
        > Swift is kind of like Rust with garbage collection and more convenience baked in. Sure - but again, OCaml or F# have been there for decades.
        rcruzeiro 8y ago
        But to be fair neither OCaml nor F# picked up any significant traction (at least not compared to Swift).
        zozbot123 8y ago
        AIUI, Swift uses reference counting, not fully-general GC. So, it's really not different from Rust from that POV, other than the fact that Rust can avoid the overhead of atomic refcount updates (or sometimes of reference counting at all) in many cases where Swift requires it. It also seems a bit silly to push for Swift on the backend when excellent and well-supported alternatives exist such as Rust, Go and others.
        lmm 8y ago
        > AIUI, Swift uses reference counting, not fully-general GC. So, it's really not different from Rust from that POV, other than the fact that Rust can avoid the overhead of atomic refcount updates (or sometimes of reference counting at all) in many cases where Swift requires it. No, ARC is a kind of GC. In particular, you have the same pausing behaviour as mark/sweep GC, because freeing any value might result in having to free arbitrarily many other values whose reference counts now go to zero.
    - zozbot123 8y ago
      I'm quite familiar with it. Compared with, e.g. Rust, it very much feels like an also-ran. And Rust has incredible momentum right now.
  - rcruzeiro 8y ago
    Obj-C is 35 years old and it doesn't look like it's going away anytime soon. As for " people/businesses are going back to web instead of App" that's something I've been hearing for 5+ years now but the app ecosystem seems to be doing just fine. That is not to say that some ideas aren't best suited for the web but saying that apps have been losing to the web is a long stretch. To put it simple: there is the web and there are apps. If the app you intend on implementing can be fully replaced by a website, then, by all means, implement it as a website.
    - robertAngst 8y ago
      >Obj-C is 35 years old and it doesn't look like it's going away anytime soon. What continues to be written in Obj C? Unlike its C and C++ counterparts, embedded work is not written in Obj C.
      - rcruzeiro 8y ago
        Pretty much all of the Apple core frameworks and it's unrealistic to think everything will be rewritten in Swift in the next few years. Besides that, you have countless applications for MacOS/iOS that are profitable and will be maintained for the foreseeable future. I guess your point was "what is the relevance of Obj-C outside of the apple ecosystem?" and the answer to that you already know: pretty much none. But given that the apple ecosystem isn't going anywhere anytime soon, Obj-C will continue to be used for better or worse. Swift on the other hand will gain all the relevance that Obj-C is losing within this ecosystem and it also has the potential of gaining a lot of relevance outside of apple as well (although it's not there yet).
        robertAngst 8y ago
        >But given that the apple ecosystem isn't going anywhere anytime soon, Obj-C will continue to be used for better or worse. What is considered soon? 5 years? That is enough to go from Facebook to Myspace. Claims about Swift seem to neglect the world changing power of Javascript.
  - coldcode 8y ago
    Yeah Apple is going out of business as usual, they only made $24B gross profit in the past quarter, did your employer do that? All mobile phone manufacturers are having sales issues including Samsung as everyone these days has a phone and competition for features has jacked up prices too high in the industry. Swift is going just fine, as is Kotlin (its kin in the Java universe) and Rust and Go. Objective-C might be slowing fading away, but then its a 35 year old language being replaced by Swift.
giancarlostoro 8y ago
Apple implementing a spec designed by Microsoft!?!?! Joking, I love that Microsoft came out with LangServ though, felt like something we all should of figured out years and years ago, good thing they wanted to make a cross platform text editor :) I gotta give Microsoft their props, they hire some really smart people who do some great things for the software industry. Props to Apple for doing this too, I am looking forward towards the next stages for the LangServ v4 spec, not sure what more they could do to make it awesome, but I'm sure there's plenty that could happen in the future in this space.
- the_duke 8y ago
  Yeah it seems so obvious in hindsight: of course a language should have ONE editor-optimized compiler/analyzer for IDE like features, which can be reused by all editors out there instead of building half-baked implementations for each IDE. But many things seem obvious in hindsight.
  - nindalf 8y ago
    > many things seem obvious in hindsight. The best ideas seem obvious in hindsight. I've had the experience of reading some books that explain groundbreaking ideas so well that you feel "shit, that's obvious. I should have thought of that". I think Language Server protocol is similar.
  - simias 8y ago
    IMO the reason this rather obvious idea took so long to be implemented was because on one hand the closed source vendors didn't really have a strong incentive to provide something like that (you support your own ecosystem and let the others deal with theirs) and on the other the open source community was spread across many compilers and interpreters which made standardizing difficult. The only project I can think of with enough clout to impose a system unilaterally was GCC, which was notoriously hard to extend and modularize (especially before LLVM started shaking things up a ~10 years ago). So overall the effort to create a protocol and then getting everybody to accept it was rather huge and the chances of success rather slim. It's great that MS finally decided to do it and the huge popularity of VScode (especially with younger coders) seems to have helped a lot.
w-m 8y ago
I was wondering whether that means that Xcode will adopt LSP as well and found this article: https://nshipster.com/language-server-protocol/ https://nshipster.com/language-server-protocol/ "Getting Xcode to use our new LSP service should make it viable to use other LSP services as well, and it’s something that we are interested in, but we don’t have specific plans to announce at this moment." It would be great if this becomes reality. I currently hate switching editors/IDEs for a project using several technologies, because e.g. Xcode is great at C++ debugging but terrible at CUDA editing.
- Joky 8y ago
  Maybe https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform/17024 https://forums.swift.org/t/new-lsp-language-service-supporti... > We are also going to make the necessary changes for Xcode to use this new LSP-based language service. Similar to how you can load an OSS toolchain 397 in Xcode to try it out now, in the future you will be able to load a build of the OSS LSP service in your installed Xcode and test any fixes or enhancements you make.
mikece 8y ago
Language Server implementation for Swift... meaning that writing, compiling, and debugging Swift (and Obj-C) in Visual Studio Code is just around the corner? What other editors/IDEs use Language Server?
- drzaiusx11 8y ago
  I've been using langserver in NeoVim for the past year and it's been great.
  - toupeira 8y ago
    Which plugin are you using? Looking at https://langserver.org/#implementations-client https://langserver.org/#implementations-client there are at least four of them, and IIRC the neovim folks are also working on a native implementation.
    - drzaiusx11 8y ago
      I'm using autozimu/LanguageClient-neovim [1] From my .config/nvim/init.vim: call plug#begin('~/.local/share/nvim/plugged') Plug 'autozimu/LanguageClient-neovim', { 'do': ':UpdateRemotePlugins' } call plug#end() let g:LanguageClient_serverCommands = { \ 'javascript': ['node','/Users/jrousseau/javascript-typescript-langserver/lib/language-server-stdio.js'], \ } " Automatically start language servers. let g:LanguageClient_autoStart = 1 [1] https://github.com/autozimu/LanguageClient-neovim https://github.com/autozimu/LanguageClient-neovim
- ygra 8y ago
  Doesn't the Language Server only cover writing code with things like auto-completion, documentation lookup and refactoring? Compiling doesn't need editor support beyond running arbitrary programs and debugging uses a different protocol, as far as I remember.
jclay 8y ago
For anyone interested, here is their official announcement back in April 2018 on the LLVM mailing list about their vision and plans for the clangd updates. As a C++ dev, I'm excited to see this tooling come to fruition. It's going to make the IDE experience with Clang based tooling far superior on all platforms. https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.h...
- jclay 8y ago
  Related: It's an interesting time for C++ tooling in general. Based on conversations with a member of the Visual Studio team, I've come to understand they're responding to increasing competition from CLion. This was the driving force behind the decision to prioritize first-class CMake support in VS 2017. I also think they're taking notice of what's working well with VSCode and taking that into account for VS 2019 updates. I've moved away from it for my C++ needs since it's just so complex. The vim extension works well, but beyond that I can't master any of the keyboard shortcuts as they're so different than any other editor I've used in the past. These days I use VSCode with VSCodeVim, cmake tools and clang-query (which is fantastic). I've been really loving working with this setup. I fire up VS 2017 with `devenv my_proj.sln` when I'm lacking any advanced performance profiling / debugging features, but this is increasingly rare. Overall, with the clang developments in the last few years, you can entirely replace the MSVC tooling. PDB debugging, ABI-compat, etc. Now clang-query and this work by Apple will ensure the IDE experience is taken care of too. The competition is welcome.
  - pjmlp 8y ago
    Clion still has lots of catchup to do in mixed language debugging, GPGPU, multi-threaded debugging, DirectX debugging, COM/UWP development. From what I see on online discussions, clang still isn't as good as VC++ in incremental compilation and linking support. Then lets also see who gets modules first. Interestingly we had Energize C++, Visual Age for C++ v4 (earlier versions were different) and C++ Builder. Had they managed to win a sizeable marketshare and such C++ nice productivity tooling would have been a thing much sooner.
_asummers 8y ago
The other interesting protocol in this space I only recently became familiar with is the Debug Adapter Protocol or DAP [0]. Curiously it doesnt't seem like there's a standard for test running though? Unless that's supposed to be an LSP action of some sort. [0] https://microsoft.github.io/debug-adapter-protocol/ https://microsoft.github.io/debug-adapter-protocol/
- bobajeff 8y ago
  That's great news to me. I was hoping they do the same for debugging.
- Arnavion 8y ago
  >Curiously it doesnt't seem like there's a standard for test running though? The code lens API allows you to register commands with code spans of your choice. There's no specific built-in command for running tests, so it's ad-hoc. https://microsoft.github.io/language-server-protocol/specification#textDocument_codeLens https://microsoft.github.io/language-server-protocol/specifi... Eg for the Rust LSP server: https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/requests.rs#L890-L903 https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8... + https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/run.rs#L39-L52 https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8...
akhilcacharya 8y ago
This is amazing, I was just wondering why this wasn't a thing a few weeks ago! Can't wait for Swift to be a great general purpose language for me.
linkmotif 8y ago
I finally installed ALE in Vim this summer and have been so happy with it: https://github.com/w0rp/ale https://github.com/w0rp/ale. Great even for linters for JS. Always much easier than expected. Shouldn’t have waited so long...
trevor-e 8y ago
Swift is a really great language and I'm very bullish on it becoming popular for server-side projects in the next few years, once they improve a few things (namely performance gotchas and concurrency).
- qalmakka 8y ago
  One of the most important things they should fix ASAP, IMHO, is how cumbersome it is to install and get up and running on Linux in general, it totally needs something like Rust's rustup before or first party support from major distros before I can recommend it to anyone.
- ken 8y ago
  I see two kinds of programming languages in the world. There are a couple which were designed with a great concurrency model from the start, and there are all the rest which weren’t. In these, concurrency remains awkward at best, and seriously problematic at worst. I have never seen any programming language retcon a good concurrency model onto version 6. The actor proposal I’ve seen looks horrendously complex. I try to be open minded about something I haven’t used yet but I really don’t think this is something you can just bolt on.
  - trevor-e 8y ago
    I do agree with your point, however, I think Swift is in a unique situation since they intentionally deferred on making concurrency first-class. Now the language is in a much better position to implement a modern system. What about the proposal is horrendously complex? The target audience is meant to be language designers, not the average developer. The actual suggested API changes looked to be a few added keywords and some new classes/protocols to use.
  - fauigerzigerk 8y ago
    Hasn't the introduction of async/await to C# been rather successful?
milin 8y ago
This is very exciting! Does this mean it will be possible for users to write swift using vim in a more painless way vs xcode?
- willio58 8y ago
  I don’t believe vim is an IDE, so it won’t be on the same level, but I’ve been writing Swift for websites in VScode for over a year now and using the command line to compile the code.
mikewhy 8y ago
> felt like something we all should of figured out years and years ago Before language server there was YouCompleteMe, a plugin for Vim that had the same ideas. It was eventually ported to other editors, but LSP wasn't far behind and eventually took over. I'm no good with Google Trends, but here they are: https://trends.google.com/trends/explore?date=all&q=youcompleteme,%22language%20server%22 https://trends.google.com/trends/explore?date=all&q=youcompl...
- mikewhy 8y ago
  whoops this was supposed to be a reply to https://news.ycombinator.com/item?id=18883088 https://news.ycombinator.com/item?id=18883088, mods feel free to move it.
- nwah1 8y ago
  YouCompleteMe used fuzzy finding to create something like IntelliSense. LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with, and in conjunction with the Debug Adapter Protocol allows things like setting breakpoints in a standardized way. EDIT: looks like YouCompleteMe did try to use OmniSharp and racer to provide better support for certain languages, but it still is different than a standardized protocol that any language could add support for without needing to be included in a swiss army knife like YCM.
  - mikewhy 8y ago
    > LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with That's what YCM did as well. Well, compilers or other intellisense-adjacent tools (like Jedi for Python, which Python's language server also used, or Tern for JS).
    - nwah1 8y ago
      YCM includes various non-standardized static analyzers and such, and glues them together to be a swiss army knife. LSP is a standardized API that compilers can target, and that means there is no need for a middleware component that does work.
beliu 8y ago
Thanks to Apple for making this open-source. Looking forward to integrating it into Sourcegraph! https://github.com/sourcegraph/sourcegraph/issues/1557 https://github.com/sourcegraph/sourcegraph/issues/1557
deleted 8y ago
[deleted]

232 points by Kryptoshi 8y ago

sgt 8y ago

I love the momentum around Swift these days, and the LSP looks very interesting.

robertAngst 8y ago
What momentum? From the Apple team? Sales and stock price are plummeting at Apple. And from another HN thread, developers are finding people/businesses are going back to web instead of App. Out of all the languages, Swift and Obj C are my 'how much longer until they go away?' languages. Is there anything showing growth? EDIT: Obligatory, Apple users can't handle talking about Apple.
- kkarakk 8y ago
  the server side swift panel at apple's conf was supposedly so full there were people standing. people are definitely interested.
- lupinglade 8y ago
  Have you used Swift? It’s not going away, it’s only going to grow.
  - miguelrochefort 8y ago
    Huh? What makes you think that?
  - lmm 8y ago
    Blind assertion is not an argument. What makes Swift a worthwhile/interesting/valuable language outside of the iOS ecosystem? As far as I can see it's yet another language with basically the ML featureset and nothing else; there are certainly worse starting points, but what reasons are there to adopt Swift that don't apply to OCaml or F#, both of which are more established (to say nothing of Rust/Haskell/Scala that actually offer substantive features that other ML-family languages don't have).
    - the_duke 8y ago
      Swift is kind of like Rust with garbage collection and more convenience baked in. It's a pretty nice language with a lot of adoption due to it being nicer and much more modern than ObjectiveC. It's not going anywhere. There are also companies like IBM pushing for Swift on the server. Personally the bad Linux support makes it uninteresting for me right now.
      - lmm 8y ago
        > Swift is kind of like Rust with garbage collection and more convenience baked in. Sure - but again, OCaml or F# have been there for decades.
        rcruzeiro 8y ago
        But to be fair neither OCaml nor F# picked up any significant traction (at least not compared to Swift).
      - zozbot123 8y ago
        AIUI, Swift uses reference counting, not fully-general GC. So, it's really not different from Rust from that POV, other than the fact that Rust can avoid the overhead of atomic refcount updates (or sometimes of reference counting at all) in many cases where Swift requires it. It also seems a bit silly to push for Swift on the backend when excellent and well-supported alternatives exist such as Rust, Go and others.
        lmm 8y ago
        > AIUI, Swift uses reference counting, not fully-general GC. So, it's really not different from Rust from that POV, other than the fact that Rust can avoid the overhead of atomic refcount updates (or sometimes of reference counting at all) in many cases where Swift requires it. No, ARC is a kind of GC. In particular, you have the same pausing behaviour as mark/sweep GC, because freeing any value might result in having to free arbitrarily many other values whose reference counts now go to zero.
  - zozbot123 8y ago
    I'm quite familiar with it. Compared with, e.g. Rust, it very much feels like an also-ran. And Rust has incredible momentum right now.
- rcruzeiro 8y ago
  Obj-C is 35 years old and it doesn't look like it's going away anytime soon. As for " people/businesses are going back to web instead of App" that's something I've been hearing for 5+ years now but the app ecosystem seems to be doing just fine. That is not to say that some ideas aren't best suited for the web but saying that apps have been losing to the web is a long stretch. To put it simple: there is the web and there are apps. If the app you intend on implementing can be fully replaced by a website, then, by all means, implement it as a website.
  - robertAngst 8y ago
    >Obj-C is 35 years old and it doesn't look like it's going away anytime soon. What continues to be written in Obj C? Unlike its C and C++ counterparts, embedded work is not written in Obj C.
    - rcruzeiro 8y ago
      Pretty much all of the Apple core frameworks and it's unrealistic to think everything will be rewritten in Swift in the next few years. Besides that, you have countless applications for MacOS/iOS that are profitable and will be maintained for the foreseeable future. I guess your point was "what is the relevance of Obj-C outside of the apple ecosystem?" and the answer to that you already know: pretty much none. But given that the apple ecosystem isn't going anywhere anytime soon, Obj-C will continue to be used for better or worse. Swift on the other hand will gain all the relevance that Obj-C is losing within this ecosystem and it also has the potential of gaining a lot of relevance outside of apple as well (although it's not there yet).
      - robertAngst 8y ago
        >But given that the apple ecosystem isn't going anywhere anytime soon, Obj-C will continue to be used for better or worse. What is considered soon? 5 years? That is enough to go from Facebook to Myspace. Claims about Swift seem to neglect the world changing power of Javascript.
- coldcode 8y ago
  Yeah Apple is going out of business as usual, they only made $24B gross profit in the past quarter, did your employer do that? All mobile phone manufacturers are having sales issues including Samsung as everyone these days has a phone and competition for features has jacked up prices too high in the industry. Swift is going just fine, as is Kotlin (its kin in the Java universe) and Rust and Go. Objective-C might be slowing fading away, but then its a 35 year old language being replaced by Swift.

giancarlostoro 8y ago

Apple implementing a spec designed by Microsoft!?!?! Joking, I love that Microsoft came out with LangServ though, felt like something we all should of figured out years and years ago, good thing they wanted to make a cross platform text editor :) I gotta give Microsoft their props, they hire some really smart people who do some great things for the software industry. Props to Apple for doing this too, I am looking forward towards the next stages for the LangServ v4 spec, not sure what more they could do to make it awesome, but I'm sure there's plenty that could happen in the future in this space.

the_duke 8y ago
Yeah it seems so obvious in hindsight: of course a language should have ONE editor-optimized compiler/analyzer for IDE like features, which can be reused by all editors out there instead of building half-baked implementations for each IDE. But many things seem obvious in hindsight.
- nindalf 8y ago
  > many things seem obvious in hindsight. The best ideas seem obvious in hindsight. I've had the experience of reading some books that explain groundbreaking ideas so well that you feel "shit, that's obvious. I should have thought of that". I think Language Server protocol is similar.
- simias 8y ago
  IMO the reason this rather obvious idea took so long to be implemented was because on one hand the closed source vendors didn't really have a strong incentive to provide something like that (you support your own ecosystem and let the others deal with theirs) and on the other the open source community was spread across many compilers and interpreters which made standardizing difficult. The only project I can think of with enough clout to impose a system unilaterally was GCC, which was notoriously hard to extend and modularize (especially before LLVM started shaking things up a ~10 years ago). So overall the effort to create a protocol and then getting everybody to accept it was rather huge and the chances of success rather slim. It's great that MS finally decided to do it and the huge popularity of VScode (especially with younger coders) seems to have helped a lot.

w-m 8y ago

I was wondering whether that means that Xcode will adopt LSP as well and found this article: https://nshipster.com/language-server-protocol/ https://nshipster.com/language-server-protocol/ "Getting Xcode to use our new LSP service should make it viable to use other LSP services as well, and it’s something that we are interested in, but we don’t have specific plans to announce at this moment." It would be great if this becomes reality. I currently hate switching editors/IDEs for a project using several technologies, because e.g. Xcode is great at C++ debugging but terrible at CUDA editing.

Joky 8y ago
Maybe https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform/17024 https://forums.swift.org/t/new-lsp-language-service-supporti... > We are also going to make the necessary changes for Xcode to use this new LSP-based language service. Similar to how you can load an OSS toolchain 397 in Xcode to try it out now, in the future you will be able to load a build of the OSS LSP service in your installed Xcode and test any fixes or enhancements you make.

mikece 8y ago

Language Server implementation for Swift... meaning that writing, compiling, and debugging Swift (and Obj-C) in Visual Studio Code is just around the corner? What other editors/IDEs use Language Server?

drzaiusx11 8y ago
I've been using langserver in NeoVim for the past year and it's been great.
- toupeira 8y ago
  Which plugin are you using? Looking at https://langserver.org/#implementations-client https://langserver.org/#implementations-client there are at least four of them, and IIRC the neovim folks are also working on a native implementation.
  - drzaiusx11 8y ago
    I'm using autozimu/LanguageClient-neovim [1] From my .config/nvim/init.vim: call plug#begin('~/.local/share/nvim/plugged') Plug 'autozimu/LanguageClient-neovim', { 'do': ':UpdateRemotePlugins' } call plug#end() let g:LanguageClient_serverCommands = { \ 'javascript': ['node','/Users/jrousseau/javascript-typescript-langserver/lib/language-server-stdio.js'], \ } " Automatically start language servers. let g:LanguageClient_autoStart = 1 [1] https://github.com/autozimu/LanguageClient-neovim https://github.com/autozimu/LanguageClient-neovim
ygra 8y ago
Doesn't the Language Server only cover writing code with things like auto-completion, documentation lookup and refactoring? Compiling doesn't need editor support beyond running arbitrary programs and debugging uses a different protocol, as far as I remember.

jclay 8y ago

For anyone interested, here is their official announcement back in April 2018 on the LLVM mailing list about their vision and plans for the clangd updates. As a C++ dev, I'm excited to see this tooling come to fruition. It's going to make the IDE experience with Clang based tooling far superior on all platforms. https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.h...

jclay 8y ago
Related: It's an interesting time for C++ tooling in general. Based on conversations with a member of the Visual Studio team, I've come to understand they're responding to increasing competition from CLion. This was the driving force behind the decision to prioritize first-class CMake support in VS 2017. I also think they're taking notice of what's working well with VSCode and taking that into account for VS 2019 updates. I've moved away from it for my C++ needs since it's just so complex. The vim extension works well, but beyond that I can't master any of the keyboard shortcuts as they're so different than any other editor I've used in the past. These days I use VSCode with VSCodeVim, cmake tools and clang-query (which is fantastic). I've been really loving working with this setup. I fire up VS 2017 with `devenv my_proj.sln` when I'm lacking any advanced performance profiling / debugging features, but this is increasingly rare. Overall, with the clang developments in the last few years, you can entirely replace the MSVC tooling. PDB debugging, ABI-compat, etc. Now clang-query and this work by Apple will ensure the IDE experience is taken care of too. The competition is welcome.
- pjmlp 8y ago
  Clion still has lots of catchup to do in mixed language debugging, GPGPU, multi-threaded debugging, DirectX debugging, COM/UWP development. From what I see on online discussions, clang still isn't as good as VC++ in incremental compilation and linking support. Then lets also see who gets modules first. Interestingly we had Energize C++, Visual Age for C++ v4 (earlier versions were different) and C++ Builder. Had they managed to win a sizeable marketshare and such C++ nice productivity tooling would have been a thing much sooner.

_asummers 8y ago

The other interesting protocol in this space I only recently became familiar with is the Debug Adapter Protocol or DAP [0]. Curiously it doesnt't seem like there's a standard for test running though? Unless that's supposed to be an LSP action of some sort. [0] https://microsoft.github.io/debug-adapter-protocol/ https://microsoft.github.io/debug-adapter-protocol/

bobajeff 8y ago
That's great news to me. I was hoping they do the same for debugging.
Arnavion 8y ago
>Curiously it doesnt't seem like there's a standard for test running though? The code lens API allows you to register commands with code spans of your choice. There's no specific built-in command for running tests, so it's ad-hoc. https://microsoft.github.io/language-server-protocol/specification#textDocument_codeLens https://microsoft.github.io/language-server-protocol/specifi... Eg for the Rust LSP server: https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/requests.rs#L890-L903 https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8... + https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/run.rs#L39-L52 https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8...

akhilcacharya 8y ago

This is amazing, I was just wondering why this wasn't a thing a few weeks ago! Can't wait for Swift to be a great general purpose language for me.

linkmotif 8y ago

I finally installed ALE in Vim this summer and have been so happy with it: https://github.com/w0rp/ale https://github.com/w0rp/ale. Great even for linters for JS. Always much easier than expected. Shouldn’t have waited so long...

trevor-e 8y ago

Swift is a really great language and I'm very bullish on it becoming popular for server-side projects in the next few years, once they improve a few things (namely performance gotchas and concurrency).

qalmakka 8y ago
One of the most important things they should fix ASAP, IMHO, is how cumbersome it is to install and get up and running on Linux in general, it totally needs something like Rust's rustup before or first party support from major distros before I can recommend it to anyone.
ken 8y ago
I see two kinds of programming languages in the world. There are a couple which were designed with a great concurrency model from the start, and there are all the rest which weren’t. In these, concurrency remains awkward at best, and seriously problematic at worst. I have never seen any programming language retcon a good concurrency model onto version 6. The actor proposal I’ve seen looks horrendously complex. I try to be open minded about something I haven’t used yet but I really don’t think this is something you can just bolt on.
- trevor-e 8y ago
  I do agree with your point, however, I think Swift is in a unique situation since they intentionally deferred on making concurrency first-class. Now the language is in a much better position to implement a modern system. What about the proposal is horrendously complex? The target audience is meant to be language designers, not the average developer. The actual suggested API changes looked to be a few added keywords and some new classes/protocols to use.
- fauigerzigerk 8y ago
  Hasn't the introduction of async/await to C# been rather successful?

milin 8y ago

This is very exciting! Does this mean it will be possible for users to write swift using vim in a more painless way vs xcode?

willio58 8y ago
I don’t believe vim is an IDE, so it won’t be on the same level, but I’ve been writing Swift for websites in VScode for over a year now and using the command line to compile the code.

mikewhy 8y ago

> felt like something we all should of figured out years and years ago Before language server there was YouCompleteMe, a plugin for Vim that had the same ideas. It was eventually ported to other editors, but LSP wasn't far behind and eventually took over. I'm no good with Google Trends, but here they are: https://trends.google.com/trends/explore?date=all&q=youcompleteme,%22language%20server%22 https://trends.google.com/trends/explore?date=all&q=youcompl...

mikewhy 8y ago
whoops this was supposed to be a reply to https://news.ycombinator.com/item?id=18883088 https://news.ycombinator.com/item?id=18883088, mods feel free to move it.
nwah1 8y ago
YouCompleteMe used fuzzy finding to create something like IntelliSense. LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with, and in conjunction with the Debug Adapter Protocol allows things like setting breakpoints in a standardized way. EDIT: looks like YouCompleteMe did try to use OmniSharp and racer to provide better support for certain languages, but it still is different than a standardized protocol that any language could add support for without needing to be included in a swiss army knife like YCM.
- mikewhy 8y ago
  > LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with That's what YCM did as well. Well, compilers or other intellisense-adjacent tools (like Jedi for Python, which Python's language server also used, or Tern for JS).
  - nwah1 8y ago
    YCM includes various non-standardized static analyzers and such, and glues them together to be a swiss army knife. LSP is a standardized API that compilers can target, and that means there is no need for a middleware component that does work.

beliu 8y ago

Thanks to Apple for making this open-source. Looking forward to integrating it into Sourcegraph! https://github.com/sourcegraph/sourcegraph/issues/1557 https://github.com/sourcegraph/sourcegraph/issues/1557

deleted 8y ago

[deleted]