7 ms·

The future of the Crystal language

122 points by cylo 11y ago

13of40 11y ago
> Note that the above “if” starts with “if instance variables types remain the same”. But how can we know that? The problem is that the compiler determines their > type by traversing the program, instantiating methods, and checking what gets assigned to them. So we can’t really reuse the cache because we can’t know the final > types until we type the whole program! It’s a chicken and egg problem." Maybe I'm oversimplifying it, but suppose you compiled a statement like... a++ ...into something like... if a is an integer (which would presumably be something fast like "CMP [RAX],123; JNZ NotAnInteger") do "INC [RAX+8]", otherwise do more expensive stuff to look up the actual type and a function to use as a ++ operator? As long as the programmer sticks to the same type, the compiled expression runs fast, and if they switch types midstream, it still runs, albeit with a performance hit.
- tekacs 11y ago
  You might be interested in deoptimisation: :) http://chrisseaton.com/rubytruffle/deoptimizing/ http://chrisseaton.com/rubytruffle/deoptimizing/ This would have the effect that you describe (actually even faster than what you're proposing, by essentially trapping on all changes to the target to know ahead of time that deoptimisation has to occur), but it's not the world's most trivial feature to implement.
- PeCaN 11y ago
  That's what a lot of JIT compilers do. SpiderMonkey for example does type inference in the interpreter (or baseline JIT? what do they use now) and uses that to generate almost exactly what you're describing. If the type inference holds (it usually does, even in dynamic languages) then you get almost native performance.
- mvitorino 11y ago
  Don't really know Crystal but it seems to me that it is statically compiled which means you need to find the type of 'a' at compile time. The approach you suggest is more commonly used in dynamic languages and involves keeping at runtime a tag on every single value that indicates it's type (memory and speed overhead). You would be trading compile time with run time. Also it seems that not only it is statically compiled, it produces a static binary in the target platform. If, like others suggest in this thread, you were to optimize at runtime instead of generating the alternate paths, you would need a bytecode representation of the program embedded in the executable and very likely a virtual machine with the optimiser and capability to hot reload code. Any of these options would be a substantial departure of the current path the language is taking.
- asterite 11y ago
  We mostly want to never have to do this. This way we can guarantee that "no method error" never happens at runtime (one of the most feared exceptions after a big refactor in a dynamically typed language)
