In my experience Compilation speed is an excellent bikeshed that lots of developers complain about if they're evaluating a language. It's an easy thing to say "Well the compilation speed" as a reason to discount a language, but in reality Compilation speed (barring like, truly incredible times for basic things) is a simple Pro/Con in a massive sea of pros and cons.

You can also go further and decide what in said 'sea' is more or less important.

Compilation speed greatly effects your ability to iterate in your development process. Depending on your skill level, for most programmers this can be MASSIVE (its literally your development frame rate). Also depends on domain too, for example, something with a ton of IO/sideeffect needs more iterative development than say an algo.

Sure there are ultra high experience devs who can make a thousand line edit, send the build and have it run perfectly 4 hours later. Even in that case you need to consider the cost of coding extra defensively to make sure it's right the first time.

> Compilation speed greatly effects your ability to iterate in your development process. Depending on your skill level, for most programmers this can be MASSIVE

Compilation speed is not the only factor in ability to iterate. This argument is the exact bikeshed argument that gets made all the time. Even if your compilation is insanely fast, your build pipeline might be insanely slow. Compilation speed alone isn't enough to really make any value judgements at all, is my entire point.

> Sure there are ultra high experience devs who can make a thousand line edit, send the build and have it run perfectly 4 hours later. Even in that case you need to consider the cost of coding extra defensively to make sure it's right the first time.

My last job used Ruby on Rails, a language that is touted to have extremely fast iteration speed. That company also chose to have a build process run all tests (unit + system), such that a "build" took 3+ hours. To say, "Ruby on Rails has fast iteration speed and doesn't require a compile step" ignores so much context about what's actually happening, the statement is effectively useless.

Ruby on rails has nothing to do with fast iteration speed. It's incredibly slow and doesn't care a little about the horrible dev experience. I used it professionally for 12 years.

I don't think you're using bike shed in the right context, but let's not go down that rabbithole.

I specifically did evaluate Crystal some time ago, having a set of properties that seemed to hit a sweet spot. I gave it a fair go working on several projects with some of the popular Crystal web frameworks. I went in with full enthusiasm. In the end, only the most basic framework, Kemal (Lightning Fast, Super Simple web framework. Inspired by Sinatra) was tolerable. Definitely not a Rails/Ruby replacement. After that, I favored Phoenix/Elixir for such projects.

> I don't think you're using bike shed in the right context, but let's not go down that rabbithole.

Glad you found that worthwhile to bring up but not extrapolate on :)

> specifically did evaluate Crystal some time ago, having a set of properties that seemed to hit a sweet spot. I gave it a fair go working on several projects with some of the popular Crystal web frameworks. I went in with full enthusiasm. In the end, only the most basic framework, Kemal (Lightning Fast, Super Simple web framework. Inspired by Sinatra) was tolerable. Definitely not a Rails/Ruby replacement. After that, I favored Phoenix/Elixir for such projects.

Great! Glad you found something that worked out for you! I'm noticing you didn't bring up compilation time in your complaints about Crystal specifically, which seems like a worthwhile thing to point out given we're discussing Crystal compilation times.

Regardless, in the spirit of my other recent post, I'm glad you found a tool/language that you enjoy (Phoenix/Elixir)!

Sorry I wasn't clear. I first tried to use a more featured framework, Lucky or Amber but only Kemal compiled fast enough. I'm pretty sure they all would have executed the application fine.

I have nothing against Crystal. In fact I still think it's great, just not for the kinds of things (e.g. web dev) that I would do in languages like Ruby, Go, or Java. Similarly, Pony is a fantastic language (Rust done right IMO) but I don't have a use for what it/Rust delivers in my typical projects. In short, I think Crystal could benefit from better/clearer positioning, as the digressing discussions in these comments show.

In my experience, over the past 2 years there's been quite a good speed up in compile times in Rust, but that's just for my case on an older laptop. On my desktop, there's never been an issue.

Long compile times suck, but Crystal and Rust have never put me off because of that. I can wait another few seconds.

I mean, I agree when build times take more than a minute, I don't care about seconds. Have you used languages that take less than a few seconds (in total) to compile?

Also in my experience Crystal compiles simple projects faster than Rust and somewhat comparable to Julia, but much slower than (e.g.) C or Zig, which I think is fine for a language with higher level features. Maybe I haven't done anything big enough with Crystal yet to see the compilation times though?

And of course, I expect it will get better over time, there are things that can be done like parallelization and cached incremental compilation results (like Cargo or Gradle do)

Rust has an 'excuse' for compile speed, in that, the compiler is ostensibly doing 'more work'.

I'm not sure what you're implying by this, because the Crystal compiler is doing a lot of work as well. The global type inference is the primary reason for Crystal's compiler speeds, and it's why it's not likely to substantially improve. It's not slow for the sake of being slow.

Java does type inference in a number of places and javac is not slow.

Java doesn't do type inference at the level of Crystal. It's not the presence of type inference, it's the fact that almost everything in a Crystal program can be inferred.

javac produces Java bytecode, not LLVM IR.

javac exists since at least 15 years, Crystal "only" 6 years.

Maybe things will get better with time?

What work would that be?

? The borrow checker which is literally the reason Rust exists.

Borrow checking is almost always very cheap, and lifetime are erased before codegen which is the really slow part.