70x faster? If Crystal gets its own port of Ruby on Rails, oh boy.
Web server output is roughly 2x as per its home page: https://crystal-lang.org/?utm=source-temp
This A* example is contrived.
From Ruby to Crystal: A Quick Look
21–30 of 44 posts
Re: From Ruby to Crystal: A Quick Look
#22Earlier quoted context omitted.
In fact being similar to or compatible with Ruby is not a language goal at all.
If the goal is not to be similar to Ruby then what makes Crystal better than Rust or Go? I can understand being compatible ith not being a specific goal.
>what makes Crystal better than Rust or Go
Rust is very much a systems programming language: no GC, no runtime, no overhead. We don't intend to compete with Rust at all.
Go however has inspired Crystal's IO system quite a bit. Crystal looked at Go and saw that CSP was working very well and copied the idea.
Here's some differences:
- Go aims for simplicity, in Crystal it's a bit lower down the priority list in favour of expressability
- Crystal has a stronger, more complex type system than Go
- Crystal has type inference
- Crystal has blocks/yield (with 0 overhead) like Ruby
- Crystal has a more "normal" package manager
Re: From Ruby to Crystal: A Quick Look
#23Earlier quoted context omitted.
In fact being similar to or compatible with Ruby is not a language goal at all.
That's communicated very poorly, when the first thing on the website is "fast as C, slick as Ruby" followed by mentioning how similar the syntax is to Ruby.
I'm getting the impression of a running pattern of argument when talking about Crystal:
Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!"
Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is to be similar to Ruby and allow porting more easily?"
Crystalist: "Crystal is not Ruby. Crystal has no goal of being similar to Ruby. Any similarity to other languages is purely coincidental. What's Ruby?"
Re: From Ruby to Crystal: A Quick Look
#24Earlier quoted context omitted.
I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that doesn't depend on rewriting your code nearly as much.
The idea behind crystal is not to make a faster ruby, but to make a rethought ruby for the modern age: compiled, statically typed and removed of warts. Crystal should feel familiar to ruby developers in it's syntax and stdlib, but we have absolutely no problems with throwing away ruby's ideas when they are deemed substandard. Crystal doesn't aim to draw in as many ruby developers as possible, it aims to create the be…
I can understand that, but a lot of the difference to me seem like they make moving code over harder without providing any benefit. For me that makes it substantially less likely that I'll use it, but that's fine.
Re: From Ruby to Crystal: A Quick Look
#25Earlier quoted context omitted.
I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that doesn't depend on rewriting your code nearly as much.
A lot of the differences are based around choosing what is optimal, instead of what is similar to Ruby. Without context, I'd prefer `property` over `attr_accessor`. As for the effect on porting code, it's still very easy to port code. I ported over ActiveSupport's Inflector module(s), and approximately 75% of the code was untouched, 20% was minor tweaks (i.e. single to double quotes), and 5% required actual changing.…
Without context, "attr_accessor" to me appears closer in meaning to what it actually means in Ruby. Maybe it's meaning in Crystal is sufficiently different to make "property" make more sense. In Ruby, after all, it literally creates accessor methods, it does not create a property.
Re: From Ruby to Crystal: A Quick Look
#26Earlier quoted context omitted.
That's communicated very poorly, when the first thing on the website is "fast as C, slick as Ruby" followed by mentioning how similar the syntax is to Ruby.
I'm getting the impression of a running pattern of argument when talking about Crystal: Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!" Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is t…
Yes, it feels a bit like a bait and switch to me. I can understand that - I've been tempted to go down the same route myself... But the messaging around it is all over the place.
On one hand, when they explicitly state that the goal is not for Crystal to be as close to Ruby as possible, that makes me more sympathetic.
At the same time it also makes me less likely to use it anytime soon. Not out of ill will - it's an interesting project and I hope they do well - but hardly any of my Ruby code is CPU constrained, so I have little reason to switch for speed. Had they aimed as close as possible, I might have tried anyway, but every little extra difference makes it less worthwhile.
Of course that's very different for people that actually write code where speed is a major concern and that e.g. haven't been able to use Ruby for that reason.
Re: From Ruby to Crystal: A Quick Look
#27Crystal could be a really powerful tool for enhancing existing Ruby code. Imagine a world where you write your code in Ruby, but farm out the expensive operations to a Ruby-like Crystal extension (similar to what is commonly done with C or Rust). I think this is possible already (just after a quick Google search[1]), just not friendly for the average Ruby dev to implement. [1] https://www.slideshare.net/AnnaKazakova/…
When I look at Crystal, what comes to my mind is that it is what Ruby could have been if the community had taken Dylan as inspiration in regards to language design and tooling.
Re: From Ruby to Crystal: A Quick Look
#28Outside of speed benefits as compared to ruby, one of the main things going for crystal is it's ability to use all of the robust tooling that already exists. This post mentions it in passing but Crystal gets the benefit of all the existing tooling without having to build it as part of delivering the language to developers. I think that's a huge win. I also think this is one reason why Crystal has grown fairly quickly…
Can you be more specific on what you mean about "existing tooling"?. I work in a Ruby shop and am very curious to try Crystal.
Re: From Ruby to Crystal: A Quick Look
#29Earlier quoted context omitted.
That's communicated very poorly, when the first thing on the website is "fast as C, slick as Ruby" followed by mentioning how similar the syntax is to Ruby.
I'm getting the impression of a running pattern of argument when talking about Crystal: Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!" Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is t…
Firstly I'd like to mention that our messaging probably isn't consistent because it doesn't come from only one person. Crystal is a community and we all say slightly different things.
The message we want to get across about the Crystal is that it is very Ruby-inspired, and that Ruby devs will feel at home. Crystal is often compared to Rust and Go, and the level of abstraction you will see when writing Crystal code will feel much more at home compared to Go and especially Rust. That being said, Crystal isn't Ruby, and you'll have more success writing a project from scratch for Crystal than attempting to port any >10k LOC codebase. Crystal isn't designed to make porting Ruby easy, and it hasn't been for a while. Crystal's goal is to make you as a Ruby developer feel at home, not your code. A lot of people have ported codebases from Ruby and talked about it, but you probably see only the successes, not the failures.
In short, we want you to use Crystal not because it's faster and easy to port to, but because it's simply a better, more robust, modern language.
Re: From Ruby to Crystal: A Quick Look
#30Earlier quoted context omitted.
I'm getting the impression of a running pattern of argument when talking about Crystal: Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!" Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is t…
Yes, it feels a bit like a bait and switch to me. I can understand that - I've been tempted to go down the same route myself... But the messaging around it is all over the place. On one hand, when they explicitly state that the goal is not for Crystal to be as close to Ruby as possible, that makes me more sympathetic. At the same time it also makes me less likely to use it anytime soon. Not out of ill will - it's an…
> but hardly any of my Ruby code is CPU constrained,
All of the IO in crystal is async, so even if you're IO bound, crystal is probably a lot more efficient.