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.<p>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.<p>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).<p>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:<p><pre><code> - 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</code></pre>
I love Crystal, and have loved it for several years. It was my go-to for Advent of Code or small fun projects for a while.<p>Eventually, I got so tired of constantly jumping between browser docs and my editor because of the lack of a working and useful language server (yes, I know about Scry and Crystalline, but neither of them actually do autocomplete outside of maybe 2% of cases), and I got so used to an amazing tooling experience when writing F# (my other favorite language) that I just kinda dropped off using Crystal.<p>Things I would've written in Crystal, I wrote in F#. If I _really_ needed a static binary, I picked up Rust (though I love Crystal's syntax _so much more_ than Rust's).<p>If Crystal gets a good language server, heck yeah I'll roll with it. In the meantime, it just sorta feels like a missed opportunity.
We've been happily using Crystal in production at Heii On-Call (free website / cron job monitoring, free critical alerting to iOS/Android apps, on-call scheduling) [1] specifically for higher-throughput components of the overall system, such as the API server [2] and the system that continuously does website monitoring [3]. For context, we do use Ruby on Rails for the main website frontend.<p>Really I find Crystal to be <i>so</i> much more ergonomic and pleasant to use than Go or Rust, though I could see that being a matter of opinion. Very concise, very readable, very fast once compiled.<p>Porting utility classes from Ruby is so easy too. I end up spending more time porting unit tests than porting the underlying code. And the testing story (Crystal's "spec" [4]) is really nice.<p>If you want to try Crystal without installing anything, I made a "crystal-docker-quickstart" project template you can clone [5]. You can safely try out Crystal and have your first static binary compiled in about 15 seconds via something like:<p><pre><code> git clone https://github.com/compumike/crystal-docker-quickstart.git my_app
cd my_app
./d_dev
make && out/my_app
</code></pre>
Lastly, I've found that the Crystal community [6] is small but friendly and helpful. It's at that magical stage of an open source community where people are extremely competent and responsive, but not (yet?) burned out from dealing with so many people.<p>[1] <a href="https://heiioncall.com/" rel="nofollow">https://heiioncall.com/</a><p>[2] <a href="https://api.heiioncall.com/" rel="nofollow">https://api.heiioncall.com/</a><p>[3] <a href="https://heiioncall.com/outbound_prober" rel="nofollow">https://heiioncall.com/outbound_prober</a><p>[4] <a href="https://crystal-lang.org/reference/1.8/guides/testing.html" rel="nofollow">https://crystal-lang.org/reference/1.8/guides/testing.html</a><p>[5] <a href="https://github.com/compumike/crystal-docker-quickstart">https://github.com/compumike/crystal-docker-quickstart</a><p>[6] <a href="https://forum.crystal-lang.org/" rel="nofollow">https://forum.crystal-lang.org/</a>
Real world example for Crystal: our overnight sitemap generation (built using Ruby, as part of our Rails app) took 6 hours to generate 20 million links. At some point due to infra changes, it stopped running to completion. Since then, we ported it over to Crystal, with the main code virtually unchanged (library to help generate sitemaps has matching API). Just had to set up basic database mapping for a few tables. That version is now in production, and it now processes 30 million links in about 30 minutes.
For friends from China who are interested in Crystal,i create the Github crystal-china org, <a href="https://github.com/crystal-china">https://github.com/crystal-china</a>, and I also hold <a href="https://crystal-china.org" rel="nofollow">https://crystal-china.org</a> domain name, although there is still no time to build a website.<p>Let us discuss use Chinese in TG,Discord, and do something together.
Lucky core dev here! I've been using Crystal in production since about 2017. I love the language, but there's definitely some hard tradeoffs which are mentioned in this thread. Our larger app has some serious compile time issues. We deploy with github actions, and it takes about 30min to build the production binary, compile assets, and push the binary to the server. But overall, I've found my apps are way more stable, and really fast as well as running on much smaller machines. The tradeoffs for us are definitely worth it.
As a very anecdotal data point, I once created a pet project that interfaced with a CouchDB endpoint and inserted some keys with dates in a complex nested JSON structure and deployed it to Heroku. (It was ment to be called as a Apple Shortcut)<p>It took me half a day with Ruby, two days with Crystal and a little more than a week with Rust. The Crystal experience was very very smooth coming from Ruby. With Rust it felt like I was wrestling with the compiler.
The minimum requirement for a language to take off: first class Windows support. The current preview support is good enough to start playing. A high-performance (C-like, LLVM based) and a very high-level language with Ruby-like expressiveness coupled with static typing and compile-time (as well as runtime) safety, and with the ability to produce standalone native executables make it really one of a kind.
There’s really a lot to be said for an easily readable relatively terse language that compiles to a tiny binary executable with low memory usage and can be run as a service, profiled, etc.<p>We use it extensively in production. I really would only ever consider Rust as an alternative, it’s <i>that</i> good.
Crystal should get more attention, from desktop application developers in particular. Crystal makes it much easier to maintain large performant code bases.<p>Basically working with Crystal is much more like working with Python or Ruby, but with performance comparable to C. Unlike Rust or Go where you get the performance, but you don’t get the huge bump in productivity b/c youre working at a lower level of abstraction.
Windows support is still under development, yes?<p><a href="https://crystal-lang.org/install/on_windows/" rel="nofollow">https://crystal-lang.org/install/on_windows/</a><p>I'll stick with Nim then, it's Windows support is much better.
Of course for backend dev, Linux is usually #1 choice. Let's try Crystal.
> I remember when I first learned about type inference, one of my first thoughts was, why can’t we just create a statically typed language that does type inference for everything. The compiler would still have to figure out the types at compile time anyway, and I’d save myself a few keystrokes.<p>> Turns out this is what Crystal does. It does aggressive type inferencing, and only asks you to declare types when it can’t figure it out.<p>> Crystal does not have a global type inference engine
I find myself getting pretty immediately turned off by IMO kind of silly and unverifiable catch phrases languages use as marketing tools. Crystal uses "a programming language for humans", much like EmberJS's "for _ambitious_ web developers". As I skim the Crystal page, it's not clear to me what is supposed to stand out as a language that makes it "for humans" any more than any other language? It just seems silly.
> I recently implemented a Brainfuck interpreter in the Crystal programming language<p>Aw, a bit of a missed opportunity to write a crystal version of the impressive (but probably dated?) "How I start"-article for Nim:<p><a href="https://howistart.org/posts/nim/1/" rel="nofollow">https://howistart.org/posts/nim/1/</a>
In my opinion a new programming language nowadays should focus on (in this order):<p>1. easy interfacing with existing library ecosystem (like e.g. C interfaces)<p>2. nice testing framework<p>3. good IDE with good context help and refactor plugins<p>4. syntactic sugars and improvements over other languages
I wish they had used the headline to say something about the language rather than the useless tagline "for humans". Is it imperative, functional, object-oriented? For embedded, scripting, system programming?<p>Is it new? A dialect of something else?<p>Nope, all I know is it's "for humans", and possibly computers can run it too (?)
Just a tip. I scrolled multiple screenfuls and actually know less now about this language.<p>Put the recipe at the top.<p>We want to know what it will produce. If you have a heart-warming story about how you learned it in the tootledge of Chef van Rossum, tell that story below the fold.<p>I want a sense of the flavor before your whole life story :)
Crystal has already "taken off" for me, in the sense that it does everything I need it to do. The standard library is replete with http client and server, as well as JSON, and a host of other useful bits, just have a look: <a href="https://crystal-lang.org/api/" rel="nofollow">https://crystal-lang.org/api/</a><p>Wrapping of C-libraries is a relatively painless experience:
<a href="https://crystal-lang.org/reference/1.8/syntax_and_semantics/c_bindings/index.html" rel="nofollow">https://crystal-lang.org/reference/1.8/syntax_and_semantics/...</a><p>I can use any/all command-line utilities with an IO buffer (image processing, other out-of-band processing)<p>The stock "DB" module supports Sqlite, MySql, and PostGres out of the box.<p>SPEED: anyone "sticking" with RoR is not paying attention here: Crystal is a compiler and spits out a binary executable with low memory usage compared to it's interpreted cousin. This binary executable can be run by systemd as a normal system service, started with command-line options, etc.
Apples-and-Oranges comparison: I've turned a nodejs-based app that used roughly 600mb memory into an executable using 12mb. The latter has also not leaked any substantial amount of memory after running for 5 months straight now (still says 12mb) so, take that as you wish...<p>For me, Crystal has already arrived. I don't need group approval for this to be the case. I can happily use version 1.7.3 for the rest of eternity, so I don't see this rug being pulled from out from under me in the near future.
Perhaps use private shard repos if this is your actual concern.
Slow compile times were a real issue for me when I was trying to leverage Crystal. This is acknowledged as a significant (and challenging to solve) issue: <a href="https://dev.to/asterite/incremental-compilation-for-crystal-part-1-414k" rel="nofollow">https://dev.to/asterite/incremental-compilation-for-crystal-...</a>
I’m honestly more interested in jRuby at this point. I think the coming combination of jRuby with fibers is going to become extremely compelling based on the early numbers that Charles Nutter was seeing. This is approaching BEAM levels of concurrency.<p><a href="https://twitter.com/headius/status/1653051050285203456?s=46&t=alZCBpHQmrOiijvY9w8DwA" rel="nofollow">https://twitter.com/headius/status/1653051050285203456?s=46&...</a>
They seem to suffer from similar problems as Julia: Type inference for large projects seems to be extremely difficult and results in huge compile times / startup times and or runtimes.
As someone who isnt a programmer, why are those "guides" done so poorly?<p>def double(val)
val + val
end<p>The example does not show what happens when you try to connect text and a number. Will it glue them together? Give an error?<p>Also, "for humans", the whole x = x + 1 is illogical.
it’s = “it is”<p>otherwise it’s “its”<p>he or she makes this grammatical error multiple times<p>if you don’t know which to use, if you can substitute “it is” and it makes sense, then use “it’s”, otherwise not
Looks fine I guess, but (like Ruby) it's not as intuitive as Python, and I have a lot of hopes that Mojo will bring about a performant Python like programming experience