Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: The Crystal programming language – what are your impressions?
53 points by open-source-ux on April 28, 2022 | hide | past | favorite | 47 comments
It's a compiled language with Ruby-inspired syntax (but not identical to Ruby). It has fast performance and a good standard library. Version 1.0 of the language was released in March 2021.

Some disadvantages:

- Compilation is a bit slow

- Small community

- Few learning resources

- Windows version is still under development (not 1.0 ready)

I'm impressed by the language and find it very likable. It's not often discussed on HN, which is a shame.

If you are using Crystal, or have taken a look at the language, what are you thoughts on the language?



I’ve taken several clients projects from conception to production with crystal lang.

It’s more production ready than much I’ve encountered elsewhere with less need for external “shards” or libraries.

The executables are small and to give you one example: a nodejs app that used 500mb of ram is now consuming 25mb as a crystal executable that doesn’t require any minding and happily runs for months with no change in the overall memory consumption or evident leakage. This executable was built on the same machine it runs on and can use normal systemd units and controls etc.

The standard library is built for purpose and has most of what you need.

I agree that compile times are slower than ideal but not like c++ slow or anything, like 30 seconds for one app that’s roughly 30k LOC fwiw.

I use a combo of standard lib .ecr server rendered templates and named js bundles from the frontend build toolchain to speed up the dev cycle. Most backend functionality in crystal works as intended once it compiles.

I really wouldn’t consider anything but Rust an improvement (gets rid of our Boehm GC) as crystal is just nicer to work with than Go, and less hassle or nonsense than c or c++…

Obviously it blows the doors off anyway interpreted even with native extensions… it is FAST


> It's not often discussed on HN, which is a shame.

It absolutely is. In fact, it's how I found out about the language. There's been several conversations about it and each release is posted on HN. For example: https://news.ycombinator.com/item?id=27903288

Crystal as a language is fantastic IMO. The type system literally forces you to consider race-conditions. Never had a language make me eat my vegetables in such a way. The code runs incredibly fast (on par with Rust and Go).

However, like the points you listed, it's hasn't "gone critical." It needs the basics to get even a hundredth of a percent of traction: cross-platform, IDE support, and some "killer" use-case.


I also don't agree that it doesn't come up on HN. If we look at all the recent Ruby threads:

Five hours ago, we were asked "Is Rails still relevant", and one answer is that crystal is a better option: https://news.ycombinator.com/item?id=31170481

Three days ago, we had a post on Sorbet and multiple replies push people back to Crystal: https://news.ycombinator.com/item?id=31159010

And another thread thirty days ago about Stripe's use of Ruby has multiple suggestions people use crystal: https://news.ycombinator.com/item?id=30833555

The pattern goes back a long way and /r/ruby sees regular announcements for new Crystal releases. On this thread someone notes they had a Crystal talk at Ruby conference.

I refer to these because it's appears that several people in this thread have noted a lack of hype and interest, but I feel there's a lot of hype - it's just that it seems to be heavily directed at the existing Ruby users which may not be excited just because it "looks like Ruby".

I can't take my existing Rails apps and just compile them with Crystal. If I'm going to use a different language, a whole range of options exist. I'd consider Elixir, Clojure, Rust or Python. Meanwhile, there are plenty of people pushing me not to use Ruby over concerns about performance, typing, and things that Crystal claims to solve. If the Crystal community wants to reach those, they need to be aware of who is currently avoiding Ruby and thus the current outreach.


> I'd consider Elixir, Clojure, Rust or Python.

Why would you consider Python?


I tried to write a non-trivial application in Crystal and have built some opinions on it:

