8 ms·

I wish Crystal would take off. It has so many things going for it (many of them mentioned in the article): performance, useful tooling such as an opinionated fo

by lgreiv 3y ago

I wish Crystal would take off. It has so many things going for it (many of them mentioned in the article): performance, useful tooling such as an opinionated formatter, an integrated RSpec-like test framework, a powerful standard library, an awesome type system that gets out of the way most of the time, a familiar syntax. So far I have been building some smaller personal CLI tools and a few web apps (with the Lucky framework). I’ve also tinkered with running it in AWS lambda functions in a custom (albeit unfinished) runtime. Coming from a decade of Ruby, due to the similar syntax and mindset Crystal is my go to for cases where I need performance or runtime-less execution (e.g. in containers from scratch that contain only the binary and dependencies, if needed). Crystal's standard library provided enough functionality for me in the past to get away with only few dependencies per project, which is great for supply chain security and complexity. Some of it's highlights are: - an ergonomic HTTP::Server and client - OAuth / OAuth2 clients with token refresh - JSON/YAML/XML parsing/generation/mapping - JSON/YAML mapping to classes - native templating similar to ERB

Mawr 3y ago
Don't get your hopes up, Crystal is doomed to never become mainstream. We can divide programmers into two camps, those that enjoy programming itself and those who use it as a means to an end. The latter greatly outnumber the former, let's say 9:1. That massive disparity in numbers is why only the languages that enable the latter group thrive. Ruby is the perfect example, the language got a massive exposure boost due to Rails, but once the hype died down, everyone left. That's because beyond Rails, Ruby has nothing to offer to programmers who want to get stuff done. Nothing besides pain, of course. To those who enjoy playing with languages, "did you know there are 10 different ways you can filter an array in Ruby?" ([1]) is joyful to hear. But when you're woken up at 3am to find a bug in production `arr.reject(&:even?)` is the last thing you want to see. This sort of cleverness, ambiguity and implicitness in language design repels 90% of programmers, and that is the reason why languages like Perl, Ruby, Scala, and now Crystal are either dead, dying, or destined to die. [1]: https://news.ycombinator.com/item?id=35836570 https://news.ycombinator.com/item?id=35836570
- Mawr 3y ago
  (self-reply) Addendum: EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. " [1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
- hyperthesis 3y ago
  > implicitness in language design In a sense, all languages have implicit aspects. Can you characterize the problematic implicitness? (I guess python's TOOWTDI helps, when reading code). I've been studying bidirectional transformations, and a survey paper notes that "relational" methods have died off (somewhat "declarative", where you specify how things should be connected, with the details implicitly worked out for you... something like set-builder notation), while various coding methods remain (where you code for forward transformation, and the backward transformation is automatically derived). They hypothesise it's because relational tools (libraries and projects) are difficult to maintain - but I suspect it's because they are difficult to use. Which is a shame: something that automatically "does what you want" seems like a great idea! But being difficult to predict and diagnose - not being in control - is not great. So, to rephrase my question, what characterizes "good" automation?
stouset 3y ago
As a very, very long-time member of the Ruby community > an integrated RSpec-like test framework Please no. Please, please stop blindly just cargo culting RSpec into your projects. Minitest is included with the language and has all the assertions you might generally want. The only thing RSpec really "adds" is an insane and quirky DSL for the sake of "reading like English", which is a terrible misfeature. Most of the rest are terrible, terrible misfeatures as well. As an example, one of these misfeatures is built-in mocking. Mocking is great, you might think. Yes, mocking is a necessary evil in certain cases but it should be used very sparingly. What happens instead is that people don't bother to design their classes for easy testing and they mock the hell out of everything in order to make their code testable. So what's the problem? Tests are supposed to do two things: 1) discover bugs you didn't realize you wrote, and 2) allow refactoring where if the tests pass, your code is probably alright. Widespread mocking absolutely tanks both of these goals. Instead of testing the effects of code, 90% of the Rails tests I see in the wild test mock everything to the point that the tests simply confirm that the code is implemented the way it is currently implemented. No bugs can be unearthed by this method because none of the actual effects are tested, just that certain methods are called in a certain order. And refactoring is now insanely difficult because any change to the logic causes the tests to fail, even if the effects are the same. This is just one example. So please, I beg you, stop reflexively reaching for RSpec. Minitest is great, it has most of the things you need out of the box. And Rails has a test framework built on top of it that similarly already does all the things you need. And it's all just plain Ruby. </soapbox>
norman784 3y ago
I also wished for a long time for Crystal to take off, but now having Go and Rust I don't see Crystal to gain too much relevance in the future, while it might be appealing to Ruby devs, Ruby is becoming better every day, but still Ruby devs stay in Ruby because of the ecosystem, the company where I work on already decided that no new project will be written in C, C++, Ruby, Java and instead use Go or Rust, I suppose that other companies are doing the same.
- pelasaco 3y ago
  Exactly.. I was a Crystal enthusiast, but because of their slow development pace and small community, half-baked documentation (all understandable, no critics here) and the raise of Go (great documentation, fast pace development, huge community), was hard to keep focus on that. Go became my option to ruby, and I'm doing fine with that.
  - actionfromafar 3y ago
    I can't suffer Go. C, Rust, C++, Ruby Python, Java, C#, VB.Net are all fine, F# looks cool too but I never used it. I started to use Crystal in a small commercial project, as a web backend, and it was very fun and promising. But the project got cancelled for completely unrelated reasons. I long for an excuse to use Crystal again. Hard typing combined with Ruby carefree style and EXEs without runtime... really cool stuff. I think Crystal will crack the Win32 nut eventually.
    - rookderby 3y ago
      I think windows is the main thing holding crystal back. I make little games for jams and I'm always trying out new languages. I submitted a bug related to running processes on windows last november, it was just recently closed as completed. Although I spend almost all of my at-home time on linux, I know that I have to provided windows executables for jams. I plan to come back to crystal when I can write once and can compile the same code everywhere.
