4 ms·

Crystal 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 (effect

Crystal 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.

nathan_compton 3y ago
I take it the interpreter they added a few years ago isn't mature enough to address this or it can't?
- fredrikholm 3y ago
  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.
nukeyoular 3y ago
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.
- paholg 3y ago
  Hold on. You're saying that you made a small fix that vastly increases the performance of the Crystal LSP, but you're refusing to submit it upstream because you're worried about Ruby programmers adopting Crystal? What kind of elitist fucking bullshit is that? I've read plenty of things on the internet that have made me angry, but perhaps none so viscerally. Rethink your life choices.
fuzztester 3y ago
>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.
- fredrikholm 3y ago
  The language semantics, the standard library and the ease of which I can read other peoples code are all very good compared to just about anything. Compile times and tooling are compared to the competition, sorely lacking. Auto complete, suggestions, documentation-on-hover etc are so slow that they're essentially useless. For example, adding a simple model with two fields in an empty Lucky project (Rails, but Crystal) makes all my CPU fans spin at 100% capacity for ~35 seconds. Lucky has hot reload built in, but compiling those 6 lines take longer than cloning, compiling and running $FORMER_DAYJOB's ~800k lines of Go code base.
  - blacksmoke16 3y ago
    Keep in mind a good portion of the compile times for an application is dependent on what the code is doing and your hardware. I.e. just because Lucky is slow in this regard for you doesn't mean every project/framework is going to be just as bad for everyone else. E.g. I can compile a dev build of the compiler in 20s. Also I don't personally use an LSP, but the VSCode extension recently was re-written: https://forum.crystal-lang.org/t/crystal-vscode-extension-v0-9-0-released/6488 https://forum.crystal-lang.org/t/crystal-vscode-extension-v0.... So may be worth checking out again. Or just don't use an LSP ;)
    - fredrikholm 3y ago
      Cheers, all valid points! :) With regards for compile times, I'm spoiled by languages that have sub-second compile times to the point where I actively lean on the compiler while I'm writing (see next point). With regards to LSPs, I'm spoiled by the 1990s and can't live without auto-completion and suggestions. Why write something in 26 keystrokes when 4 will do ;)
fuzztester 3y ago
>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?
- fredrikholm 3y ago
  Crystals, as it allows you to specify zero types in your entire project should you want to, whilst still type checking in a language where every type is implicitly a union (eg. "this is a string or an int or null"). The result of that is a cyclical graph where nodes are traversed several times over per pass, for several passes, with increasingly more information until it reaches a state where all callers have been accounted for.
  - bdjsiqoocwk 3y ago
    Julia allows you to specify no types, and it still supports incremental compilation.
  - fuzztester 3y ago
    Wow. Thanks for both of your replies. The last paragraph of your reply above reminds me somewhat of a part of this talk, somewhere near the end: Lang NEXT 2014 Panel Systems Programming in 2014 and Beyond https://youtu.be/ZQR32nTVF_4?si=zQNTWBXcp4TkSnRh https://youtu.be/ZQR32nTVF_4?si=zQNTWBXcp4TkSnRh It is the part where Bjarne Stroustrup talks about the issue of the huge compilation times of multi-file C++ projects, due to the number of times that header files are repeatedly included, IIRC. The section is a bit funny, with the responses from the other participants. There may be a solution for by now (modules), but I am not a C++ guy, so don't know if it exists or is good enough. Interested to know what others think of this.
winrid 3y ago
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.
- snovymgodym 3y ago
  On pure pragmatic grounds, it's really difficult to justify any of these new languages when you compare the tooling and support of those that have either been around longer or have company/institutional support.
  - winrid 3y ago
    Yeah. That's why I talk about it. I want people to build good IDE support for Nim :)
- archargelod 3y ago
  Nim has been on a steady path of improving tooling support[0] since 2.0 release. LSP is a lot more stable now than even a couple months ago. That's what I love from community-driven languages: while BDFL isn't very passionate about tooling, people have spoken and gears are turning to improve it[1]. It also helps that there is a company around (Status) that's using Nim in production and wants to invest money and dev-time[2] in the language. - [0] https://github.com/nim-lang/RFCs/issues/544 https://github.com/nim-lang/RFCs/issues/544 - [1] https://forum.nim-lang.org/t/10959 https://forum.nim-lang.org/t/10959 - [2] https://forum.nim-lang.org/t/10762 https://forum.nim-lang.org/t/10762
  - winrid 3y ago
    Nice, I'll have to check it out again this year. Might be a good chance to look into Helix, too.
- ilrwbwrkhv 3y ago
  That's why Go is actually perfect. Tooling works great and compile times are super fast. Language is super simple.

