There was a recent post on Reddit asking why there wasn’t an LSP for Crystal. This is a copy / paste of what I said in response, repeated for visibility and further discussion. There are a number of things that make writing a language server for Crystal difficult. There is no fault tolerant parser, which is necessary to provide functionality with “broken” code (well, there was before the tree sitter got a lot of improvements, at 99.07% of the stdlib parsing without errors now) Crystal’s complex syntax makes it incredibly difficult to make a fault tolerant parser There is no semantic analysis done (by the compiler) to methods that aren’t used A full semantic analysis of the stdlib and all files is required (due to the nature of the language) every time a change is made Type inference means that the types of variables and parameters depends on how they’re used, requiring semantic analysis of everything to ensure types are accurately captured Everything is in a global namespace, and analysis relies on one or multiple entrypoints that have to be specified explicitly Crystalline has been around for a few years and it does the best for what it has, re-using a lot of the semantic analysis that the compiler uses. It works for some people, especially on small to medium sized projects. I’d recommend giving it a try to see how well it works for you. I’ve been working on a language server since last June, very much far from done but here’s a list of what I have so far: Auto-generated bindings to the language server protocol based on Microsoft’s own generated bindings for Rust / Python, see GitHub - nobodywasishere/lsprotocol-crystal: Code generator and generated types for Language Server Protocol & Crystal lang Basic framework for a language server to be implemented, pulling a lot of inspiration from Crystalline, named larimar Started doing a lot of research into fault-tolerant parsers and language server architectures (Roslyn, Rust, etc), and even started implementing my own fault-tolerant parser, but this is an immense task that may not be the best approach Worked with a group of amazing people to put a lot of work into the tree sitter parser for Crystal GitHub - crystal-lang-tools/tree-sitter-crystal: tree sitter parser for crystal lang . This is especially useful for syntax highlighting in helix / neovim / zed Began to put a lot of work into improving ameba, a linter for Crystal that I find very useful and should be used more widely by the community I’ve integrated both ameba and the tree sitter back into larimar to provide linting, syntax errors, and syntax highlighting in an editor-independent way. It’s not 100% yet for those but it’s a starting point I intend to keep working on ameba, adding semantic analysis to allow for better linting. I intend to take some of the code that’s used for that and re-use it in larimar. How exactly that will work i have some ideas but that’s still WIP. See Expand ameba's functionality with semantic information · Issue #513 · crystal-ameba/ameba · GitHub My current approach that some people may not like, is that to get LSP-like features, methods / parameters / variables need to be explicitly typed. It’s the only way to avoid needing a full semantic analysis to resolve types. Having spent the past year and a half working on tooling surrounding Crystal, I’ve become extremely familiar with the limitations of the language, and how it’s seemingly designed to be as hard as possible to have good tooling for. I know a lot of people in the community may be dissatisfied or frustrated with the current state of tooling, but the limitations of Crystalline are the limitations of the language itself, and it’s very hard to work around / outside of those without some compromise. Progress is being made, but it needs to be done carefully and will take time.

I think I was originally approaching this of requiring types to get autocomplete, but I think you bring up a really great point I haven’t thought of, and a potentially different way of looking at this problem. In the case of this: def foo(a) b = a.| end I think all possible methods should be autocompleted, regardless of what foo is called with, if at all. Then whatever methods are called on a, not only restrict the type of b based on the return type of the methods, but also restrict the type of a based on what objects have those methods. So: def foo(a) b = a.abs # Let's pretend this restricts `a` to `Number` a.| # ^ autocomplete only methods on `Number` a.bar # ^^^ error: method `bar` doesn't exist on `Number` end I may go with the more strict need-to-type-things approach to start with, but this does provide a lot of promise for larimar and ameba to do partial / lossy semantic analysis (I intend to re-use the same visitor for both). I wonder if it’d also be possible to bubble up parameter types from their bodies? Like in the same example: def foo(a) b = a.abs # Let's pretend this restricts `a` to `Number` end foo("bar") # ^^^^^ error: parameter `a` should be `Number`, not `String` # or # ^^^^^ error: String does not have method `abs` Something to explore once more a framework is laid out.

IMO explicitly typing everything is a minor inconvenience at worst and leads to safer code in the end, so it’s 100% worth it. Type information on hover is the feature I personally would like the most, for which strict typing is certainly a prerequisite.