- pmontra 3y ago
pelasaco 3y ago
all those features are offered by Go too.. The similarities among ruby and crystal are normally easy to spot in small projects, but their differences get really visible in big projects.
- moe 3y ago
  Go is not a good comparison. Crystal is expressive, 500 lines of Go commonly translate to 50 lines of Crystal. The DX in Crystal is really closer to Ruby than to Go. It's essentially a very fast and type-safe version of Ruby.
  - pelasaco 3y ago
    > The DX in Crystal is really closer to Ruby than to Go. Me as polyglot can say that is much easier to switch completely between languages and paradigm than write or talk similar (but not equal) languages. So it is maybe a great reason for beginners to start to play with Crystal as Rubyists, but as soon as you start to work daily with the language, other factors like good documentation, tons of examples, great standard lib, active community and development, etc are much more important than if its remembers ruby or not.
    - straight-shoota 3y ago
      Crystal core developer speaking: I think this argument is less about the concrete syntactical and semantic similarities to Ruby, but the shared general idea to focus on developer happiness. For example, code is easy to read, yet still expressive.
    - mirekrusin 3y ago
      Maybe with LLMs it won't matter much anymore? Maybe in the near future we'll have copilot for crystal as vscode plugin and the rest doesn't matter much - just quality of this plugin?
      - aatd86 3y ago
        What will your LLM be trained on? It only makes the problem even more acute I think.
Thaxll 3y ago
Crystal won't take off because it's an "amateur" language, to have a good and properly supported language you need a lot of poeple and money, which Crystal has not. I would not rely my business on a language where there is just one full time dev working on it and relying on donations.
- rco8786 3y ago
  This reads a bit like a tautology..."Crystal has not taken off because Crystal has not taken off".
  - Thaxll 3y ago
    Crystal has been going on for years and there is still no major support, it won't change, basically if you're a new lanague you have a couple of years after that you just missed the train.
    - nindalf 3y ago
      Not historically true. Python didn't take off for years after the initial release in 1991. Even in the mid 2000s people were evangelising Python like it was a new thing (https://xkcd.com/353/ https://xkcd.com/353/) Or take Rust, which has gained adoption more recently. It took a while to get going after the 1.0 release in 2015. If you look at daily downloads of Rust crates (https://lib.rs/stats https://lib.rs/stats) as a proxy for adoption: - 2015 to 2017 - not many downloads - 2018 - first signs of real growth, reaches 1M per day. - 2018 to 2021 - 10x growth, 10M per day - 2021 to 2024 - 10x growth (projected) So new languages shouldn't lose hope if they don't see adoption immediately. It's possible that they might be adopted later. But for language authors, it's the hope that kills you. You continue working on it even if maybe you shouldn't.
      - viraptor 3y ago
        Another one: nix started in 2003 but hasn't really entered the common usage/popularity until the last 4 (or so) years as far as I can tell.