nathan_compton 3y ago

I take it the interpreter they added a few years ago isn't mature enough to address this or it can't?

fredrikholm 3y ago
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.

nukeyoular 3y ago

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.

paholg 3y ago
Hold on. You're saying that you made a small fix that vastly increases the performance of the Crystal LSP, but you're refusing to submit it upstream because you're worried about Ruby programmers adopting Crystal? What kind of elitist fucking bullshit is that? I've read plenty of things on the internet that have made me angry, but perhaps none so viscerally. Rethink your life choices.

fuzztester 3y ago

>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.

fredrikholm 3y ago
The language semantics, the standard library and the ease of which I can read other peoples code are all very good compared to just about anything. Compile times and tooling are compared to the competition, sorely lacking. Auto complete, suggestions, documentation-on-hover etc are so slow that they're essentially useless. For example, adding a simple model with two fields in an empty Lucky project (Rails, but Crystal) makes all my CPU fans spin at 100% capacity for ~35 seconds. Lucky has hot reload built in, but compiling those 6 lines take longer than cloning, compiling and running $FORMER_DAYJOB's ~800k lines of Go code base.
- blacksmoke16 3y ago
  Keep in mind a good portion of the compile times for an application is dependent on what the code is doing and your hardware. I.e. just because Lucky is slow in this regard for you doesn't mean every project/framework is going to be just as bad for everyone else. E.g. I can compile a dev build of the compiler in 20s. Also I don't personally use an LSP, but the VSCode extension recently was re-written: https://forum.crystal-lang.org/t/crystal-vscode-extension-v0-9-0-released/6488 https://forum.crystal-lang.org/t/crystal-vscode-extension-v0.... So may be worth checking out again. Or just don't use an LSP ;)
  - fredrikholm 3y ago
    Cheers, all valid points! :) With regards for compile times, I'm spoiled by languages that have sub-second compile times to the point where I actively lean on the compiler while I'm writing (see next point). With regards to LSPs, I'm spoiled by the 1990s and can't live without auto-completion and suggestions. Why write something in 26 keystrokes when 4 will do ;)

fuzztester 3y ago

>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?

fredrikholm 3y ago
Crystals, as it allows you to specify zero types in your entire project should you want to, whilst still type checking in a language where every type is implicitly a union (eg. "this is a string or an int or null"). The result of that is a cyclical graph where nodes are traversed several times over per pass, for several passes, with increasingly more information until it reaches a state where all callers have been accounted for.
- bdjsiqoocwk 3y ago
  Julia allows you to specify no types, and it still supports incremental compilation.
- fuzztester 3y ago
  Wow. Thanks for both of your replies. The last paragraph of your reply above reminds me somewhat of a part of this talk, somewhere near the end: Lang NEXT 2014 Panel Systems Programming in 2014 and Beyond https://youtu.be/ZQR32nTVF_4?si=zQNTWBXcp4TkSnRh https://youtu.be/ZQR32nTVF_4?si=zQNTWBXcp4TkSnRh It is the part where Bjarne Stroustrup talks about the issue of the huge compilation times of multi-file C++ projects, due to the number of times that header files are repeatedly included, IIRC. The section is a bit funny, with the responses from the other participants. There may be a solution for by now (modules), but I am not a C++ guy, so don't know if it exists or is good enough. Interested to know what others think of this.

winrid 3y ago

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.

snovymgodym 3y ago
On pure pragmatic grounds, it's really difficult to justify any of these new languages when you compare the tooling and support of those that have either been around longer or have company/institutional support.
- winrid 3y ago
  Yeah. That's why I talk about it. I want people to build good IDE support for Nim :)
archargelod 3y ago
Nim has been on a steady path of improving tooling support[0] since 2.0 release. LSP is a lot more stable now than even a couple months ago. That's what I love from community-driven languages: while BDFL isn't very passionate about tooling, people have spoken and gears are turning to improve it[1]. It also helps that there is a company around (Status) that's using Nim in production and wants to invest money and dev-time[2] in the language. - [0] https://github.com/nim-lang/RFCs/issues/544 https://github.com/nim-lang/RFCs/issues/544 - [1] https://forum.nim-lang.org/t/10959 https://forum.nim-lang.org/t/10959 - [2] https://forum.nim-lang.org/t/10762 https://forum.nim-lang.org/t/10762
- winrid 3y ago
  Nice, I'll have to check it out again this year. Might be a good chance to look into Helix, too.
ilrwbwrkhv 3y ago
That's why Go is actually perfect. Tooling works great and compile times are super fast. Language is super simple.