69_years_and 11y ago
Only just had a quick peep and play and I like it - looking forward to using Crystal more often on a tooling level. Nice work to date...
dutchbrit 11y ago
Taken from Github on the "why?" We love Ruby's efficiency for writing code. We love C's efficiency for running code. We want the best of both worlds. We want the compiler to understand what we mean without having to specify types everywhere. We want full OOP.
- davexunit 11y ago
  >We love Ruby's efficiency for writing code. Ruby's syntax is one of the worst parts of Ruby. [0] >We love C's efficiency for running code. Many other languages have efficient native code compilers, too. I don't know why people assume this is only a C thing. >We want the best of both worlds. >We want the compiler to understand what we mean without having to specify types everywhere. This is good. I much prefer dynamic languages to static ones. Though I don't know if Crystal supports the best parts of dynamic languages like runtime program modification AKA live coding. >We want full OOP. Single paradigm languages feel very restrictive to me. I like languages that support many paradigms because different parts of programs call for different programming techniques. OOP in particular is a paradigm that I feel forced to use more often than I feel it's the right technique for the task at hand. [0] http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...
  - hellofunk 11y ago
    The question is not whether the language has a native code compiler, as that rarely has a profound effect on the runtime speed of a language. Some native code languages are slower than VM and interpreted languages. And native code != native code. Objective-C and Swift both have native code compilers. But they are slower than C and C++ on the same platforms, for various reasons, such as: the runtime environment itself and how the runtime works, and, in the case of Swift, the organization of its LLVM code prior to final compilation.
  - arnvald 11y ago
    > Many other languages have efficient native code compilers, too. I don't know why people assume this is only a C thing. I think it's just become very common to show C as the reference to show how fast are other programming languages, and everyone keeps it this way. > Ruby's syntax is one of the worst parts of Ruby. [0] For people who write the language, yes, it's incredibly hard to parse (and that blog post doesn't mention the new ambiguous things like keywords vs. hashes) Yet, for people who use Ruby, it's very convenient and easy to read.
0xFFC 11y ago
I don't know it is only me or its apply to others too, My own field is OS and I love it. But recently I am literally fascinated by whats going on in "Programming Language" field. Rust, Go, Nim, Julia, Haskell, Ocaml, Racket, Clojure etc (though these are not scientific research in PL community, but we can claim these are mostly result of scientific research). I wasn't aware of crystal . I literally Love them all and if I were going to an abandoned island for rest of my life , my only wish would have been : "let me play with all of these for rest of my life" BTW : I looked at crystal syntax (I am talking about only syntax). Syntax designed extremely clear. I would say (my opinion, in short time I had to investigate crystal) maybe clear'er that python.
vinceguidry 11y ago
The real reason they couldn't find anything when Googling the language in the future is because of the inconvenient naming. Every time I search for Crystal, I have to pick out the results from SAP Crystal Reports. I wish more people took this aspect of their projects seriously. You don't need a short domain name, but your project does at least need to be Googlable.
- sanxiyn 11y ago
  I agree, but I note some of this is out of your control. Rust used to be very clean wrt Google, and then Rust the game was released in 2014.
- arnvald 11y ago
  It's the same with other languages as well: Go, Julia, Ruby (when I searched for some "Ruby Bangkok" meetups, I found thousands of offers to buy real rubies in Thailand. Same with frameworks: Phoenix, Sinatra, Iron, Gin. After some time Google learns and shows you relevant results, but if you use Startpage or DuckDuckGo, you have to add "lang" or "framework" to search query
  - fao_ 11y ago
    C is by far the worst... Side Note: In DDG Lua doesn't need 'lang', you can type in a function name and it'll give you documentation in the 'instant answers' thing.
- sdogruyol 11y ago
  You can use #crystallang
- thomasfl 11y ago
  Google seems to know that when I am searching for ruby, I want it to rank the programming language first. In due time it will know that by crystal I mean the programming language.
- stefantalpalaru 11y ago
  Search for "crystal language" instead.
sdogruyol 11y ago
If you're a web dev and want to build an API be sure to check out Kemal: http://serdardogruyol.com/kemal/ http://serdardogruyol.com/kemal/
- tremendo 11y ago
  a Sinatra for Crystal. Wonderful. Now if there is a Sequel equivalent… I'll be sold.
thomasfl 11y ago
If I had to optimize parts of a ruby project, I think it would be much better to port the code to crystal than C or Go.

122 points by cylo 11y ago

> Note that the above “if” starts with “if instance variables types remain the same”. But how can we know that? The problem is that the compiler determines their > type by traversing the program, instantiating methods, and checking what gets assigned to them. So we can’t really reuse the cache because we can’t know the final > types until we type the whole program! It’s a chicken and egg problem." Maybe I'm oversimplifying it, but suppose you compiled a statement like... a++ ...into something like... if a is an integer (which would presumably be something fast like "CMP [RAX],123; JNZ NotAnInteger") do "INC [RAX+8]", otherwise do more expensive stuff to look up the actual type and a function to use as a ++ operator? As long as the programmer sticks to the same type, the compiled expression runs fast, and if they switch types midstream, it still runs, albeit with a performance hit.

tekacs 11y ago
You might be interested in deoptimisation: :) http://chrisseaton.com/rubytruffle/deoptimizing/ http://chrisseaton.com/rubytruffle/deoptimizing/ This would have the effect that you describe (actually even faster than what you're proposing, by essentially trapping on all changes to the target to know ahead of time that deoptimisation has to occur), but it's not the world's most trivial feature to implement.
PeCaN 11y ago
That's what a lot of JIT compilers do. SpiderMonkey for example does type inference in the interpreter (or baseline JIT? what do they use now) and uses that to generate almost exactly what you're describing. If the type inference holds (it usually does, even in dynamic languages) then you get almost native performance.
mvitorino 11y ago
Don't really know Crystal but it seems to me that it is statically compiled which means you need to find the type of 'a' at compile time. The approach you suggest is more commonly used in dynamic languages and involves keeping at runtime a tag on every single value that indicates it's type (memory and speed overhead). You would be trading compile time with run time. Also it seems that not only it is statically compiled, it produces a static binary in the target platform. If, like others suggest in this thread, you were to optimize at runtime instead of generating the alternate paths, you would need a bytecode representation of the program embedded in the executable and very likely a virtual machine with the optimiser and capability to hot reload code. Any of these options would be a substantial departure of the current path the language is taking.
asterite 11y ago
We mostly want to never have to do this. This way we can guarantee that "no method error" never happens at runtime (one of the most feared exceptions after a big refactor in a dynamically typed language)