mavu 3y ago
Counterpoint: why should I care if it "takes off"? It is a very much stable, fast, useful language that can be used today.
- webkike 3y ago
  You get more and better libraries if the language is popular. Your favorite APIs (such as AWS for example) implement clients in the language
  - Koshkin 3y ago
    More, of course. But better? Percentage-wise, unlikely.
    - webkike 3y ago
      Maybe not if you consider good as a threshold, but the quality of good libraries will improve with a larger pool of skilled contributors
  - biql 3y ago
    I wonder if the lack of libraries in a new language is just a few ChatGPT-integrations away. After all, Crystal is so similar to Ruby. I bet as soon as context/environment aware ChatGPT tools/agents that can compile / run tests / apply fixes until it works are available, this will become the reality: "Create this Ruby library but for Crystal" and in a few hours you can include it in your Crystal project.
    - notmypenguin 3y ago
      The FFI wrapper for c libraries is great, and one can use imagemagick and pngquant and such via an IO buffer wrapping a call to a command. Crystal works great TODAY and will blow Ruby out of the water on performance. I simply can’t justify RoR in 2023 given Crystal
    - deleted 3y ago
      [deleted]
alwaysbeconsing 3y ago
It looks nice, I've been wanting to try it. Regarding tooling, how is the debugger/debugging support?
- lgreiv 3y ago
  It’s a bit of legwork, but it’s there. https://github.com/amberframework/docs/blob/master/examples/crystal-debug.md https://github.com/amberframework/docs/blob/master/examples/...
  - alwaysbeconsing 3y ago
    Thanks, bookmarked!
KRAKRISMOTT 3y ago
Their development team is slow ass. They live in an idealistic world where Windows users are not worth supporting. Bugs and features take too long to fix and ship. Feels more like a toy enthusiast project relying entirely on organic growth. It cannot survive in a world where the most successful programming projects have full-time corporate backed teams.
- EyeSayUntoThee 3y ago
  your entire complaint appears based around the timeline of windows support. you are free to use windows as a principal OS, but please inform us of your biases when totally trashing a team and product for what is essentially a technical issue of significant proportions, not a product of laziness or slowness, as you allege.
kashif 3y ago
I wish Nim would take off...but alas the worst languages are always the most popular - JS, C++ ...
- Conscat 3y ago
  The most flexible languages with the most advanced development tools are always the most popular - JS, C++
- lgreiv 3y ago
  Nim really looks awesome too! If I came from a python background, I could see me reaching for Nim rather than Crystal.

by lgreiv 3y ago

Mawr 3y ago

Don't get your hopes up, Crystal is doomed to never become mainstream. We can divide programmers into two camps, those that enjoy programming itself and those who use it as a means to an end. The latter greatly outnumber the former, let's say 9:1. That massive disparity in numbers is why only the languages that enable the latter group thrive. Ruby is the perfect example, the language got a massive exposure boost due to Rails, but once the hype died down, everyone left. That's because beyond Rails, Ruby has nothing to offer to programmers who want to get stuff done. Nothing besides pain, of course. To those who enjoy playing with languages, "did you know there are 10 different ways you can filter an array in Ruby?" ([1]) is joyful to hear. But when you're woken up at 3am to find a bug in production `arr.reject(&:even?)` is the last thing you want to see. This sort of cleverness, ambiguity and implicitness in language design repels 90% of programmers, and that is the reason why languages like Perl, Ruby, Scala, and now Crystal are either dead, dying, or destined to die. [1]: https://news.ycombinator.com/item?id=35836570 https://news.ycombinator.com/item?id=35836570

