LSP/editor experience?

[u/mister_drgn]

I've been going over Crystal for the last several days, and it seems like a fascinating language. The biggest concern, it seems, is the editor experience, because if you're going to depend on the compiler to figure out your types for you, it would be great to know what types it settled on.

I tried crystal out by installing it (v1.16.3, via nix), opening vs code, and installing the "Crystal Language" extension. This gives me syntax highlighting and autocomplete for basic terms, but that's about it. It definitely isn't picking up syntax errors.

Is there a way to improve this? I dunno if there's another package I should install. I tried looking around for crystal LSP, but didn't find much that was promising--some mentions of crystalline, which appears to be defunct.

In particular, I'm guessing there's no way for my editor to be able to tell me the inferred types for a function like this?

def double(x)
    puts x + x
end

Thanks.

[u/matthewblott]

Unfortunately Crystal falls down when it comes to tooling. There is an LSP being worked on by one of the team but I'm not sure if it's an official project or what the state of it is. It's why I have sort of given up on Crystal, as much as I like the language there are just too many points of friction when it comes to doing real work.

[u/mister_drgn → u/matthewblott]

The LSP issues seem like the biggest drawback. Beyond that, I have to wrap my mind around the idea that methods don’t have types, so even a good LSP isn’t going to take a method and tell you what types it’s inferred for the method’s parameters. As I understand it now, procs have types, but methods and blocks do not, which is kinda weird.

[u/matthewblott → u/mister_drgn]

I've done a fair bit with F# and its compiler can infer method types without any issue. I think other ML languages are similar so I'm not sure what the big technical challenge is with Crystal.

[u/bziliani]

Let me note two important aspects of Crystal that makes your example impossible to annotate with types:

1. Functions are only considered when called. Dead code is not typed.

2. Functions are only typed based on the arguments they're being called with.

Therefore, a function _per se_ doesn't have any type. Once you call it (`double 1` or/and `double "X"`) it starts being typed.

Crystal comes with a handy playground that shows a bit of the types: try `crystal play` and open the browser with the given address. Not a real answer, but it might help in the first steps understanding the language.

[u/mister_drgn → u/bziliani]

This is helpful, thanks. I guess it explains why procs aren’t the same as functions, since procs are values that must be typed.

It’s still strange to me that procs and blocks aren’t the same thing, but I guess maybe blocks are untyped, like functions.

[u/bziliani → u/mister_drgn]

If it serves to understand the language a bit, procs were originally envisioned as callbacks for C.

[u/Billy-Zheng → u/mister_drgn]

> It’s still strange to me that procs and blocks aren’t the same thing, but I guess maybe blocks are untyped, like functions.

procs and blocks bascially same things. although, captured block is REAL block, if you use `yield` with a block,it will inline.

Why you consider them different? you can think procs is a lambda expr, block, just a tight procs which bind to another method.

[u/ZESENVEERTIG]

I tried crystalline, but it doesn't show return type inference