Julia supports incremental compilation.
What does that got to do with Crystal?
Crystal: Fast as C, Slick as Ruby with Tom Richards
21–28 of 28 posts
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#22Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#23Earlier quoted context omitted.
>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…
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 ;)
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#24Earlier quoted context omitted.
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…
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.c…
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 ;)
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#25Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#26Crystal 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 an…
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.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#27Earlier 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.
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-t…
Nice, I'll have to check it out again this year. Might be a good chance to look into Helix, too.
Re: Crystal: Fast as C, Slick as Ruby with Tom Richards
#28Earlier 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.
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)