Language Server Protocol Support for Sublime Text 3 | Hacker News Reader

Language Server Protocol Support for Sublime Text 3

github.com

169 pointskristianp26 comments

I think Language Servers are my favorite feature from Microsoft in the development of VSCode. Microsoft has come a long way with open source, not only with VSCode but improving developer tools across the board.

Similar to textmate grammars being adopted by virtually every new editor, language servers will help others bootstrap new editor concepts more rapidly and with a more rich feature set from the start.

I think Microsoft rarely gets credit for plenty. They were the ones who started AJAX and Mozilla reverse engineered it for example. Now they are going pretty much all in for WebAssembly with C# with their Blazor project which lets you either render views on the server as they already are or render them on the client with a 1 liner type of setting. I have yet to see another major company building WebAssembly tooling this early on. This is the kind of thing that puts WebAssembly in the mainstream and readily available though.

> I have yet to see another major company building WebAssembly tooling this early on.

Qt has been working on webassembly support for more than 1 year - https://msorvig.github.io/qt-webassembly-examples/quick_cloc...

Emphasis on major.

Rust+WebAssembly is excellent.

I'm sure I'm missing something. The beauty of Rust is you can operate at the baremetal level in safety. It's not the most productive language to work with. So why target WebAssembly from it?

Some of us find the language highly productive, and extremely accurate in its usage in many different spaces.

In terms of webassembly, there is a sweet spot for Rust, which is in speeding up CPU bound JS routines. There is a project, wasm-bindgen, to make building these high performance pieces and injecting them into JS easy.

Some of us even want to see it grow as an alternative language for full web development. There are a few projects that aim to make this easy (compiling to wasm): stdweb, cargo-web, js-sys. It’s already a fully capable language capable of targeting the web.

The features you get for this that many of us appreciate: no garbage collector (ie bounded memory usage), strict error checking, strongly typed null checks, an amazing type system, etc. Productivity means different things to different people.

Here's an example: I wanted to have decent hashing performance in JavaScript (large file uploads protected against bitrot). There are a hodgepodge of different JavaScript libraries with inconsistent algorithm support and performance characteristics; SubtleCrypto is becoming more standard but has limited algorithm support and doesn't support efficient operations on large inputs.

With https://github.com/acdha/wasm-hashing I was able to use the high-quality Rust hashing system to support all of the different algorithms I needed with a consistent interface and performance was actually competitive with or better than the browsers' native SubtleCrypto implementation.

That's a really nice capability to have in your back pocket, especially since it comes with Rust's usual assistance for code-quality.

That’s very cool!

Is there a reason you’re using wasm-bindgen directly instead of using wasm-pack?

When I started wasm-pack was still moving pretty rapidly and it took a lot longer to do builds when I was working interactively. Now that the split went through I've been meaning to revisit that.

Ah, cool :) if it goes poorly, I’m sure the team would love to know!

They've posted a lot of interesting updates since I last worked on that. Might be time to dust that project off.

> They were the ones who started AJAX and Mozilla reverse engineered it for example.

I think you have your answer right there. MS added AJAX as a proprietary feature to make the experience of using Outlook in Explorer richer than in Mozilla.

At the time they were ignoring standards bodies and trying to lock thr web down to running in IE on Windows only. Hence them paying Apple to push a similar (but inferior) version of IE on the Mac.

" MS added AJAX as a proprietary feature to make the experience of using Outlook in Explorer richer than in Mozilla."

No, they wanted Outllok Web to be closer in usability to Outlook Desktop. They had a problem and they solved it. This is how the web standards body works anyway : somebody does something good/inovative (see ajax, jquery etc etc) and after a while it gets standardized.

There was no standard to ignore since the whole feature set didn't exist. Firefox is not ignoring a standard by integrating Pocket to the address bar.

> They were the ones who started AJAX and Mozilla reverse engineered it for example.

Yes, Microsoft even invented DHTML(which wasn't in the DOM spec). But Microsoft also stalled web standards and Ecmascript effort for a whole decade as well.

Waiting when it will be merged in NeoVim [1][2].

[1] https://github.com/neovim/neovim/pull/6856

[2] https://github.com/neovim/neovim/issues/5522

There are already a few language server implementations for Neovim

I've been happily using the LanguageClient LSP implementation [1] for about a year.

[1] https://github.com/autozimu/LanguageClient-neovim

I haven't tried this yet and I don't know how well it works, but it looks like a good way to move forward for Sublime Text.

I personally like the philosophy of making a tool that does one thing and does it well. I keep getting back to Sublime because of how fast it starts and how well it handles very large files. Features like this should have a significant impact on both those advantages.

I'm totally fine with this being just a plug-in and it does indeed offer a great advantage to the community overall.

I’m really excited about language servers. I finally installed ALE in Vim and it works great. It can use language servers and all kinds of external tools like linters, but those are a bit slow because they have to spawn a new process just to perform a check. Looking forward to trying out the Flow language server sometime.

What would be a reason to use a tool like this in a proper IDE? I mean they should provide these features already. But I see them support eclipse, jetbrains, etc.

For the user of a fully functioning ide, probably not that much; LSP would be more important for developers of that software, since its less work to maintain, and improvements come free.

Otherwise, it’d be things like faster/better support for non-tier-1 languages, like perhaps kotlin on eclipse, or rust on jetbrains, while stealing the benefits of their other work (I feel like outside of the more complex refactoring support, theres not much IDEs provide specific to their target language, that LSP doesn’t, but I’m not that sure)

Its basically just less work for everyone involved; end-user-benefit being a byproduct of that

The line between IDE and "text editor" is fuzzy these days. Mainly I think many people, such as myself, have an editor of choice. The editing process itself is what makes the editor their preference, so that's what they build their experience around. This is why (imo) you get text editors like sublime, vim, emacs serving such an IDE-centric experience. People don't think of it like IDE vs not-IDE, it's all an IDE, if you enjoy it you try to add features you want. Switching to a fully fledged IDE may have better language experiences, but for many that's the lesser factor.

Hell, Vim has a lot of this stuff, but I switched to Kakoune a long while back, giving up a ton of my addons/plugins for languages. I can still write them (and am working on it), but the point is Kakoune is not nearly as widely supported on tooling as Vim is. Yet, the editor reigns supreme to me, and I prefer Kakoune.

It's quite obvious. Instead of every IDE supporting every language (N*M), you have every IDE supporting language server and one implementation of server per language (N+M).

Reply on news.ycombinator.com