* It has nice features, seems decently fast (I wasn't able to fully test just how fast)

* The language is complicated, there's so many built-in language constructs it doesn't fit in my head cleanly. I often found myself forgetting about entire features of the language by the time it was appropriate to use them

* The stdlib is decently documented, has good coverage

* Type system is top notch, tagged union types are the future of static typed languages IMO

* It's very not mature. I encountered many poor error messages, seeming compiler errors, poorly documented behavior, etc.. It has potential, but I wouldn't recommend it for production use today.


> The language is complicated

Not that it isn't complicated, but how much experience have you had with Ruby before trying Crystal?


Not much. I tried it, but I’m primarily a Python guy


Crystal is a niche within a niche. Only somebody interested in ruby will care, and then only somebody interested in ruby who is also interested in the use cases where crystal is superior to ruby will care. By now you're in a pretty small subset of the overall programming community. This is bad enough.

Worse, the use cases that crystal aims to solve for ruby, are not things that would attract people to ruby in the first place. Few people need a compiled language and reach for ruby, to find it lacking, and then look at crystal. The people with problems that crystal solves were never looking at ruby in the first place. They're not interested in tricks like `1.day`.


I've never written a line of ruby in my life. For me, Crystal is an easier and asthetically prettier alternative to rust. It's syntax and type system are superior to golang. It doesn't use a giant VM.


Good of you to ask, it's come into my radar this week, and I'm writing a toy project with it (https://github.com/1player/fancy).

My impressions:

* it feels pretty fun and productive. Right now only Elixir feels better than that, so it's good to have fun on the system programming space.

* it's too slow to compile. This is a major pain point for me, iteration speed should be priority #1. I'd love a REPL.

* it's incredibly easy to hack on the compiler. I sent today my first PR to fix a bug in the stdlib.

* great stdlib, needs better documentation, again Elixir would a great inspiration for how to write docs. I'd love more monadic functions to deal with nils.

* github feels healthy and very active, but the whole ecosystem feels like it's stalled in the past 2 years. Pretty much nobody talks about it, most deps haven't been updated in years, it has a ghost town feel.

* it would fit nicely in my list of favourite languages. Zig for very low level, Crystal for native high level, Elixir for daemons and long running services.

Verdict: I like it a lot, it could be my favourite system programming language, but outreach and hype would give me some hope it's going somewhere and not dying a slow death.


Regarding the REPL, they actually merged a PR with support for interactive/debug mode. https://github.com/crystal-lang/crystal/pull/11159. There is an accompanying blog post here https://crystal-lang.org/2021/12/29/crystal-i.html. I haven't used it myself, just thought I'd let you know.


The mix of beautiful syntax and fast compiled binaries is theoretically compelling. Swift is probably the biggest competitor aesthetics wise with this combination. Compiled to wasm (very early days), crystal apps are an order of magnitude smaller than swiftwasm's 4.4-7.5 MB. Both feel incomplete in their ecosystem, fear of future abandonment is real. Something like rails with server and client code in crystal would be a banger, similar to (bloated) Blazor. It would be nice if they could find a way to serialize compilation intermediates to allow incremental compilation!


The language is really nice, the compatibility with the Ruby language is impressive. It’s incredibly fast, uses a tiny amount of memory and it’s binaries are very small. For web development, the Lucky framework by Thoughbot is promising.

Personally my biggest issue is the compile times. For web app development where you may be saving frequently and using hot reloading it’s to slow, it’s lagging.

If non-production compile times were reduced by 60-80% I could envision interest and adoption increasing quickly.


Every programming language needs to confront the fact that it's distribution, not syntax, that matters, and nothing else. And JavaScript won distribution. By a landslide. There are many lovely languages out there, and you can certainly describe your personal processes or even your server processes with them, but ultimately you will be limited by ad hoc and brittle distribution systems, and their adoption will reach some small asymptote.


> Every programming language needs to confront the fact that it's distribution, not syntax, that matters, and nothing else.

Every programmer needs to confront that the fact that their opinion about what really matters, isn't the same thing for them as it is for others. And even more so, what really matters changes based on what context you're using the language in, and what you're building.

There is not a single metric that decides if a programming language "wins" or not. What does that even mean?

For me, Clojure won a long time ago, because what does matter is simplicity. But I also realize that this is a personal opinion, not something that I spread as "fact" for others to finally realize.


>There is not a single metric that decides if a programming language "wins" or not

Yes there is: it's the number of currently running processes described by that language. In practice this means counting every tab in every browser on every device on Earth. Even the largest DC operators in the world, Amazon, Google, Microsoft, NSA, etc who run sophisticated bespoke software distribution systems that support all kinds of runtimes, cannot compare in number to everything else. (Although it wouldn't surprise me if one or more of them attempts to maintain a stateful process for every man woman and child on Earth. That's still not enough.)


I think you misunderstand what GP meant; by "not a single metric", I don't think they mean "there is no metric" but "there's not solely one metric". The one you give is reasonable in some contexts, but not every language is trying to optimize for that. "Winning" is relative to how you define the game, and not everyone will agree your definition is the one they care about.


If people don't like an assertion on which I base my analysis they can and should throw out the result. I am making a bold assertion, but I really think its right, so if you understand it enough to disagree with it, I'll call that a win. But I personally think the success criteria I've specified is not debatable, except of course as fodder for those who like to debate.


> But I personally think the success criteria I've specified is not debatable

I take it as you see "success" in terms of programming languages as something objective then, not subjective?


I have another metric called “performance” that JavaScript is not the winner of. JavaScript is a fact of life in web browsers, less so on servers. I really would only ever use Nodejs as a build tool on my dev box, but perhaps you can advise me of other uses. I don’t consider a long running public facing service to be a good fit for node due to such a VMs memory behavior over time.


I mean, that's an interesting point, but you have defined winning only on a macroscopic scale. On an individual level, winning takes on much more subjective criteria, and I think that's what people typically need information about when making language decisions. Quantity of users is interesting, but I'm certainly not writing an OS in Python because it ranks higher than C on TIOBE, and I'm not going to discount smaller languages that I can use effectively on the sole merit that other languages are more popular.

Languages are tools that solve a problem, and it is possible for them to both be used by relatively few people and still successfully solve a problem.

For example, though Elixir is not as popular as Go, Elixir might win for me because I think it has a better concurrency model. Elixir is not globally used more than Go, but nonetheless it is my winner, and the people who pour their time into the product have still done an admirable job.


There's a great talk -- https://www.youtube.com/watch?v=QyJZzq0v7Z4 -- Why Isn't Functional Programming the Norm? – Richard Feldman -- that goes into this.

It's a discussion of "why" programming languages succeed.


I fully agree.

A part of distribution is mature, easy to install and use toolchain. Another is a wealth of accessible packages. A third is being able to run on popular platforms. The only way to beat JS is eventually wasm.


Thankfully, humans are flawed so don't all go for the most perfect choice every time, because sometimes they want to try something _different_.

If we were robots, we would sit 8 hours a day in grey cubicles to write Java and Javascript because they have the biggest ecosystem and mindshare, increasing our productivity.

But I'm a human, for my small projects I optimise for other metrics than hireability. And truth be told, even at work sometimes I try to make my code writing a little fun with smaller ecosystems that spark joy.


Since we're on about distribution, I converted a nodejs application to Crystal. The docker containers were 1GB vs 20MB.


While I don't disagree, what do you think of Crystal?


I am interested in this topic. What is it that needs to be distributed: the compiler, the runtime environment, the attached debugger, the package manager client, the UI availability, the discoverability, the (relatively) safe execution? JavaScript had a lot of things going for it, but I wonder what was the thing that got distributed that won.


Begins with B, ends with R, 7 letters

B _ _ _ _ _ R


Blender? Bendier? Beefier?


Rhymes with Trouser...


???


"Distribution" isn't a problem solved by programming languages.


Had someone give a talk on crystal at the Boulder Ruby meetup a few years ago. It seemed really interesting if you wanted to build CLI apps and liked the mouthfeel of the ruby language.

What was missing at the time was the equivalent of the gem ecosystem. I'm not sure if that has changed.

Here's the talk if you are interested: https://www.youtube.com/watch?v=B6Hx5wgNFL0



Sorry, I should have been more precise. There was a library ecosystem at the time, it just wasn't as sprawling or useful as Ruby's. (As I'd expect, given the maturity of the languages in question.)


It's unfortunate that Ruby's import semantics hasn't been improved upon by Crystal, i.e. you can only import all definitions from a file - no selective imports like with Python and many other languages (even Perl gets this right).


True, selective imports are easier to understand, but not as readable than a list of `require`. Also, supports glob loading, which is better than JS import keyword.


I will say it's more like statically typed Ruby. It has many frameworks for building web applications of which the most popular seems to be Amber.

Unfortunately it has a small community. For instance in my opinion one would rather build a web application using ruby than crystal. The only ruby-like language that has gained some level of success and popularity is elixir.


I really enjoy it because I already knew Ruby (so the syntax didn’t bother me) and the type system, in particular algebraic types, was to my liking.

That said it might as well be a toy language, in my opinion, because I don’t think it has the support or community to power a serious production project


Honestly Nim is more mature, has more features, compiles quicker and is equally easy. Crystal has nice syntax but otherwise is lacking features.


On top of my to-do pile for a long time.

IIUC Nim also compiles to ISO-compliant C, so you can distribute it more easily (?).


What features are lacking in your opinion?


Windows support (plus more compile options in general), different GC options, more options for parallelism, more libs (both standard + user), etc...

Not necessarily 'lacking' if Nim didn't exist, but lacking in comparison. And for a bleeding edge GC'd statically-typed language that compiles using LLVM I think Pony is more interesting than Crystal, also Ruby-ish syntax.


> If you are using Crystal, or have taken a look at the language, what are you thoughts on the language?

Maybe ask Nikola Corporation? [0]

[0] https://manas.tech/blog/2020/02/11/nikola-motor-company/


The same company that uses HTML5 supercomputers?


Even if that is the case what is your point exactly?

The article I linked shows that there is a company that is using Crystal in production. Correct?


Crystal is one of the languages that I have been learning. I like it because it has a Ruby-like syntax and it is statically typed.

It has a Ruby-like syntax but performance is better than Ruby. The creators of this language say that in many cases the speed will be close to C++. Also, programmers who know Ruby will not have much problem using Crystal.

The language is still in development but I think that it has a future. Another important thing is that the community around this language is growing very fast and there are many jobs for developers who know this language.

I think that Crystal could be another option for languages such as Java and C# because it has similar features like static typing, compiles to native code, etc. The tooling is a little bit rough around the edges, but I think that's to be expected for a language that's only been around for three years. The community seems really active and helpful, though, and I have no doubt that these tools will improve over time as the language develops.

I recommend Crystal to anyone who's had trouble with Ruby's speed or who wants more type information available. Definitely check it out!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: