Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crystal 1.0 – What to expect

crystal-lang.org

Post reply on HN
Print view View original

131–140 of 351 posts

Re: Crystal 1.0 – What to expect

#131

Post by Trasmatta »

Zababa wrote: post #119
Trasmatta wrote: post #61

Earlier quoted context omitted.

They "why" is basically having a language with the aesthetics and usability of Ruby, but fully statically typed with global type inference, and impressive performance. The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.

> The downside being a relatively slow compiler. It's the necessary trade-off for the type inference. I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .

Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed.

I believe you can speed up your compile times a bit by being explicit with annotations (which I often prefer anyway), but there's still a lot of overhead for the global type inference.

Re: Crystal 1.0 – What to expect

#132

Post by _joel »

Trasmatta wrote: post #81
dkarras wrote: post #75

Earlier quoted context omitted.

See, when you add "performance" to those properties it piques my interest. I'd love me a high performance language that is sanely typed, allows for metaprogramming, feels like an interpreted language while doing so etc. However the main page says absolutely nothing about performance. I even don't care about compile times. So what is the performance like?

You can find some benchmarks here: https://github.com/kostya/benchmarks With the caveat of course being that benchmarks don't always reflect real world performance.

Also Crystal based web frameworks tested here (key: Cry) same caveat as above. https://www.techempower.com/benchmarks/

Re: Crystal 1.0 – What to expect

#133

Post by steveklabnik »

wiremine wrote: post #86
dang wrote: post #53

If curious, here are the significant past threads I found. Others? An Introduction to Crystal - https://news.ycombinator.com/item?id=26217013 - Feb 2021 (39 comments) Switch from Ruby to Crystal - https://news.ycombinator.com/item?id=25005780 - Nov 2020 (35 comments) Go vs. Crystal Performance - https://news.ycombinator.com/item?id=23615303 - June 2020 (160 comments) Ruby vs. Crystal Performance - https://news.ycombi…

This is great, thanks for putting in the time to put this together! Side note: Anybody know of tools that auto-compile lists like this? I'm sure it's not perfect, but these sorts of reviews really add value to the current conversation.

Kind of hilariously, years ago we had a user that would do this. It was sort of controversial for reasons I don’t really remember; I always enjoyed it. They eventually stopped posting.

Re: Crystal 1.0 – What to expect

#134

Post by galaxyLogic »

vasilakisfil wrote: post #38

Crystal is a beautiful language, however compiling times is something that put off most people who try it. How comes and they don't allow you to optionally provide types in your function/class signatures so you can help the compiler and speed up the whole process ? I mean global type inference is nice, but giving the option to specify types and speeding up the compiling time would be even more nice.

> the option to specify types

I think that would be good no only to reduce compile times but also to make code more readable

Re: Crystal 1.0 – What to expect

#135

Post by viraptor »

onlyrealcuzzo wrote: post #107
Doctor_Fegg wrote: post #23

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…

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 you don't have a world class well funded team - yes, static typing is necessary for performance.

Re: Crystal 1.0 – What to expect

#136

Post by bovermyer »

The_rationalist wrote: post #103
ibraheemdev wrote: post #4

It feels like Crystal it took all the best things from the languages I love, and put them together into one, beautiful language: - Elegance of Ruby - Statically type checked + global type inference - No Nulls - Go-like concurrency - Easy C ffi - High performance I really hope the Crystal succeeds and the language goes mainstream - this release is a huge step forward towards that. Congrats to the Crystal team for reac…

All of those points are already met and in a better way by mature languages like e.g Kotlin. Really the only argument would be the "Ruby elegance" (or familiarity?) which I don't know. What make ruby/crystal more "elegant" (I would prefer the term readable ) than the competition?

Well, speaking purely from personal experience, Crystal is much more enjoyable to write and read than Java derivatives.

Take that with a grain of salt, though, since I have a deep-seated hatred of Java stemming from experiences in the early 00s.

Re: Crystal 1.0 – What to expect

#137

Post by viraptor »

pansa2 wrote: post #117
sjwright wrote: post #104

Earlier quoted context omitted.

I haven’t ever understood the argument against static typing. I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” The only exception to this is untrusted input, but for that an string is usually always fine.

> I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.

Change it to "this variable is always going to be a T, never not a T" and it still stands.

Re: Crystal 1.0 – What to expect

#138

Post by fishmaster »

Trasmatta wrote: post #131
Zababa wrote: post #119

Earlier quoted context omitted.

> The downside being a relatively slow compiler. It's the necessary trade-off for the type inference. I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .

Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed. I believe you can speed up your compile times a bit by being explicit with annotations (…

> Maybe the most powerful of any fully statically typed language?

Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.

Re: Crystal 1.0 – What to expect

#139

Post by asterite »

fishmaster wrote: post #138
Trasmatta wrote: post #131

Earlier quoted context omitted.

Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed. I believe you can speed up your compile times a bit by being explicit with annotations (…

> Maybe the most powerful of any fully statically typed language? Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.

Those functional languages don't have function overloading or named arguments. The type inference in Crystal works very differently. The type of a method can only be computed from explicit calls to it. In those functional languages the type can be computed independent of a call because it's trivial to do so if a function name always refers to a single entity.

Re: Crystal 1.0 – What to expect

#140

Post by brigandish »

vasilakisfil wrote: post #38

Crystal is a beautiful language, however compiling times is something that put off most people who try it. How comes and they don't allow you to optionally provide types in your function/class signatures so you can help the compiler and speed up the whole process ? I mean global type inference is nice, but giving the option to specify types and speeding up the compiling time would be even more nice.

> How comes and they don't allow you to optionally provide types in your function/class signatures

Perhaps you mean something else, but this is from the book Programming Crystal:

> Returning Values

> A method returns the value of its last expression, so there’s no need to explicitly return that or declare its type. However, if you want to document or directly control that return type, you can explicitly specify the type, as in this example:

> methods_and_procs/methods.cr

    def typed_method : Array(Int32)
      (42..47).to_a.select { |n| n % 4 == 0 }
    end

    typed_method # => [44]
Post reply on HN