Mawr 3y ago
(self-reply) Addendum: EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. " [1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
hyperthesis 3y ago
> implicitness in language design In a sense, all languages have implicit aspects. Can you characterize the problematic implicitness? (I guess python's TOOWTDI helps, when reading code). I've been studying bidirectional transformations, and a survey paper notes that "relational" methods have died off (somewhat "declarative", where you specify how things should be connected, with the details implicitly worked out for you... something like set-builder notation), while various coding methods remain (where you code for forward transformation, and the backward transformation is automatically derived). They hypothesise it's because relational tools (libraries and projects) are difficult to maintain - but I suspect it's because they are difficult to use. Which is a shame: something that automatically "does what you want" seems like a great idea! But being difficult to predict and diagnose - not being in control - is not great. So, to rephrase my question, what characterizes "good" automation?

stouset 3y ago

As a very, very long-time member of the Ruby community > an integrated RSpec-like test framework Please no. Please, please stop blindly just cargo culting RSpec into your projects. Minitest is included with the language and has all the assertions you might generally want. The only thing RSpec really "adds" is an insane and quirky DSL for the sake of "reading like English", which is a terrible misfeature. Most of the rest are terrible, terrible misfeatures as well. As an example, one of these misfeatures is built-in mocking. Mocking is great, you might think. Yes, mocking is a necessary evil in certain cases but it should be used very sparingly. What happens instead is that people don't bother to design their classes for easy testing and they mock the hell out of everything in order to make their code testable. So what's the problem? Tests are supposed to do two things: 1) discover bugs you didn't realize you wrote, and 2) allow refactoring where if the tests pass, your code is probably alright. Widespread mocking absolutely tanks both of these goals. Instead of testing the effects of code, 90% of the Rails tests I see in the wild test mock everything to the point that the tests simply confirm that the code is implemented the way it is currently implemented. No bugs can be unearthed by this method because none of the actual effects are tested, just that certain methods are called in a certain order. And refactoring is now insanely difficult because any change to the logic causes the tests to fail, even if the effects are the same. This is just one example. So please, I beg you, stop reflexively reaching for RSpec. Minitest is great, it has most of the things you need out of the box. And Rails has a test framework built on top of it that similarly already does all the things you need. And it's all just plain Ruby. </soapbox>

norman784 3y ago

I also wished for a long time for Crystal to take off, but now having Go and Rust I don't see Crystal to gain too much relevance in the future, while it might be appealing to Ruby devs, Ruby is becoming better every day, but still Ruby devs stay in Ruby because of the ecosystem, the company where I work on already decided that no new project will be written in C, C++, Ruby, Java and instead use Go or Rust, I suppose that other companies are doing the same.

pelasaco 3y ago
Exactly.. I was a Crystal enthusiast, but because of their slow development pace and small community, half-baked documentation (all understandable, no critics here) and the raise of Go (great documentation, fast pace development, huge community), was hard to keep focus on that. Go became my option to ruby, and I'm doing fine with that.
- actionfromafar 3y ago
  I can't suffer Go. C, Rust, C++, Ruby Python, Java, C#, VB.Net are all fine, F# looks cool too but I never used it. I started to use Crystal in a small commercial project, as a web backend, and it was very fun and promising. But the project got cancelled for completely unrelated reasons. I long for an excuse to use Crystal again. Hard typing combined with Ruby carefree style and EXEs without runtime... really cool stuff. I think Crystal will crack the Win32 nut eventually.
  - rookderby 3y ago
    I think windows is the main thing holding crystal back. I make little games for jams and I'm always trying out new languages. I submitted a bug related to running processes on windows last november, it was just recently closed as completed. Although I spend almost all of my at-home time on linux, I know that I have to provided windows executables for jams. I plan to come back to crystal when I can write once and can compile the same code everywhere.
pmontra 3y ago

pelasaco 3y ago

all those features are offered by Go too.. The similarities among ruby and crystal are normally easy to spot in small projects, but their differences get really visible in big projects.

moe 3y ago
Go is not a good comparison. Crystal is expressive, 500 lines of Go commonly translate to 50 lines of Crystal. The DX in Crystal is really closer to Ruby than to Go. It's essentially a very fast and type-safe version of Ruby.
- pelasaco 3y ago
  > The DX in Crystal is really closer to Ruby than to Go. Me as polyglot can say that is much easier to switch completely between languages and paradigm than write or talk similar (but not equal) languages. So it is maybe a great reason for beginners to start to play with Crystal as Rubyists, but as soon as you start to work daily with the language, other factors like good documentation, tons of examples, great standard lib, active community and development, etc are much more important than if its remembers ruby or not.
  - straight-shoota 3y ago
    Crystal core developer speaking: I think this argument is less about the concrete syntactical and semantic similarities to Ruby, but the shared general idea to focus on developer happiness. For example, code is easy to read, yet still expressive.
  - mirekrusin 3y ago
    Maybe with LLMs it won't matter much anymore? Maybe in the near future we'll have copilot for crystal as vscode plugin and the rest doesn't matter much - just quality of this plugin?
    - aatd86 3y ago
      What will your LLM be trained on? It only makes the problem even more acute I think.

