Crystal: Fast as C, Slick as Ruby with Tom Richards • Hacker News Board

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

#11

Post by snovymgodym » Sat, Mar 09, 2024, 7:54 PM UTC

winrid wrote: post #10

fredrikholm wrote: post #3

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),…

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.

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

#12

Post by fredrikholm » Sat, Mar 09, 2024, 8:27 PM UTC

fuzztester wrote: post #8

fredrikholm wrote: post #3

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),…

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

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

#13

Post by fredrikholm » Sat, Mar 09, 2024, 8:39 PM UTC

fuzztester wrote: post #9

fredrikholm wrote: post #3

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),…

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

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

#14

Post by winrid » Sat, Mar 09, 2024, 9:44 PM UTC

snovymgodym wrote: post #11

winrid wrote: post #10

Earlier quoted context omitted.

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

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

#15

Post by bdjsiqoocwk » Sat, Mar 09, 2024, 9:55 PM UTC

fredrikholm wrote: post #13

fuzztester wrote: post #9

Earlier quoted context omitted.

>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 ac…

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

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

#16

Post by fuzztester » Sat, Mar 09, 2024, 10:01 PM UTC

fredrikholm wrote: post #13

fuzztester wrote: post #9

Earlier quoted context omitted.

>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 ac…

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.

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

#17

Post by archargelod » Sun, Mar 10, 2024, 2:52 AM UTC

winrid wrote: post #10

fredrikholm wrote: post #3

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),…

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.

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

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

#18

Post by ilrwbwrkhv » Sun, Mar 10, 2024, 2:56 AM UTC

winrid wrote: post #10

fredrikholm wrote: post #3

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),…

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.

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

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

#19

Post by adamrezich » Sun, Mar 10, 2024, 5:10 AM UTC

winrid wrote: post #10

fredrikholm wrote: post #3

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),…

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 the other hand, the "Jai" beta is quite good in this regard.

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

#20

Post by cyber_kinetist » Sun, Mar 10, 2024, 6:07 AM UTC

winrid wrote: post #10

fredrikholm wrote: post #3

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),…

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.

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