5 ms·

Thunderbong with an excellent link! Chris Seaton is one of the most influential programmers out there for me. I'm so interested in just about everything he's t

Thunderbong with an excellent link! Chris Seaton is one of the most influential programmers out there for me. I'm so interested in just about everything he's touched. What a guy. Ruby will never die so long as people have ideas like his, though not all can follow through and create such cool things! I'm curious to see where performant ruby goes in the midst of Crystal. I quite like Ruby for exploring, Pry is an unrivalled repl experience, but then Crystal is very fast and quite efficient for big things. I like the idea of types guiding me amongst a big large codebase that I might not be familiar with. We'll just have to keep hacking and see what happens!

vinceguidry 5y ago
It should be kept in mind that the Ruby ecosystem has quite a bit of depth to it and there are solutions that have been around for quite some time to make it useful in places you wouldn't ordinarily think to. The performance issue has many angles to it. There are lots of different ways to extend Ruby with code in other languages such as C or Rust, there's DragonRuby if you wanna make games, you can run Ruby on the JVM, JRuby and nowadays TruffleRuby, there's even a slimmed-down Ruby suitable for use in embedded contexts, mruby, which is what I replaced all of my Crystal code with. (if you go this route, the best way I've found is to compile your own mruby with whatever you want in it, and put a #!/path/to/mruby shebang at the top of your scripts. Compile if you need even more perf, I found JITted mruby to be more than sufficient.) Crystal isn't a bad language, but the only thing it shares with Ruby is a small subset of syntax. It's sorely lacking in maturity and in libraries and tools. It's unfortunate because Crystal is an idea worth exploring, but its proximity to Ruby means people will always position it against Ruby, and it will always fall short. And with types now in Ruby that's one less reason to pick Crystal over Ruby.
- colesantiago 5y ago
  Wasn't Rust also lacking libraries as well? Example: Last time I checked couldn't find a firebase library for Rust, so gave up on it. Rust seems a bit immature in the library department no? But didn't stop it becoming popular. I bet Crystal will do the same.
  - bombless 5y ago
    Do you mean this firebase? https://crates.io/crates/google-firebase1_beta1 https://crates.io/crates/google-firebase1_beta1
  - vinceguidry 5y ago
    Crystal's is about a year older than Rust. If it was going to get popular it would have by now.
    - ksec 5y ago
      >Crystal's is about a year older than Rust. If it was going to get popular it would have by now. You mean at least a year younger ? Rust >The language grew out of a personal project begun in 2006 by Mozilla employee Graydon Hoare,[18] who stated that the project was possibly named after the rust family of fungi.[29] Mozilla began sponsoring the project in 2009[18] and announced it in 2010. Crystal >Work on the language began in June 2011
      - vinceguidry 5y ago
        I guess. It probably would have been better to say they're about the same age. I went by Rust's first pre-alpha release, maybe I should have used an earlier event.
- multiplegeorges 5y ago
  > And with types now in Ruby that's one less reason to pick Crystal over Ruby. The story around types in Ruby is very early. There are "competing" ways to do it and they are really not dev ergonomic. I think Ruby has a loooong way to go with typing to take it off the list of things to use Crystal for.
  - vinceguidry 5y ago
    It's not really. The earliest type system for Ruby as far as I can recall is sorbet, and it's been around since at least 2017.
    - chrisseaton 5y ago
      Type systems for Ruby go back to at least 2007 https://rubybib.org/#madsen2007 https://rubybib.org/#madsen2007
pizza234 5y ago
> I'm curious to see where performant ruby goes in the midst of Crystal Crystal is a statically typed language, so the traditional performance considerations about static <> dynamic languages apply. AFAIK Ruby is also particularly hard to optimize, due to its very dynamic nature (pretty much every concept can be changed at runtime). > Crystal is very fast and quite efficient for big things It can'be currently said "very fast" about such a young language; it will depend on how much manpower will be put it in the long term. Parallelism is not even yet stable, which is a considerable factor. I personally think it as a pleasant language to write small tools/scripts. If parallelism would have been implemented from day 1, I would have actually used it.
- michaelcampbell 5y ago
  I don't see the age of language at all relevant to how many ops/s or whatever other measure of speed you want to use it has. It's either faster than what you consider "very fast", or it is not; how long the language has been around is, IMO, a complete non-sequitur. That it can be made, possibly, much faster than it is I guess can probably weigh in here, but that's not what they were talking about.
