Live data from Hacker News

Crystal 1.0 – What to expect

crystal-lang.org

241–250 of 351 posts

Re: Crystal 1.0 – What to expect

#241

Earlier quoted context omitted.

What is the compilation speed like? EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

Moore's law has stopped, and not every developer's workstation is 'fast'.

Re: Crystal 1.0 – What to expect

#242

Earlier quoted context omitted.

Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you…

No, Julia is not statically typed and will outperform pretty much anything, at least when dealing with numerical code. Next generation climate models are built with Julia. You would not pick a slow language for such a high performance dependent task.

Julia is statically typed, or at least it is for the inner bottleneck loops. If you want fast numeric code in Julia then you have to have homogeneous arrays. (Besides, I'd be very surprised if Julia doesn't have Fortran libraries driving it under the hood.)

You're confusing dynamic typing and type inference.

Re: Crystal 1.0 – What to expect

#243

Earlier quoted context omitted.

Crystal's appeal, for me at least, is the productivity of Ruby with the memory efficiency and execution speed of C++. Static typing is just a way of achieving that, it's not something I'm seeking per se.

Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you…

> Is static typing really necessary for speed?

Absolutely yes. If you don't know the shape of your data at compile time then you're going to destroy your performance discovering and validating it at runtime.

Re: Crystal 1.0 – What to expect

#244

Earlier quoted context omitted.

What is the compilation speed like? EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

It is a huge difference if you can compile is less then a second (giving you almost repl functionality) or if you have to resort to nightly builds for large projects. Even 15 minute builds hamper development.

Re: Crystal 1.0 – What to expect

#245
post #116
post #55

Congrats on the release! The biggest factor drawing me to experiment a little with Crystal is that it is one of very few languages providing what otherwise has been pretty unique to Go: Lightweight threads+Channels+M:N concurrency (automatically multiplexing the lightweight threads onto a smaller number of OS threads). Also it does it with a very readable and clean syntax. Wrote a little about it, with code compariso…

> automatically multiplexing the lightweight threads onto a smaller number of OS threads For Crystal 1.0, the number of OS threads is always 1, isn’t it? So although this provides concurrency, it’s less powerful than Go where the same mechanism also provides parallelism.

Unless you supply the -Dpreview_mt flag, as in the post, as far as I understand :)

Re: Crystal 1.0 – What to expect

#246

Earlier quoted context omitted.

What is the compilation speed like? EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

Two kinds of people: - people who routinely compile huge code bases; - people who compile an OS. C is still here because it compiles UNIX fast.

Re: Crystal 1.0 – What to expect

#247
post #55

Congrats on the release! The biggest factor drawing me to experiment a little with Crystal is that it is one of very few languages providing what otherwise has been pretty unique to Go: Lightweight threads+Channels+M:N concurrency (automatically multiplexing the lightweight threads onto a smaller number of OS threads). Also it does it with a very readable and clean syntax. Wrote a little about it, with code compariso…

Haskell's concurrency has those features! The Async library contains high level combinators for concurrency that are particularly nice to use. (page1, page2) https://hackage.haskell.org/package/async-2.2.3/docs/Control...

Thanks for the pointer!

Re: Crystal 1.0 – What to expect

#248

Earlier quoted context omitted.

Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you…

It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if…

Type inference can only get you so far when the language and runtime allow you to devolve values to an 'Optional[Any]' at literally any given statement.

Sometimes discipline must be enforced on the programmer.

Re: Crystal 1.0 – What to expect

#249

Earlier quoted context omitted.

What is the compilation speed like? EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

Compile speed is part of Developer Experience, and one of the most important aspects thereof is the feedback cycle. I want to see the results of my code changes as fast as possible, and the performance of my hardware is rarely ever the bottleneck.

Re: Crystal 1.0 – What to expect

#250

Earlier quoted context omitted.

What is the compilation speed like? EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

I think if you've been bitten by compilation times in e.g. Scala or C++, then compile speed is something you end up caring about. When it comes to modern static languages, it seem like there's a tradeoff where providing all the abstractions and ergonomics to make you not miss any functionality from dynamic languages will instead expand compilation times and make you miss the instant feedback of an interpreted language. Or give up on that and make the language much simpler and more limited, and you get fast compilation (e.g. Go). So I think people are looking for the holy grail of a language with both ease of use, extensive ergonomics and abstractions, while maintaining fast compilation times. So anytime a candidate comes along they ask about the parts of that equation that are not in the bullet list.
Post reply on HN