Introducing Rust Language Server, source release

[TylerJewell]

Hi - project lead for Eclipse Che. This is a great step forward. A couple of items for you to think about:

1. Eclipse Che currently provides LSP support, but I believe that Eclipse and Orion (a web editor) are thinking about their path forward. All are Eclipse projects, but different platforms with Che being a distributed workspace server and cloud IDE. Che has been shipping support for a couple months in the 5.0 milestone train. We have another generational advance planned and this is the epic for that. https://github.com/eclipse/che/issues/2109

2. With that, Che has provided a packaging approach that we call agents which will package different language servers for dynamic deployment in a distributed workspace. We would very much like it if you could open a tracking GitHub ticket so that your language server can be packaged as an agent and deployable within workspaces. It’s not a lot of work, just a ZIP packaging and some bash scripts that help unpack it and start the server, registering it with a browser IDE. We would then make sure that this package was associated with the Rust workspace stack and Rust file types. We have been seeking more language servers for testing, and this is perfect. Zend has been doing a lot of work related to having PHP support in the same way - you can see their tracking epic here. https://github.com/eclipse/che/issues/2590. They are going pretty far beyond the basics.

3. And (cough cough) to be fair, it was Microsoft, RedHat and my company, Codenvy, as the initial companies that pushed the language protocol out the door :). Codenvy is a supporter of Che and we felt this was essential to allow languages to be used in a distributed setting, and we wanted interoperability with VS Code and other IDEs.

[TylerJewell]

I think the guys at Sourcegraph have started on an emacs language server already. You may want to ask them about it.

[Wilfred]

Super exciting! I might explore adding Emacs integration (the ‘kitchen sink’ editor ).

Should I be worried about JSON-RPC protocols running locally? There was a security update for Guile recently due to offering dev tools listening on localhost over HTTP. I suppose at this point, the only change a malicious user could make are the refactorings.

[sanxiyn]

I got RLS working with Atom using atom-languageclient.

Unfortunately, it doesn’t work out of the box. Out of the box, it doesn’t even load! This is strange, because after fixing loading issues which are shallow, it worked great. So it must be working for the author.

[matthieum]

A small note regarding indexing/compiling.

I am currently using CLion on a sizeable codebase, when doing git pull --rebase CLion needs to update its indices which takes some time because of said size, which is understandable.

The really annoying part, however, is that while the update is ongoing the indices are unusable.

Please, please, keep two sets of indices in RLS: the last complete one, and the one being rebuilt.

Not only does it give a better user experience, but it also means that the speed at which you rebuild matters less (since probably not that much actually changed).

[glaebhoerl]

Please, please, keep two sets of indices in RLS: the last complete one, and the one being rebuilt.

This is also important to be able to continue offering type information (about the remaining, unaffected things) if the code is edited and now contains a type error, isn’t it? It’s what the Haskell analogues do as far as I’m aware.

[nrc]

Please, please, keep two sets of indices in RLS: the last complete one, and the one being rebuilt.

Yep, we do this

[nrc]

I wonder how you plan to solve this problem.

Yeah, this is a hard problem and we don’t have a solid plan. It is on our minds though.

Maybe the compiler should gain to ability to output only the metadata (.rmeta file ??) instead of a full .rlib ?

It already can (-Zno-trans), we use this in the RLS but that is the reason it struggles with syntax extensions. We plan to add better support to the compiler and Cargo in the very near future to avoid this problem.

[nrc]

Thanks for the info, I filed an issue to make an Eclipse Che agent. Hopefully, we’ll have something created soon!

[matklad]

This is also important to be able to continue offering type information (about the remaining, unaffected things) if the code is edited and now contains a type error, isn’t it?

Hm, I don’t think so. To deal with errors (and most of the time they are syntax errors), you need to be lax in your typehcecking. For example, when checking a function call you always give the return type as the result, without looking at the argument’s types (or quantity). For if, you don’t unify branches and just return the type of the first branch which has a valid type.

Type inference is mostly a local affair, so you don’t need indices much, as it is cheap just to recalculate it for the currently open files. Indices are used mostly (at least in IntelliJ) for finding stuff in other files, that is, for non local things.

[TylerJewell]

Fantastic - I think longer term, there is not a consistent way that language servers should be packaged for different projects. There is a long thread on the language server repository about this where the Microsoft engineers want to use NPM to package a language server, but we are resisting that idea. We dynanically install language servers into workspaces that are containers which can have any OS, so we look for POSIX compliance. One idea is to have language servers package themselves into Dockerfiles which can be launched consistently by any tool. And then the tool would be responsible for hooking up the container with the project files in a workspace.

We would then like to have an open source registry hosted at the foundation for eclipse where language servers can list themselves, update themselves, and let any tool have discovery automatically.

[raindev]

I’m really excited to see the amazing work in the direction of editor independent tooling My only concern: I hope the good tooling support would not be used as a justification of not fixing the weaknesses of the language. That’s the trap Java fell into. E.g., people are tolerating lots of unnecessary boilerplate because of IDEs.

[3442853561]

I translated your article into Chinese. https://mp.weixin.qq.com/s?__biz=MzIwNjQ2NjI4NA==&mid=2247483891&idx=1&sn=c96158022dd835d19965572437967316&chksm=97207c70a057f5668d1b1a8985dd7f0dc777ac6b65ff74a97d4655cf82ff7841cf28339e8737&scene=0#rd

[bbigras]

I’ll end up starting an emacs LS package soon, if someone doesn’t beat me to it.

I might explore adding Emacs integration

Did you guys started to work on it? Do you think now that emacs supports “shared/dynamic libraries” that the package could be written in Rust?

[cmr]

Did you guys started to work on it?

Yes. https://github.com/sourcegraph/emacs-lsp. It’ll be pretty much complete by 2016-11-11, the current status is not quite ready

Do you think now that emacs supports “shared/dynamic libraries” that the package could be written in Rust?

No, I don’t think that makes any sense at all.

[bbigras]

It’ll be pretty much complete by 2016-11-11

Nice!

No, I don’t think that makes any sense at all.

Why (I’m not arguing, I’m just curious, that information could be useful one day)? Is it because modules needs to be compiled with emacs making them a pain to use?

[bbigras]

It’ll be pretty much complete by 2016-11-11

Any update?

[cmr]

sourcegraph/emacs-lsp

It has basic support for a few methods: hover, definition, references, and symbol search. I haven’t tested it with the RLS yet. I’ll be adding support for the additional methods supported by the RLS over the next few days.

RE: compiled emacs plugin, it doesn’t make sense in that the benefits of Rust are pretty much non-existent and the cost of integration with elisp is too high. As you mention it also does complicate deployment.

[fmdkdd]

FYI, another Emacs package has popped up:

emacs-lsp/lsp-mode

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.