Crystal: Fast as C, Slick as Ruby with Tom Richards
1–10 of 28 posts
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#2I know it's 6 years old, but it's a good talk, IMO.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#3Crystal is close to being my ideal language, but the compile times are really, really bad.
Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies.
The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky), and the response on the forums was "don't use Crystal for large projects", "I don't think the compiler is slow" and a couple of really good technical explanations of how improving the compile times is almost a pipe dream outside of a major redesign.
I'm salty because the feel-in-hand of Crystal is best in class, but the DX is worst in class and I get the impression that that's not going to change.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#4Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
I take it the interpreter they added a few years ago isn't mature enough to address this or it can't?
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#5Julia supports incremental compilation.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#6Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
I take it the interpreter they added a few years ago isn't mature enough to address this or it can't?
It's not included in releases (you have to compile Crystal yourself if you want it), so I'd guess it's still a WIP.
And even if, it still has the same restrictions; any change means type checking everything from scratch, where the time it takes to do that scales (IIRC) worse than linear.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#7Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
I ran into the same issue with an LSP for Crystal. The fix was in the source code there wasn't that much to edit.
Open source is a real blessing, getting something so sophisticated and amazing for free.
I thought about submitting the patch, but then I realized that might not be in the best interest of the Crystal community. Don't wanna get flooded with Ruby types too fast. A party is better when you don't let just anybody through the door.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#8Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
>I'm salty because the feel-in-hand of Crystal is best in class, but the DX is worst in class and I get the impression that that's not going to change.
What is the difference between feel-in-hand and DX ? I know that DX means developer experience.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#9Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
>Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies.
Is this an issue of type inference in general (and therefore exists in all languages that do type inference), or is it related of Crystal's implementation of type inference?
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#10Crystal is close to being my ideal language, but the compile times are really, really bad. Because of how the type inference works, the compiler cannot (effectively) compile incrementally, which means that any change causes a full compilation. This includes dependencies. The final straw for me was when the (unofficial) LSP paused some ~30 seconds on every keystroke in a tiny project with one large dependency (Lucky),…
This is a problem with all these languages (zig, nim, crystal, D, vlang, etc). They are all neat but the DX is so bad that Java with a good IDE is faster to code in.
Zig and Nim with VSCode kind of work. Nim integration is very easy to break, Zig LSP auto complete does weird stuff. Nim's LSP seems to parse whole project from disk on each auto complete so it's slow.