Crystal for Rubyists(crystalforrubyists.com)
crystalforrubyists.com
Crystal for Rubyists
https://www.crystalforrubyists.com/
93 comments
I pretty much love C++ and would give up my career to be able to work with it again. Especially that feeling of squishing millions of lines of data in milliseconds by running the compiled code. It is pure delight. C did make me pretty miserable, though.
> Perl and C++ made me miserable
You compare to rather new, and "geared to learners", languages to some old and know-to-be-arcane languages.
I'd be curious what you think of, for instance, Kotlin and Elm.
You compare to rather new, and "geared to learners", languages to some old and know-to-be-arcane languages.
I'd be curious what you think of, for instance, Kotlin and Elm.
And Elixir :)
I feel that's pretty close to Ruby and Crystal. I was actually hoping for something more out of line (like C++ and Perl) but more modern.
I enjoy Elixir a lot but it feels like a tool designed for a whole different purpose. I don’t really know what that purpose it. It’s possible that my brain is just not well organized for the way elixir is laid out, but Crystal is so fluid with my brain.
It's quite easy for me to churn out some data munging scripts using Ruby but I was running into performance issues on large csv files. Crystal is like having super powers for csv parsing if you already have Ruby skills. I really think it's the sweet spot for the language.
This is great Serdar.
As an alternative to Chapter 2 I’ll also share https://github.com/compumike/crystal-docker-quickstart my project template which lets you get a Crystal (currently 1.6.2) dev environment running with just Docker. Good for kicking the tires, which is what I think your audience is probably wanting to do! And then eventually can install a binary package as you suggest.
As an alternative to Chapter 2 I’ll also share https://github.com/compumike/crystal-docker-quickstart my project template which lets you get a Crystal (currently 1.6.2) dev environment running with just Docker. Good for kicking the tires, which is what I think your audience is probably wanting to do! And then eventually can install a binary package as you suggest.
Thanks a lot! Happy to have your PR :) https://github.com/sdogruyol/crystal-for-rubyists-en
Nice! It doesn't work in Windows native, right? Asking because newbies might come from there (although I bet most of them use WSL).
It’s getting pretty close.
Windows status: https://github.com/crystal-lang/crystal/issues/5430
Windows status: https://github.com/crystal-lang/crystal/issues/5430
Hmm I don’t know — I don’t have a Windows or WSL setup to test with right now. What breaks?
Crystal is a lovely language. The language community is small though, and learning resources are also small. The story for Crystal is the same story for many programming languages: grow the interest of users, and find generous funding.
My impression is that not many Ruby programmers have switched to Crystal. The slow(ish) Crystal compilation will not please Ruby users. And Crystal for Windows is still in beta.
Despite these factors, Crystal is a pleasure to use - fast, readable, and a well-featured standard libary.
My impression is that not many Ruby programmers have switched to Crystal. The slow(ish) Crystal compilation will not please Ruby users. And Crystal for Windows is still in beta.
Despite these factors, Crystal is a pleasure to use - fast, readable, and a well-featured standard libary.
> The slow(ish) Crystal compilation will not please Ruby users
I don't know what's the general opinion, but distribution for dynamic languages is a nightmare (and I'm including intra-machine, ie. switching between environments).
Personally, I'd be thrilled to trade off speed of compilation for distribution simplicity!
> My impression is that not many Ruby programmers have switched to Crystal.
This depends on the context of moving - professional projects, or hobby programming. Every once in a while somebody pops up saying that they've switched for hobby projects (mostly, scripts).
I'd love to switch, also professionally (that is, for certain parts of my professional project), however, lack of (release quality) parallelism is a dealbraker for me. It's mostly a matter of long-term trust - I personally don't trust a programming language that in 2022 doesn't support parallelism. Ironically, Ruby now has it (even if in limited form).
Development of 3d party libraries are also in vicious circle (few libraries -> few devs -> few libraries). Lack of (release quality) AWS SDK, for starters, is a dealbreaker.
I don't know what's the general opinion, but distribution for dynamic languages is a nightmare (and I'm including intra-machine, ie. switching between environments).
Personally, I'd be thrilled to trade off speed of compilation for distribution simplicity!
> My impression is that not many Ruby programmers have switched to Crystal.
This depends on the context of moving - professional projects, or hobby programming. Every once in a while somebody pops up saying that they've switched for hobby projects (mostly, scripts).
I'd love to switch, also professionally (that is, for certain parts of my professional project), however, lack of (release quality) parallelism is a dealbraker for me. It's mostly a matter of long-term trust - I personally don't trust a programming language that in 2022 doesn't support parallelism. Ironically, Ruby now has it (even if in limited form).
Development of 3d party libraries are also in vicious circle (few libraries -> few devs -> few libraries). Lack of (release quality) AWS SDK, for starters, is a dealbreaker.
> Personally, I'd be thrilled to trade off speed of compilation for distribution simplicity!
Technologies like Docker have made distribution a lot easier. I haven't used tools like chruby or rbenv since 2014 when I started using Docker because Docker manages your app's runtime environment. You pull down your built image on your server and run it. There's no complication, sprawling of version managers or surprises.
Personally I think having a fast dev feedback loop is critically important. It's something you experience hundreds of times a day as you're developing your project.
Technologies like Docker have made distribution a lot easier. I haven't used tools like chruby or rbenv since 2014 when I started using Docker because Docker manages your app's runtime environment. You pull down your built image on your server and run it. There's no complication, sprawling of version managers or surprises.
Personally I think having a fast dev feedback loop is critically important. It's something you experience hundreds of times a day as you're developing your project.
With static typing and analysis in the editor there’s no reason to run the code for every second line you write.
I usually only need to run it a few times towards the end of writing a feature to see if the compiler or specs catches any errors.
I usually only need to run it a few times towards the end of writing a feature to see if the compiler or specs catches any errors.
If you're building web apps chances are you want to see your changes frequently since modifying a model, controller action or view may yield a different UI state.
I'm constantly editing code then directing my attention to my browser to see the results. This is independent of CSS or JS changes that might be picked up by asset watching tools like esbuild or tailwind's CLI tool.
I'm constantly editing code then directing my attention to my browser to see the results. This is independent of CSS or JS changes that might be picked up by asset watching tools like esbuild or tailwind's CLI tool.
Fair enough, I build json rest apis in Crystal, then someone else does the js/css front end.
> distribution for dynamic languages is a nightmare
Weird statement. Software distribution generally is just a terrible mess, regardless of what sort of language it's written in. The one exception is JS, which happens to be dynamic and also has what is probably the most reliable and ubiquitous platform available—so much so that its distribution story is often credited, rightly or wrongly, as the only reason anyone actually uses it.
Weird statement. Software distribution generally is just a terrible mess, regardless of what sort of language it's written in. The one exception is JS, which happens to be dynamic and also has what is probably the most reliable and ubiquitous platform available—so much so that its distribution story is often credited, rightly or wrongly, as the only reason anyone actually uses it.
There are very significant differences between distributing programs in a static vs. dynamic language.
Github's Hub tool is a good example.
It was originally written in Ruby. This requires that the user:
- may need to handle a certain environment in terms of Ruby interpreter (potentially install a new version)
- may need to handle a certain libraries group (gemsets in RVM)
- needs to install dependencies
- needs to handle switching to the appropriate Ruby interpreter version and libraries group
Especially point 3 is a pain.
Even just installing everything as system Ruby won't work, because often, different Ruby interpreter versions are required.
Once they moved to Golang:
- the distributor compiles for different platforms
- the user downloads the given version for their O/S
That's all.
Github's Hub tool is a good example.
It was originally written in Ruby. This requires that the user:
- may need to handle a certain environment in terms of Ruby interpreter (potentially install a new version)
- may need to handle a certain libraries group (gemsets in RVM)
- needs to install dependencies
- needs to handle switching to the appropriate Ruby interpreter version and libraries group
Especially point 3 is a pain.
Even just installing everything as system Ruby won't work, because often, different Ruby interpreter versions are required.
Once they moved to Golang:
- the distributor compiles for different platforms
- the user downloads the given version for their O/S
That's all.
I wouldn't shrug my shoulders at
>> the distributor compiles for different platforms
Most people aren't doing that for you. There are lots of tools out there where you do need to still manually compile it yourself and make sure you have the appropriate dependencies which will still be painful. That being said, I agree that shipping a script can be a problem, but lots of people use Brew and that seems to work ok.
>> the distributor compiles for different platforms
Most people aren't doing that for you. There are lots of tools out there where you do need to still manually compile it yourself and make sure you have the appropriate dependencies which will still be painful. That being said, I agree that shipping a script can be a problem, but lots of people use Brew and that seems to work ok.
Okay. Sounds like you're on the road to a convincing argument against Ruby. (I myself have avoided Ruby in the past for similar reasons, despite other things about it that are attractive.) And gesturing towards Golang is really just highlighting a conscious design decision by the Golang team—who didn't have to design it as a static language in order to achieve the same effect; they're orthogonal issues.
Where does the generalization to dynamic vs. static languages come from?
> Github's Hub tool is a good example.
I gave an example already (a counterexample, that is—JS). Was there something wrong with that?
Where does the generalization to dynamic vs. static languages come from?
> Github's Hub tool is a good example.
I gave an example already (a counterexample, that is—JS). Was there something wrong with that?
Yes, there something wrong with it, because the distribution of the runtime is done via binaries i.e. browsers. Using Go or Crystal is mimicking that level of ease. Ruby, or JS (which is more of a mess than Ruby even though the runtime is already distributed) are still a pain to share. No credit goes to the JS distribution system(s) nor the form that the code itself is distributed in for the most difficult bit being done by browser vendors bundling the runtime.
This another weird comment—for different reasons compared to the original. There are several statements where the truth status of the claims are hard to ascertain, because the statements they're part of are incomprehensible. The claims in the statements that are comprehensible are untrue.
One minor note:
Crystal achieved basic Windows support as of 2021/11/18. https://github.com/crystal-lang/crystal/issues/5430
As of Crystal 1.5.0, Windows support is basically there. https://crystal-lang.org/2022/07/06/1.5.0-released.html
However, Crystal aims to support the lowest common denominator between POSIX and Windows, so not all of the Windows standard APIs are supported out-of-the-box. Other Windows specific libraries will need to be created specifically for Windows users/developers.
Crystal achieved basic Windows support as of 2021/11/18. https://github.com/crystal-lang/crystal/issues/5430
As of Crystal 1.5.0, Windows support is basically there. https://crystal-lang.org/2022/07/06/1.5.0-released.html
However, Crystal aims to support the lowest common denominator between POSIX and Windows, so not all of the Windows standard APIs are supported out-of-the-box. Other Windows specific libraries will need to be created specifically for Windows users/developers.
> The story for Crystal is the same story for many programming languages: grow the interest of users, and find generous funding.
it's the same thing for Elixir as well. they have successfully wooed a few Ruby programmers but not many have completely switched to using Elixir. Again some companies using Elixir are those that want to migrate away from Ruby.
it takes quite a while for a new hot language to become extremely popular and then go on to replace other popular mainstream languages.
it's the same thing for Elixir as well. they have successfully wooed a few Ruby programmers but not many have completely switched to using Elixir. Again some companies using Elixir are those that want to migrate away from Ruby.
it takes quite a while for a new hot language to become extremely popular and then go on to replace other popular mainstream languages.
I love Elixir, but it is an extremely niche language. It's great for network application, but just doesn't seem to be suitable for a daily driver language. Meanwhile crystal can fit all the bill: you can use it to write small scripts, you can write it for write long running service, you can write it to crunch data (the multi-threading feature of crystal is still an experiment though, but it works well for basic stuff)...
As I mainly use ruby for scripting, Crystal has been replacing ruby's role for me for 3+ years and I don't even find anything that really missing, except for maybe a decent ORM like Sequel.
As I mainly use ruby for scripting, Crystal has been replacing ruby's role for me for 3+ years and I don't even find anything that really missing, except for maybe a decent ORM like Sequel.
To be fair, the slow compilation time is annoying even compared to other compiled languages, particularly Go and Nim, which are similarly "high level".
I also found that the Crystal LSP server was painfully slow, and there seems to be a lack of robust developer tooling in general. Has that improved in the last year or so?
I also found that the Crystal LSP server was painfully slow, and there seems to be a lack of robust developer tooling in general. Has that improved in the last year or so?
> What’s awesome about Ruby?
> Dynamically typed
As someone who has experienced the joy and at least some feeling of safety from moving to typescript from javascript, I would seriously question that dynamic typing is awesome.
> Dynamically typed
As someone who has experienced the joy and at least some feeling of safety from moving to typescript from javascript, I would seriously question that dynamic typing is awesome.
I reject the implication that if dynamic typing is awesome, then static typing is _not_ awesome.
It’s like saying pizza is awesome, therefore ice cream is not.
Both are awesome! It just depends what you’re trying to achieve at that point in time. A language’s type system is not, in absolute terms, an advantage or disadvantage. It’s just a design choice, each with their own trade-offs that we must consider.
It’s like saying pizza is awesome, therefore ice cream is not.
Both are awesome! It just depends what you’re trying to achieve at that point in time. A language’s type system is not, in absolute terms, an advantage or disadvantage. It’s just a design choice, each with their own trade-offs that we must consider.
I tend to like when languages are dynamically typed, but I suspect it's not the dynamic typing I like--I think it's that dynamically-typed languages generally have type inference.
I don't like having to write things like `List<int> list = new List<int>`... I find myself thinking, "Why do I need to tell the stupid compiler in the very same line that a new List<int> is a List<int>? Wtf else would it be?!"
When I write in a language such as Kotlin, that's statically typed but has type inference, I feel basically the same lack of resistance as I feel working in dynamically typed languages. Of course, even in such languages, there'll be times when the coder must specify a type, or should specify one for various reasons, but I like when the compiler at least makes an effort, haha.
I like Ruby a lot (and I've tried out Crystal in some recreational programming stuff and like it a lot too), and I think I'd still like it just as much without the dynamic typing.
I don't like having to write things like `List<int> list = new List<int>`... I find myself thinking, "Why do I need to tell the stupid compiler in the very same line that a new List<int> is a List<int>? Wtf else would it be?!"
When I write in a language such as Kotlin, that's statically typed but has type inference, I feel basically the same lack of resistance as I feel working in dynamically typed languages. Of course, even in such languages, there'll be times when the coder must specify a type, or should specify one for various reasons, but I like when the compiler at least makes an effort, haha.
I like Ruby a lot (and I've tried out Crystal in some recreational programming stuff and like it a lot too), and I think I'd still like it just as much without the dynamic typing.
As someone who was on the type train in Uni and moved to dynamic languages, my first feeling was slow and unsafe. I couldn't imagine how things wouldn't just explode. In practice I've rarely seen issues. Ruby is still the fastest way for me to get a concept working. I'd definitely consider it awesome.
not all dynamically typed languages are the same, Ruby is strongly typed and JavaScript is generally described as a weakly typed language.
The word "strong" is not well defined in this context. But usually it is used for languages like Haskell, Idris, PureScript and Elm.
Ruby does not do as many automatic casts as JS. In this regard it may be seen as "stronger".
Ruby does not do as many automatic casts as JS. In this regard it may be seen as "stronger".
Ruby matches this definition: https://www.wikiwand.com/en/Strong_typing
Crystal has static type checking though.
Crystal has static type checking though.
Strong is frequently used incorrectly and as such the meaning has been diluted.
But used the way the OP is using it, strong vs weak is different from static vs dynamic.
But used the way the OP is using it, strong vs weak is different from static vs dynamic.
I’d hardly call ruby strongly typed. There is basically no way to verify anything statically so almost all issues show up in run time. Updating Rails or any gems on a production system is a nightmare where the only option is to have 20,000 unit tests and then hope nothing blows up when you release it.
You have confused strong typing and static typing.
Some of us need the latter for the former.
What would you say some of the strengths of Ruby's type system are?
What would you say some of the strengths of Ruby's type system are?
Ruby 3 supports type signatures: https://github.com/ruby/rbs
The rails creator DHH has indicated that rails would “absolutely not” be getting type support.
That's absolutely the correct call for rails.
It's the main reason I see Rails not lasting another decade. All the Rails apps I have been working on become almost unmanageable after 6+ years because keeping things updated on an untyped system is borderline impossible to do safely.
There are solutions like sorbet[^1] and sorbet-rails[^2]. Have you tried them?
[^1]: https://sorbet.org/
[^2]: https://github.com/chanzuckerberg/sorbet-rails
[^1]: https://sorbet.org/
[^2]: https://github.com/chanzuckerberg/sorbet-rails
Just because Rails is untyped doesn't mean you can add type definitions to your own code within a rails application.
This is the problem when people only know one language, especially javascript. And then have quite naive opinion about programming languages. Ones should try at least all one of big categories; one of ML family, one of C-like, one of Lisp dialect.
> This is the problem
Could you state the problem more concretely? Javascript is a cross between Java and Lisp, having a Java-esque C-like syntax, and lisp-like function-as-a-first-class-citizen behavior. Typescript brings it all the way to C#; so the C-like territory is firmly covered. An ML-family language, especially something like Haskell, would only reinforce the admiration for static types. Which languages would lead to the conclusion that dynamic typing is awesome? Lisps?
Could you state the problem more concretely? Javascript is a cross between Java and Lisp, having a Java-esque C-like syntax, and lisp-like function-as-a-first-class-citizen behavior. Typescript brings it all the way to C#; so the C-like territory is firmly covered. An ML-family language, especially something like Haskell, would only reinforce the admiration for static types. Which languages would lead to the conclusion that dynamic typing is awesome? Lisps?
Oh god you are bending some broad aspects to back it up that Javascript has all of greatness from every other style of programming. No, it doesn't. I don't think it works like that. It's like a p10 of jack of all trade.
I've been using Crystal for some 6 years now and it's still my favorite language. It definitely has issues; it's not perfect, but it really hits a good balance between being a fast language with nice features and encouraging the "joy of programming" that Matz is all about. I would love to see it gain popularity eventually.
Any way related to the talk given at RubyConf Mini?
http://www.rubyconfmini.com/program#Crystal-for-Rubyists
http://www.rubyconfmini.com/program#Crystal-for-Rubyists
Nope, this is way before that talk
With advent of code coming up I'm torn between Kotlin and maybe Crystal.
https://adventofcode.com/
https://adventofcode.com/
Wow, I'm in with Crystal support :)
Do you know something like awesome-training resourses for Crystal?
Do you know something like awesome-training resourses for Crystal?
In general, I tend to look at sites like these for new languages:
https://learnxinyminutes.com/docs/crystal/
https://rosettacode.org/wiki/Category:Crystal
Otherwise I'll be starting with Crystal as well if I decide to do AoC in it, so I don't know of any other resources either.
https://learnxinyminutes.com/docs/crystal/
https://rosettacode.org/wiki/Category:Crystal
Otherwise I'll be starting with Crystal as well if I decide to do AoC in it, so I don't know of any other resources either.
Kotlin, Crystal, Nim, Koka, who can decide?
There's also a Chinese version at https://cn.crystalforrubyists.com
It's not updated for a while though happy to have your PRs :)
Hey Everyone. I'm looking russian speaking Crystal/Ruby developers for really interesting project with competitive salary. For details, please, contact me via e-mail - [email protected]
How is wasm support going? I know they have to "throw away" many of their inventions in lieu of single threads and untouchable stacks, but the core of type inference still maps well to wasm (?)
There has been some progress recently. A big part of stdlib specs already pass on WASM. It's usable for experimentation. A great introduction is available at https://glue.im/noah/introduction-to-webassembly-in-crystal and https://glue.im/noah/webassembly-host-functions-in-crystal
> Crystalian [being the name for Crystal users/evangelists]
Man, there have to be better alternatives than this.
Did you try “crystacean?” Chuckles in .rs.
Man, there have to be better alternatives than this.
Did you try “crystacean?” Chuckles in .rs.
Pfff, yesterday i talked with a Brain fucker...it was terrifying.
Can we just stop calling peoples after tools?
Generally I would agree, but in this case, "Crystal user" isn't that much better.
A developer who uses crystal? Like a builder who uses a hammer is not a hammer-user ;)
EDIT: Wow that took a long time to realize what you meant...haha no, truly not good, and thinking about it my comment "A developer who uses crystal?" is now terrible too.
EDIT: Wow that took a long time to realize what you meant...haha no, truly not good, and thinking about it my comment "A developer who uses crystal?" is now terrible too.
A "tool" is probably the best term for someone who actually uses BF.
Crystian? ;)
With Crystmas as official language day? I'm in!:)
Sounds appropriate given that Ruby already does all its major releases on Christmas day, considering Crystal's close relationship with Ruby.
Geodes?
I think this is an underrated response given that any crystal can start as a geode.
Geodudes?
Hmm, perhaps Wyld Crystallyns?
I too wanted to make this pun, glad I’m not alone :)
There are lots of alternatives. There was a large thread on the forum discussing it and there is basically no consensus for a preferred term.
As someone from the US state of Michigan that has at least two competing demonyms, I actually find the idea of everyone using a different form based on preference to be charming.
Shardies
Strahler / Fossickers?
I opt for meth heads
you people must be fun at parties :)
Crystalizers?
Crysties!
Crynge.
Conversely Perl and C++ made me miserable, as I tried and tried and gave up learning them. I prefer Excel formulae to working with them.