Adamas: experimental LSP-first compiler work, current status, and feedback request

I think your understanding is mostly correct. A big part of LSP is helping you navigate and understand code, especially code written by other people. Jump to definition, find references, rename symbols, hover docs, autocomplete, etc. It’s basically a smarter way of exploring a codebase than grepping through files.

A lot of the demand for LSP also comes from people who grew up using IDEs. They’re used to having methods, types, parameter names, and documentation available right in the editor. It isn’t really about code generation, it’s more about reducing the need to constantly switch between your editor and documentation.

Personally, I think the value depends a lot on the language and ecosystem. For something like Java, C#, or TypeScript, where there are huge frameworks and libraries, LSP can be a massive productivity boost because nobody can remember every API.

With Crystal, though, I’ve never felt the lack of LSP as strongly as some people do. The standard library is relatively compact, the ecosystem is still fairly small, and the API docs are excellent. Most of the time I can just keep the docs open, do a quick search, and find what I need.

That said, I can understand why people working on larger Crystal projects want better LSP support. Features like jump-to-definition, find references, and reliable refactoring become more valuable as a codebase grows. If you’re spending all day moving around a large project, those little conveniences add up quickly.

As for why there’s less resistance to LSP than LLMs, I think it’s because LSP is mostly helping you understand code that already exists, while LLMs are trying to generate new code. People generally trust tooling that helps them navigate their code more than tooling that tries to write it for them.

Yes, LSP is most useful on medium to large projects, but even for small projects it boosts your productivity by allowing you to jump really fast to the proper methods.

As of compiler and LSP: No, the compiler is not needed for LSP, but I had my own itch to scratch after I implemented a parser and type inferencer. I always wanted to implement some features that the original compiler does not allow you to implement, as too many changes have to be made.
In my compiler, there are two more layers (HIR and MIR) that allow you to do better optimizations and propagation analysis before generating LLVM IR code.

I see. So was your motivation not just to improve the LSP experience, but also to refactor the compiler into layers like HIR and MIR after building the parser and type inferencer?
Was LSP one application of that work?
Of course, motivation and what becomes possible often go back and forth.

Initially, I was working only on LSP, but when the parser and type inferer were done, I was curious enough to see if agents can build a whole compiler based on my wild ideas I had for some time.

Thank you. I felt that the main value of this project may not be LSP itself, but the reorganization of the compiler using LSP as a kind of test case.

This may be especially true for the Crystal community, where many people seem to see programming not only as a tool, but also as a craft.

But this is also hard to explain. It is a bit like training a deep learning model and getting excited not about the final result, but about the learned weights: how the model compressed and organized the complexity.

For an amateur like me, with limited time, it is hard to read a summary and feel that I really understand what happened inside.

Yes, it somewhat hard to explain, but I am trying to the best of my abilities.

As of LLM models. I am doing that too with Crystal: GitHub - skuznetsov/cogni-ml: Crystal ML library: Autograd, Tensors, Neural Networks, Optimizers · GitHub

It has all necessary tools to build a model, and natively read the weights from GGUF files and do dequant.
It actually has Qwen 3.5/3.6 inference engine, that works faster on Metal than llama.cpp for both prefill and tocen generation.

If validated, this is an achievement for Crystal, since llama.cpp is the go-to option for local LLMs.

Now it only depends on how far you want to go, Sergey @ComputerMage

Thank you! You can do independent validation by asking agents to compare the performance on the same set of prompts of different sizes: prefill and token generation of 8,32,64,256,1024,4096 tokens. CogniQwen is even faster than llama.cpp when working with bigger chunks and bigger model sizes.

It works really fast not only because of Crystal, but because of the mathematical optimizations and fused Metal kernels. as main work happens on GPU without moving data between GPU and CPU until the last moment.
It happens because I spent 2 years working on LLM protocol that improves reasoning skills and task focus of the LLM models, and it gave and Adamas LSP and Cogni-ML and pg_sorted_heap and Crystal_TUI.

Not far off. The other killer feature to me is smart autocomplete. If the LSP can identify the type of the object you’re at, you can complete the methods, which saves typing and aids my lousy memory.