Crystal: Fast as C, Slick as Ruby with Tom Richards | Hacker News Reader

Crystal: Fast as C, Slick as Ruby with Tom Richards

youtube.com

34 pointsfuzztester27 comments

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.

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.

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.

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.

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

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.

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.... So may be worth checking out again. Or just don't use an LSP ;)

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 ;)

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

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.

Julia allows you to specify no types, and it still supports incremental compilation.

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

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.

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.

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.

Yeah. That's why I talk about it. I want people to build good IDE support for Nim :)

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

- [1] https://forum.nim-lang.org/t/10959

- [2] https://forum.nim-lang.org/t/10762

Nice, I'll have to check it out again this year. Might be a good chance to look into Helix, too.

That's why Go is actually perfect. Tooling works great and compile times are super fast. Language is super simple.

Go indeed makes it hard to justify languages like Nim.

I'm kinda scared I'll like Go so much and then my Java knowledge will quickly decay x)

on the other hand, the "Jai" beta is quite good in this regard.

I think this is not just a problem with ecosystems, but a consequence of the language design itself. Zig and Nim have extensive meta programming language facilities that making good autocompletion support is a very hard problem, while Java doesn't have such a complicated language design. (The problem with Java though is that it's instead hard to use without an IDE since there's too much boilerplate because of its spartan design).