ElixirLS - the Elixir Language Server

TL;DR: I’ve just released an implementation of Microsoft’s IDE-independent Language Server Protocol for Elixir. It adds language support and debugger integration to VS Code, and can (in theory) be used by other IDEs, too. Cross-posting this from my new blog here.

I’ve been spoiled by good IDEs. Once you’ve gotten used to an IDE like RubyMine or IntelliJ IDEA, it’s hard to go back to just using text editors.

Elixir has an open-source IntelliJ plugin, IntelliJ Elixir, and it’s quite good. A few months ago, I started contributing to its development, adding ExUnit test support and debugger integration. It was fun to work on, but I got a bit frustrated with having to write Java. The IntelliJ Elixir codebase is all Java and it’s quite large — it includes an Elixir lexer and parser written in Java, among other code intelligence features.

There’s another approach that other editors are using — write the code insight logic in Elixir, and run a server in separate process that communicates with the editor or IDE. The original Elixir editor plugin that used this approach was Alchemist for Emacs, and the author published the Elixir code powering it as Alchemist Server. Another developer built upon Alchemist Server and created Elixir Sense which is being used in Atom and VS Code. With respect to IntelliJ Elixir, I’m convinced that the “language server” approach is the way to go because of the code reuse it enables.

It turns out, Microsoft has embraced this approach. They’ve published a JSON-based standard they’re calling the Language Server Protocol for IDE-agnostic language support, and it’s the standard way to write language plugins for VS Code. Red Hat is also backing the protocol and has added support for it to Eclipse Che. Microsoft also published a spec for a similar protocol for debugger integration, the VS Code debug protocol.

I’ve just released an early alpha of ElixirLS, a language server implementing these protocols for Elixir. It’s got debugger integration supporting line breakpoints, plus most of the standard editor features such as autocompletion and go-to-definition. It also reports build warnings and errors immediately as you type.

The server code is available here, and the associated VS Code extension is here.

I want to be clear that this is a very rough release. I’ve only tested it on OSX using Elixir 1.4, and it has significant known bugs. (The extension won’t even launch with Elixir 1.3, and most features don’t work properly for umbrella projects, for example.) I’m hoping to iron out the kinks in the coming versions, but right now, it can’t be considered stable. I’m hoping that the Elixir community might have some good ideas on how to improve it. If all you want is a stable editor for Elixir, stick with whatever you’re using now.

The best thing about having a standard protocol for IDE support is that it’s super easy to contribute to. You don’t have to know anything about VS Code or any other IDE. The spec is simple and well-documented — if you can write Elixir, you can contribute! If you’re interested in more of how it works, I’ve written a couple more blog posts on debugging Elixir in VS Code and on some of the compiler hacks I needed to enable reporting build warnings and errors as you type.

I hope other Elixir developers find it useful, or at least interesting. Give it a try, and happy coding!


Awesome! I been looking for this long time ago! Waiting for more updates :smiley:

I tried to run it on Windows (seems like a few bunch of people here use windows), the installation don’t gives any problem but when I open any elixir file it simply dont work:

just to report ^^

NOTES: I have disabled all the existing plugins of elixir in my VS Code, so seems like your plugin highlight the sintaxis (if the plugin dont do that please tell me maybe I did wrong when I disabled the old plugins)

The plugin does do syntax highlighting (which is copied directly from the other VS Code Elixir plugin). I was able to reproduce that failure. I’ll see if I can debug it soon. Windows is unfortunately rather foreign to me though.

Any thoughts on how to integrate this with sublime 3? I tried VS Code for a month (full time), but ended up going back to sublime. I just could not get a workflow that worked as well as sublime.


I’m pretty excited about this. I mainly use atom, but if this worked well I’d make the switch.

1 Like

looks great - fyi there is a google soc project for this thing https://summerofcode.withgoogle.com/projects/#6578779248918528 so maybe talk with @michalmuskala about getting the most out of everybody’s time…


Very cool, are you familiar with langserver.org? It’s a community-driven source of knowledge for Language Server Protocol implementations. Many existing implementations exist for different languages and editors.

Hm, someone more familiar with Sublime would have to implement a client for it. If someone did so, though, they’d get very good support for a lot of languages for free. Hopefully someone volunteers to take it on :slight_smile:

Edit: Looks like there is a project implementing Sublime support: https://github.com/sourcegraph/sublime-lsp

1 Like

Ooh, I didn’t realize it was part of gsoc or I’d have applied! I’ll try to get in touch with them. Thanks!


I posted to the Beam Community mailing list: https://groups.google.com/forum/#!topic/beam-community/e5epuBbjSeI

Is it too much to ask for instructions on how to run it standalone?

There is an LSP implementation in emacs that I would like to try it with.

Does it work with vim?

I used to work with IntelliJ and VisualStudio, but prefer vim these days


@edmz To run it standalone, clone the elixir-ls repo. It’s an umbrella project. To run it, run mix run --no-halt from the language_server app directory. Note that it currently communicates over stdio, not a network socket, so it could be a bit tricky to do any standalone testing unless you can figure out how to launch it properly from your editor. Same goes for the debugger app in the umbrella.

I haven’t come up with a good way of packaging it up. Most packaging and release tools include Elixir itself in the release, which is not what you’d want for a developer tool (since the developer will have his own version of Elixir installed.) I’m open to suggestions on that, but for now, you have to run it with mix even in the release.

@gregvaughn I haven’t tried it with any clients besides VS Code (which, confusingly, is not Visual Studio). But there does seem to be work on integrating language servers with Vim (here) and NeoVim (here).

The emacs implementation is TCP only.

Is a TCP version something planned?

I hadn’t seen that, thanks for the tip! I’m happy to see that there are projects implementing clients for it for lots of different editors.

It… is now!

1 Like

btw, I just found another emacs lsp mode that uses stdio.

Hah, I was working on something like this as well (https://github.com/Korbin73/Elixirist). Looks like you got further than me, do you accept pull requests if we find something that needs fixing?

Of course! Happy to have help on it :slight_smile: It sounds like there’s someone working on it as well for Google Summer of Code, though I haven’t succeeded in getting in touch with him yet.

I’ve just published v0.0.5 which includes Windows support. Give it a try! It should be running much more reliably now with different Elixir versions, too.

What I ended up doing to package it for release is compiling it to an escript, but not embedding Elixir in the escript, since you’ll want to use your system’s Elixir installation. Instead, I included shell and batch scripts that try to find your system Elixir and set ERL_LIBS to include it before running the escript. Lemme know if it still fails to launch and I’ll do my best to figure it out. Thanks!

1 Like