69_years_and 11y ago

Only just had a quick peep and play and I like it - looking forward to using Crystal more often on a tooling level. Nice work to date...

dutchbrit 11y ago

Taken from Github on the "why?" We love Ruby's efficiency for writing code. We love C's efficiency for running code. We want the best of both worlds. We want the compiler to understand what we mean without having to specify types everywhere. We want full OOP.

davexunit 11y ago
>We love Ruby's efficiency for writing code. Ruby's syntax is one of the worst parts of Ruby. [0] >We love C's efficiency for running code. Many other languages have efficient native code compilers, too. I don't know why people assume this is only a C thing. >We want the best of both worlds. >We want the compiler to understand what we mean without having to specify types everywhere. This is good. I much prefer dynamic languages to static ones. Though I don't know if Crystal supports the best parts of dynamic languages like runtime program modification AKA live coding. >We want full OOP. Single paradigm languages feel very restrictive to me. I like languages that support many paradigms because different parts of programs call for different programming techniques. OOP in particular is a paradigm that I feel forced to use more often than I feel it's the right technique for the task at hand. [0] http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...
- hellofunk 11y ago
  The question is not whether the language has a native code compiler, as that rarely has a profound effect on the runtime speed of a language. Some native code languages are slower than VM and interpreted languages. And native code != native code. Objective-C and Swift both have native code compilers. But they are slower than C and C++ on the same platforms, for various reasons, such as: the runtime environment itself and how the runtime works, and, in the case of Swift, the organization of its LLVM code prior to final compilation.
- arnvald 11y ago
  > Many other languages have efficient native code compilers, too. I don't know why people assume this is only a C thing. I think it's just become very common to show C as the reference to show how fast are other programming languages, and everyone keeps it this way. > Ruby's syntax is one of the worst parts of Ruby. [0] For people who write the language, yes, it's incredibly hard to parse (and that blog post doesn't mention the new ambiguous things like keywords vs. hashes) Yet, for people who use Ruby, it's very convenient and easy to read.

0xFFC 11y ago

I don't know it is only me or its apply to others too, My own field is OS and I love it. But recently I am literally fascinated by whats going on in "Programming Language" field. Rust, Go, Nim, Julia, Haskell, Ocaml, Racket, Clojure etc (though these are not scientific research in PL community, but we can claim these are mostly result of scientific research). I wasn't aware of crystal . I literally Love them all and if I were going to an abandoned island for rest of my life , my only wish would have been : "let me play with all of these for rest of my life" BTW : I looked at crystal syntax (I am talking about only syntax). Syntax designed extremely clear. I would say (my opinion, in short time I had to investigate crystal) maybe clear'er that python.

vinceguidry 11y ago

The real reason they couldn't find anything when Googling the language in the future is because of the inconvenient naming. Every time I search for Crystal, I have to pick out the results from SAP Crystal Reports. I wish more people took this aspect of their projects seriously. You don't need a short domain name, but your project does at least need to be Googlable.

sanxiyn 11y ago
I agree, but I note some of this is out of your control. Rust used to be very clean wrt Google, and then Rust the game was released in 2014.
arnvald 11y ago
It's the same with other languages as well: Go, Julia, Ruby (when I searched for some "Ruby Bangkok" meetups, I found thousands of offers to buy real rubies in Thailand. Same with frameworks: Phoenix, Sinatra, Iron, Gin. After some time Google learns and shows you relevant results, but if you use Startpage or DuckDuckGo, you have to add "lang" or "framework" to search query
- fao_ 11y ago
  C is by far the worst... Side Note: In DDG Lua doesn't need 'lang', you can type in a function name and it'll give you documentation in the 'instant answers' thing.
sdogruyol 11y ago
You can use #crystallang
thomasfl 11y ago
Google seems to know that when I am searching for ruby, I want it to rank the programming language first. In due time it will know that by crystal I mean the programming language.
stefantalpalaru 11y ago
Search for "crystal language" instead.

sdogruyol 11y ago

If you're a web dev and want to build an API be sure to check out Kemal: http://serdardogruyol.com/kemal/ http://serdardogruyol.com/kemal/

tremendo 11y ago
a Sinatra for Crystal. Wonderful. Now if there is a Sequel equivalent… I'll be sold.

thomasfl 11y ago

If I had to optimize parts of a ruby project, I think it would be much better to port the code to crystal than C or Go.