I’ve been using GitHub - elbywan/crystalline: A Language Server Protocol implementation for Crystal. 🔮 for a while now. The only issue I’ve had with it is that it slows down over time… I don’t spend much time programming Crystal to invest in debugging this; but it works for my other LSP needs. If you’re on Reddit — I’m not — please share this there :pray:

[image] nobodywasishere: My current approach that some people may not like, is that to get LSP-like features, methods / parameters / variables need to be explicitly typed. It’s the only way to avoid needing a full semantic analysis to resolve types. At first, this made me sad. Then I thought a bit more about it. In practice, it’s probably quite fine, as one tends to type much anyway. [image] nobodywasishere: I think I was originally approaching this of requiring types to get autocomplete, but I think you bring up a really great point I haven’t thought of, and a potentially different way of looking at this problem. But this would be extra cool. [image] Barney: IMO explicitly typing everything is a minor inconvenience at worst and leads to safer code in the end, so it’s 100% worth it. I’m not sure I agree. My method might only require the argument you pass it answer to [](String) with a String, but if I typehint it to Hash(String, String) I limit your options on what you can pass. No passing it a HTTP::Headers, no matter how convenient it might be.

I am not familiar with LSP, but something just chocked me about Crystal: Crystal’s complex syntax ??? I would like to understand. Have you got an example ?

[image] Xen: I’m not sure I agree. My method might only require the argument you pass it answer to [](String) with a String, but if I typehint it to Hash(String, String) I limit your options on what you can pass. No passing it a HTTP::Headers, no matter how convenient it might be. I think that’s a bit of a special case. In quite many cases it’s entirely possible to easily type most parameters. And I think that’s generally a good idea because it documents the interface of a method. Also we can improve cases like the one you described to make it possible to type them in a meaningful way. For example Add a module for implementing Hash-like objects · Issue #10886 · crystal-lang/crystal · GitHub might be useful for that. Another approach might be Constrain type vars / free variables to specific types · Issue #934 · crystal-lang/crystal · GitHub with an implicit interface declaration.

[image] straight-shoota: I think that’s a bit of a special case. In quite many cases it’s entirely possible to easily type most parameters. Well, it’s duck typing. And it’s the cases left over from “quite many cases” that I’m thinking about. [image] straight-shoota: Also we can improve cases like the one you described to make it possible to type them in a meaningful way. My personal favourite is Go style interfaces. Move focus from what a thing is to how you interact with it.

[image] Proposal: Interfaces for more generic code Community This is a great idea, and I’d like this to happen. The problem is that interfaces are typed, but in the rest of the language it’s not mandatory to type your methods. So a user will create a type with def to_i without an explicit return type, and the compiler won’t consider that type. For example BigDecimal has to_i without a return type. Same goes for BigFloat, Complex and maybe others. The problem is that when you create an interface expecting to “capture” existing types with it, that might…

Well, maybe in 2.0 then… Anyway, I just wanted to point out that not everybody thinks “just type everything” is all it’s cracked up to be, but I won’t derail the threat further. But an LSP that can complete on variables with known types, and make an educated guess for those without, would be excellent. Is larimar in a state where it’s worth trying out, or is it still to early?

That is true. There is a middle ground of something closer to type hints rather than type restrictions (see crystal-lang/crystal#15334) that I’ve also been thinking about. Things are still too early, the only things that exist currently are semantic tokens using the tree sitter and ameba integration. I’ll let people know when there’s something that’s worth testing.

"Why isn't there an LSP for Crystal?"

Crystal Contrib Tooling

nobodywasishere February 7, 2025, 4:24pm 13

Topic		Replies	Views
Crystalline - LSP server for Crystal Community	40	5824	June 10, 2022
Adamas: experimental LSP-first compiler work, current status, and feedback request Tooling	28	1133	June 4, 2026
Incremental compilation exploration Crystal Contrib	114	8464	October 13, 2025
How about the new lightwight semantic analyzer in newest 0.19 crystalline? Help & Support	6	448	September 18, 2026
Crystal lsp in crystal i Help & Support	4	412	October 16, 2023

"Why isn't there an LSP for Crystal?"

Related topics