Thaxll 3y ago

Crystal won't take off because it's an "amateur" language, to have a good and properly supported language you need a lot of poeple and money, which Crystal has not. I would not rely my business on a language where there is just one full time dev working on it and relying on donations.

rco8786 3y ago
This reads a bit like a tautology..."Crystal has not taken off because Crystal has not taken off".
- Thaxll 3y ago
  Crystal has been going on for years and there is still no major support, it won't change, basically if you're a new lanague you have a couple of years after that you just missed the train.
  - nindalf 3y ago
    Not historically true. Python didn't take off for years after the initial release in 1991. Even in the mid 2000s people were evangelising Python like it was a new thing (https://xkcd.com/353/ https://xkcd.com/353/) Or take Rust, which has gained adoption more recently. It took a while to get going after the 1.0 release in 2015. If you look at daily downloads of Rust crates (https://lib.rs/stats https://lib.rs/stats) as a proxy for adoption: - 2015 to 2017 - not many downloads - 2018 - first signs of real growth, reaches 1M per day. - 2018 to 2021 - 10x growth, 10M per day - 2021 to 2024 - 10x growth (projected) So new languages shouldn't lose hope if they don't see adoption immediately. It's possible that they might be adopted later. But for language authors, it's the hope that kills you. You continue working on it even if maybe you shouldn't.
    - viraptor 3y ago
      Another one: nix started in 2003 but hasn't really entered the common usage/popularity until the last 4 (or so) years as far as I can tell.

mavu 3y ago

Counterpoint: why should I care if it "takes off"? It is a very much stable, fast, useful language that can be used today.

webkike 3y ago
You get more and better libraries if the language is popular. Your favorite APIs (such as AWS for example) implement clients in the language
- Koshkin 3y ago
  More, of course. But better? Percentage-wise, unlikely.
  - webkike 3y ago
    Maybe not if you consider good as a threshold, but the quality of good libraries will improve with a larger pool of skilled contributors
- biql 3y ago
  I wonder if the lack of libraries in a new language is just a few ChatGPT-integrations away. After all, Crystal is so similar to Ruby. I bet as soon as context/environment aware ChatGPT tools/agents that can compile / run tests / apply fixes until it works are available, this will become the reality: "Create this Ruby library but for Crystal" and in a few hours you can include it in your Crystal project.
  - notmypenguin 3y ago
    The FFI wrapper for c libraries is great, and one can use imagemagick and pngquant and such via an IO buffer wrapping a call to a command. Crystal works great TODAY and will blow Ruby out of the water on performance. I simply can’t justify RoR in 2023 given Crystal
  - deleted 3y ago
    [deleted]

alwaysbeconsing 3y ago

It looks nice, I've been wanting to try it. Regarding tooling, how is the debugger/debugging support?

lgreiv 3y ago
It’s a bit of legwork, but it’s there. https://github.com/amberframework/docs/blob/master/examples/crystal-debug.md https://github.com/amberframework/docs/blob/master/examples/...
- alwaysbeconsing 3y ago
  Thanks, bookmarked!

KRAKRISMOTT 3y ago

Their development team is slow ass. They live in an idealistic world where Windows users are not worth supporting. Bugs and features take too long to fix and ship. Feels more like a toy enthusiast project relying entirely on organic growth. It cannot survive in a world where the most successful programming projects have full-time corporate backed teams.

EyeSayUntoThee 3y ago
your entire complaint appears based around the timeline of windows support. you are free to use windows as a principal OS, but please inform us of your biases when totally trashing a team and product for what is essentially a technical issue of significant proportions, not a product of laziness or slowness, as you allege.

kashif 3y ago

I wish Nim would take off...but alas the worst languages are always the most popular - JS, C++ ...

Conscat 3y ago
The most flexible languages with the most advanced development tools are always the most popular - JS, C++
lgreiv 3y ago
Nim really looks awesome too! If I came from a python background, I could see me reaching for Nim rather than Crystal.