LAC-Tech 5y ago
Ruby 3 is like 10x faster than it was in 1.8.7 when I started using it. That still doesn't make it a speed demon. But it does make it 'fast enough' for me.
- cutler 5y ago
  With all this negativity about Ruby's speed it's easily forgotten that Ruby is as fast as Python for most tasks with the exception of some numeric libraries which are really just C extensions. They are both interpreted languages and that hasn't stopped Python from dominating the world of programming.

vinceguidry 5y ago

It should be kept in mind that the Ruby ecosystem has quite a bit of depth to it and there are solutions that have been around for quite some time to make it useful in places you wouldn't ordinarily think to. The performance issue has many angles to it. There are lots of different ways to extend Ruby with code in other languages such as C or Rust, there's DragonRuby if you wanna make games, you can run Ruby on the JVM, JRuby and nowadays TruffleRuby, there's even a slimmed-down Ruby suitable for use in embedded contexts, mruby, which is what I replaced all of my Crystal code with. (if you go this route, the best way I've found is to compile your own mruby with whatever you want in it, and put a #!/path/to/mruby shebang at the top of your scripts. Compile if you need even more perf, I found JITted mruby to be more than sufficient.) Crystal isn't a bad language, but the only thing it shares with Ruby is a small subset of syntax. It's sorely lacking in maturity and in libraries and tools. It's unfortunate because Crystal is an idea worth exploring, but its proximity to Ruby means people will always position it against Ruby, and it will always fall short. And with types now in Ruby that's one less reason to pick Crystal over Ruby.

colesantiago 5y ago
Wasn't Rust also lacking libraries as well? Example: Last time I checked couldn't find a firebase library for Rust, so gave up on it. Rust seems a bit immature in the library department no? But didn't stop it becoming popular. I bet Crystal will do the same.
- bombless 5y ago
  Do you mean this firebase? https://crates.io/crates/google-firebase1_beta1 https://crates.io/crates/google-firebase1_beta1
- vinceguidry 5y ago
  Crystal's is about a year older than Rust. If it was going to get popular it would have by now.
  - ksec 5y ago
    >Crystal's is about a year older than Rust. If it was going to get popular it would have by now. You mean at least a year younger ? Rust >The language grew out of a personal project begun in 2006 by Mozilla employee Graydon Hoare,[18] who stated that the project was possibly named after the rust family of fungi.[29] Mozilla began sponsoring the project in 2009[18] and announced it in 2010. Crystal >Work on the language began in June 2011
    - vinceguidry 5y ago
      I guess. It probably would have been better to say they're about the same age. I went by Rust's first pre-alpha release, maybe I should have used an earlier event.
multiplegeorges 5y ago
> And with types now in Ruby that's one less reason to pick Crystal over Ruby. The story around types in Ruby is very early. There are "competing" ways to do it and they are really not dev ergonomic. I think Ruby has a loooong way to go with typing to take it off the list of things to use Crystal for.
- vinceguidry 5y ago
  It's not really. The earliest type system for Ruby as far as I can recall is sorbet, and it's been around since at least 2017.
  - chrisseaton 5y ago
    Type systems for Ruby go back to at least 2007 https://rubybib.org/#madsen2007 https://rubybib.org/#madsen2007

pizza234 5y ago

> I'm curious to see where performant ruby goes in the midst of Crystal Crystal is a statically typed language, so the traditional performance considerations about static <> dynamic languages apply. AFAIK Ruby is also particularly hard to optimize, due to its very dynamic nature (pretty much every concept can be changed at runtime). > Crystal is very fast and quite efficient for big things It can'be currently said "very fast" about such a young language; it will depend on how much manpower will be put it in the long term. Parallelism is not even yet stable, which is a considerable factor. I personally think it as a pleasant language to write small tools/scripts. If parallelism would have been implemented from day 1, I would have actually used it.

michaelcampbell 5y ago
I don't see the age of language at all relevant to how many ops/s or whatever other measure of speed you want to use it has. It's either faster than what you consider "very fast", or it is not; how long the language has been around is, IMO, a complete non-sequitur. That it can be made, possibly, much faster than it is I guess can probably weigh in here, but that's not what they were talking about.

LAC-Tech 5y ago

Ruby 3 is like 10x faster than it was in 1.8.7 when I started using it. That still doesn't make it a speed demon. But it does make it 'fast enough' for me.

cutler 5y ago
With all this negativity about Ruby's speed it's easily forgotten that Ruby is as fast as Python for most tasks with the exception of some numeric libraries which are really just C extensions. They are both interpreted languages and that hasn't stopped Python from dominating the world of programming.