3 ms·

I recently ported a fairly simple ruby project to crystal, and am happy with the result. I'm now writing another smallish project in crystal, and finding it qu

I recently ported a fairly simple ruby project to crystal, and am happy with the result. I'm now writing another smallish project in crystal, and finding it quite productive. I like the syntax and language features of ruby, but I prefer static typing... so it's a nice addition. I'm glad to see crystal has momentum.

lbotos 8y ago
Did a quick search but I wasn't able to find anything on the site: - Goals of Crystal over say Ruby? Speed? Safety? - What drew you to try it?
- bhaak 8y ago
  On https://crystal-lang.org/ https://crystal-lang.org/ "Fast as C, slick as Ruby". There's a list on https://crystal-lang.org/docs/ https://crystal-lang.org/docs/ that is less tongue in cheek.
  - aerovistae 8y ago
    Is it actually as fast as C? That seems like quite a claim.
    - 3rdAccount 8y ago
      It uses LLVM like Swift, Rust, & Julia. I'm not sure if it can beat highly optimized C code, but generally is in the neighborhood of C, while letting you code like a rubyist. This is similar to how Nim lets you write code similar to Python and it then transpiles to C or C++ code to be compiled by gcc or Js to be run in the browser.
    - coldtea 8y ago
      Any statically typed language that doesn't do anything really stupid will be as fast as C when using the same backend (LLVM here) and the same type of coding (e.g. not taking into advantage high level libs that abstract everything, but doing regular stuff like loops, bit mangling, string processing, etc). Pascal, Rust, ADA, and lots of others all are (or can be, when programmed properly with comparable constructs) "as fast as C" (and in some cases, e.g. when avoiding aliasing issues) faster.
    - RX14 8y ago
      It's fast as C in the same way Java and Go are as fast as C. To put it in more concrete terms, it's worst cases on the same order of magnitude as C at least for non-specialized usecases. Whereas dynamic languages are usually many orders of magnitude slower. Comparing "the speed of languages" is largely bullshit and you need to be comparing a specific problem. Crystal certainly has the genes required to be as fast as Go, and I think very few people are unhappy with Go's performance. Currently the major difference between Crystal and Go's single-threaded performance is the GC and thats not too bad. Parallelism is coming soon. You could say that Crystal and Go (by default) is faster than C (by default) for IO bound workflows because of how IO is handled in Crystal and Go. But most people look at micro-benchmarks which don't reflect the difficulty of achieving C's performance in C.
    - petre 8y ago
      My Crystal test code with primes managed to run 4x faster than the D version and 1.15x faster then the Go version when built with the --release switch, but when I ran it up to 100k it filled up all my 8GB of memory and started swapping. The D and Go versions run fine up to 100k without any issues and without filling up the memory. Running it up to 100k probably also causes integer overflow and I couldn't make the range iterations work with uint64 as I'm not quite familiar with the language. Crystal https://p.thorsen.pm/f4b376d71d1a https://p.thorsen.pm/f4b376d71d1a Dlang https://p.thorsen.pm/f5f7d6b09480 https://p.thorsen.pm/f5f7d6b09480 Golang https://p.thorsen.pm/369b79e836a8 https://p.thorsen.pm/369b79e836a8
      - sam0x17 8y ago
        You should definitely consider using Set(Int32) instead of Hash(Int32, Bool). Not sure why it is using so much RAM but I strongly encourage you to submit this as an issue on the crystal lang github.
        petre 8y ago
        The problem is that not all the languages tested have a Set type. This is why all the implementations use a Hash or map or associative array type, which are roughly the same thing. Othwerwise we are comparing apples with oranges. I also refuse to use anything which is not included in the standard library. The program does really basic stuff, so all of its building blocks should be in the core language. This is why the Rust implementation is slower than D or Go - because it uses HashMap which is slower than D's associative arrays or Go's maps.
        petre 8y ago
        I reported it and it turns out that the integer overflow generated the memory consumption issue. After modifying the code it's speed is par with Go.
    - pjmlp 8y ago
      Remember C compilers used to generate pretty crappy code, it took them a couple of years to improve. Same applies to any other language.

lbotos 8y ago

Did a quick search but I wasn't able to find anything on the site: - Goals of Crystal over say Ruby? Speed? Safety? - What drew you to try it?

bhaak 8y ago
On https://crystal-lang.org/ https://crystal-lang.org/ "Fast as C, slick as Ruby". There's a list on https://crystal-lang.org/docs/ https://crystal-lang.org/docs/ that is less tongue in cheek.
- aerovistae 8y ago
  Is it actually as fast as C? That seems like quite a claim.
  - 3rdAccount 8y ago
    It uses LLVM like Swift, Rust, & Julia. I'm not sure if it can beat highly optimized C code, but generally is in the neighborhood of C, while letting you code like a rubyist. This is similar to how Nim lets you write code similar to Python and it then transpiles to C or C++ code to be compiled by gcc or Js to be run in the browser.
  - coldtea 8y ago
    Any statically typed language that doesn't do anything really stupid will be as fast as C when using the same backend (LLVM here) and the same type of coding (e.g. not taking into advantage high level libs that abstract everything, but doing regular stuff like loops, bit mangling, string processing, etc). Pascal, Rust, ADA, and lots of others all are (or can be, when programmed properly with comparable constructs) "as fast as C" (and in some cases, e.g. when avoiding aliasing issues) faster.
  - RX14 8y ago
    It's fast as C in the same way Java and Go are as fast as C. To put it in more concrete terms, it's worst cases on the same order of magnitude as C at least for non-specialized usecases. Whereas dynamic languages are usually many orders of magnitude slower. Comparing "the speed of languages" is largely bullshit and you need to be comparing a specific problem. Crystal certainly has the genes required to be as fast as Go, and I think very few people are unhappy with Go's performance. Currently the major difference between Crystal and Go's single-threaded performance is the GC and thats not too bad. Parallelism is coming soon. You could say that Crystal and Go (by default) is faster than C (by default) for IO bound workflows because of how IO is handled in Crystal and Go. But most people look at micro-benchmarks which don't reflect the difficulty of achieving C's performance in C.
  - petre 8y ago
    My Crystal test code with primes managed to run 4x faster than the D version and 1.15x faster then the Go version when built with the --release switch, but when I ran it up to 100k it filled up all my 8GB of memory and started swapping. The D and Go versions run fine up to 100k without any issues and without filling up the memory. Running it up to 100k probably also causes integer overflow and I couldn't make the range iterations work with uint64 as I'm not quite familiar with the language. Crystal https://p.thorsen.pm/f4b376d71d1a https://p.thorsen.pm/f4b376d71d1a Dlang https://p.thorsen.pm/f5f7d6b09480 https://p.thorsen.pm/f5f7d6b09480 Golang https://p.thorsen.pm/369b79e836a8 https://p.thorsen.pm/369b79e836a8
    - sam0x17 8y ago
      You should definitely consider using Set(Int32) instead of Hash(Int32, Bool). Not sure why it is using so much RAM but I strongly encourage you to submit this as an issue on the crystal lang github.
      - petre 8y ago
        The problem is that not all the languages tested have a Set type. This is why all the implementations use a Hash or map or associative array type, which are roughly the same thing. Othwerwise we are comparing apples with oranges. I also refuse to use anything which is not included in the standard library. The program does really basic stuff, so all of its building blocks should be in the core language. This is why the Rust implementation is slower than D or Go - because it uses HashMap which is slower than D's associative arrays or Go's maps.
      - petre 8y ago
        I reported it and it turns out that the integer overflow generated the memory consumption issue. After modifying the code it's speed is par with Go.
  - pjmlp 8y ago
    Remember C compilers used to generate pretty crappy code, it took them a couple of years to improve. Same applies to any other language.