I used Crystal to create a web application a 2-3 years ago. It is running great without any problems. There are not that many users (only about 300-400) at any time. Anyhow, I did not touch the application in the last two years, and did not use Crystal in the last two years for anything else. I used Rust to write some simple personal CLI apps, which was fun but also hard. For some reason, couple of days back I returned to Crystal for a CLI app that I am making. I will say this: Crystal is a lot of fun to program in, easy to use and performant all at the same time. I cannot explain the reasons objectively, but it is really a joy to use Crystal. I think I will be using it from now on. I just wish it had a bigger community and as a result more libraries.
I'm a Ruby guy and I tried Crystal for about 2 years and absolutely loved it but then had to give up for the following reasons:
1. Too slow to compile (the whole program + the entire stdlib is built everytime you build!). No incremental compilation available.
2. No language server (apparently it's just impossible due to the way the language works). Tbh, I'd be happy with just "Go to definition" but alas, no-can-do!
3. Obscure error messages (macros are to blame here)
4. Weak HTTP server implementation -- making things such as a fetching POST params or uploads incredibly frustrating. Once read the request body cannot be read again.
5. Weak/non-existent Windows support
6. No multicore support
7. Obviously small community
8. Nil handling takes a bit getting used to (coming from Ruby)
9. Error messages are hard to read with overloaded methods wherein just the types are used without any indication of what doesn't match
Overall, if the above changes, I'd switch to it in a heartbeat!
> 3. Obscure error messages (macros are to blame here)
I feel like this is a bit strongly influenced by the macro experience.
Macros are an advanced and powerful feature and naturally more complex to debug.
In general, Crystal's error messages are often praised for their clarity and helpfulness (especially compared to dynamically typed languages, of course).
> 4. Weak HTTP server implementation -- making things such as a fetching POST params or uploads incredibly frustrating. Once read the request body cannot be read again.
The stdlib implementation of `HTTP::Server` is intentionally very bare-bones (many programming languages don't even have such a practically usable feature in stdlib).
Specialized web server implementations are available as shards (https://shardbox.org/categories/Web_Frameworks). They're based on the foundation in stdlib and provide more advanced features.
> 5. Weak/non-existent Windows support
Windows support is pretty stable and almost complete by now.
> 6. No multicore support
Crystal has supported multi-threading as opt-in via the `-Dpreview_mt` flag. It's considered a preview, because it's to be used with care when dealing with data structures that are not thread-safe. But it has proven to work well in production use.
> 8. Nil handling takes a bit getting used to (coming from Ruby)
But once you're used to it, it's sooo much helpful. It just helps to avoid a lot of potential bugs which you would have to take extra care for in Ruby.
I also tried it now and then. There are too many places to have concurrency and scaling issues with such a tiny community. The packages and feature sets are thin too.
Alternatives: if you don't mind your eyes bleeding with C++-verbosity and tracking liveness yourself, there's Rust. Sure Go looks cute until you have a million users emailing you trivial questions they should've asked a group.
And if you want something similar to Crystal but with even stricter and more granular semantics than Rust with an even smaller community. there's Pony. It was built around the Orca GC. There's Nim too. Finally, one can use Haskell to built that critical payment service and maintain absolute job security. Meanwhile, the Erlang/Elixir OTP stack stays performant, although no one is quite sure how to package, deploy, and manage its lifecycle properly.
> 2. No language server (apparently it's just impossible due to the way the language works). Tbh, I'd be happy with just "Go to definition" but alas, no-can-do!
> 2. No language server (apparently it's just impossible due to the way the language works). Tbh, I'd be happy with just "Go to definition" but alas, no-can-do!
Crystal powers 90% of the Kagi search backend (reminder being Python). Highlights are great performance and concurency handling. Biggest downsides at this moment are compilation speed (does not take advantage of multi CPU cores) and debugging tools.
Overall our experience has been fantastic (we adopted it while still in beta) and the pace the language is developing is great.
Ah, that's interesting information. I've been a (paid) user of Kagi these last few weeks and I'm really enjoying its snappiness.
Of course, no ads or trackers must help - when I look at the Network tab in developer tools the comparison with a google search is stark. ~4 requests vs. google's ~50.
Wow! I’ve been paying for Kagi for as long as it’s been possible to, love the project & the search results are truly so much better than I’ve gotten from Big G for most queries.
Never would’ve expected it to be using Crystal though! That’s really neat. Are there open source bits? I’d love to see some enterprise-level Crystal examples
Just want to say I am very happy with Kagi. I've been a paying subscriber since there was an announcement here a few months ago. The results are typically very good, the speed is unreal, and features like lenses and personalized results are so awesome. It's so nice not having search results filled with Stack Overflow spam sites, and if anything slips through I can block it.
What do you mean by great concurrency? Last I checked multithreading was still hidden behind an experimental compiler flag, which turns me off a bit...
git clone https://github.com/compumike/crystal-docker-quickstart.git my_app
cd my_app
./d_dev
# docker container spins up in a few seconds... within the container's bash shell, try:
make spec
make && out/my_app
# outside container, you may edit src/main.cr, save it, and then again within container:
make && out/my_app
Out of all the programming languages coming out these days, Crystal is the one I am watching out for. I've never programmed with Ruby, but I have programmed with Python in the past so I really value the focus on programmer friendly syntax that Python taught me. Currently a Golang a programmer and I love the performance plus binary executables!
From my experience so far Crystal feels like a performant language with the wonderful feel of Python. Definitely check this language out if this is the first time you're hearing about it.
However it really needs a bit of “wow” factor to take off.
We’ve used it here and there in dribs and drabs but don’t see a reason to use it in a new project when there is Elixir and/or Rust.
Elixir brings the easy to use concurrency almost automatically. This and other features make it almost unbeatable for web and backend stuff.
Rust is just as fast as crystal. Albeit harder to grok.
Python was literally saved by the numerical libraries. Or there would not be real reason to keep using it.
I keep one weather eye open on crystal to see how it’s doing but have seen no real reason to start a new project with it as yet.
For me the syntax is not reason enough as yet. Elixir is maybe easier and functional to boot. Being object oriented in 2022 is not a good reason either.
I’m an old rubyist and I wish Crystal the best. I’ve been following it since it was a gleam in the eye, But … why? And for what??
That provides you the flexibility of having union types (variable may be `Thing1` or `Thing2`) for generic purposes, AND type-safetiness (is that a word?) when dealing with specific paths of your program that apply differently to some of the subtypes of the variable.
I think Swift and Kotlin support (some of?) that now. It was really new for me back in the day (around 2014?).
But that's from a coding point of view - not that much about niches, as you talk about.
Now, all we need for crystal to succeed is numpy, scipy, something pandas-like, and of course matplotlib (not plots, matplotlib).
By the way, how are we on data-science friendly IDEs? Debugging? Automatic thorough documentation generator? Tooling in general?
Is the time to first plot fast?
Data science is a domain crystal could excel in. Having both an approachable syntax and the feedback that the compiler and type system provides makes it an excellent companion for that work.
I've tried a few times now to do data science in a statically typed language, and I just haven't enjoyed the developer experience. In general I tend to think the advantages of dynamic typing are overblown, but this is one problem domain where it seems to be indispensable.
ML and data engineering is a different story, of course. Also, I wouldn't be surprised if something clever could be done with a structural type system.
>... numpy, scipy, something pandas-like, and of course matplotlib... Where I work, we desperately need a fast python.
It sounds like Julia would be a better fit than Crystal?
Ironically they have similar problems: compile/start-up time (though crystal has working ahead of time compilation - AFAIK Julia developers are still working on speeding up "first run" in various ways).
I used Crystal every day for 2 years.
It is for me one of the best languages. Fun and powerful but there are some big problems, I switched to Elixir.
Among the problems :
- A too long compilation. For 2 projects, the compilation in dev env takes more than 30 seconds for each compil, the developer experience is dead at this cadence.
- IDE integration: auto-completion, go to def, API docs, etc works when it wants (almost never).
- The community is too small which results in a lack of docs, examples, help. I spent days searching in Github projects, just to see examples of basic things.
- Instead of focusing on a main framework that makes everyone agree, everyone makes their own framework, their own libs (including me). The result is a lot of time and energy spent on duplicate packages and frameworks that are not necessarily maintained.
I continue to follow the evolution from afar, one day it may be possible to integrate Crystal in WASM, acceptable compile times, maybe a productive main framework :)
For someone like me who never managed to make himself enjoy the Python syntax, Crystal seems like a great choice, and I realize I just forgot about it recently. If there's enough libraries available I might just dive in.
Rust doesn't have a garbage collector, meaning you have a steep learning curve around the borrow checker. Zig aims to be a C replacement, with manual memory management as well.
Nim is very close to Crystal. Some parts that might lead you to prefer Crystal however:
- Nim compiles to C code, meaning Nim is coupled to what C can do. I find compiling to C to be distasteful, C is not meant to be a compilation target. We should be getting away from C, IMO. Nim is limited to what C can achieve, and the design of the language trends towards "here's how this translates to C" as a result. Compiling to C is also an extra layer of abstraction, as now for instance with debugging you have to go through the C layer. Crystal like Rust uses LLVM
- Crystal also uses Ruby syntax, which many prefer. I have grown to dislike semantic whitespace such as how Python works, so this is a plus for me.
- Crystal has a garbage collector, period, and leans into that. Whereas Rust, Zig, and Nim want to give you complete control over memory, Crystal is more focused on being a better high-level programming language, competing with the likes of JVM/NET/Go/Ruby. This focus is likely Crystal's main edge. The only other single-executable opinionated GCed language is Go. Crystal's type system is much better than Go's. If Crystal can reduce compile times and capture some of Go's pragmatic aura, it will see more success.
Looks interesting! I'm always open to a statically type checked language.
This isn't about the language, but I was surprised to see that Nikola motors is a sponsor. Wasn't that company a fraudulent Hydrogen Fuel vehicle startup[1]? I wonder what the story is there- I find it hard to imagine anyone would be doing much software engineering at the company in the first place, even if it *were* working on the technologies they claimed to.
Yeah, and Meta uses Rust and contributed to a mass atrocity in Myanmar and is facing a $100BN+ lawsuit. Does that mean we should all stop using Rust because Meta is not only using it but also sponsoring the Rust Foundation as well?
That could be possible considering much of the language seems compatible. However, Crystal has incompatible accessor syntax for some reason. And concurrency is handled differently unless rails uses fibers everywhere. At this point they are way too different to just get away with syntax find/replace, it would require structural changes as well.
[+] [-] bb1234|3 years ago|reply
[+] [-] axelthegerman|3 years ago|reply
[+] [-] u89012|3 years ago|reply
1. Too slow to compile (the whole program + the entire stdlib is built everytime you build!). No incremental compilation available.
2. No language server (apparently it's just impossible due to the way the language works). Tbh, I'd be happy with just "Go to definition" but alas, no-can-do!
3. Obscure error messages (macros are to blame here)
4. Weak HTTP server implementation -- making things such as a fetching POST params or uploads incredibly frustrating. Once read the request body cannot be read again.
5. Weak/non-existent Windows support
6. No multicore support
7. Obviously small community
8. Nil handling takes a bit getting used to (coming from Ruby)
9. Error messages are hard to read with overloaded methods wherein just the types are used without any indication of what doesn't match
Overall, if the above changes, I'd switch to it in a heartbeat!
[+] [-] straight-shoota|3 years ago|reply
I feel like this is a bit strongly influenced by the macro experience. Macros are an advanced and powerful feature and naturally more complex to debug. In general, Crystal's error messages are often praised for their clarity and helpfulness (especially compared to dynamically typed languages, of course).
> 4. Weak HTTP server implementation -- making things such as a fetching POST params or uploads incredibly frustrating. Once read the request body cannot be read again.
The stdlib implementation of `HTTP::Server` is intentionally very bare-bones (many programming languages don't even have such a practically usable feature in stdlib). Specialized web server implementations are available as shards (https://shardbox.org/categories/Web_Frameworks). They're based on the foundation in stdlib and provide more advanced features.
> 5. Weak/non-existent Windows support
Windows support is pretty stable and almost complete by now.
> 6. No multicore support
Crystal has supported multi-threading as opt-in via the `-Dpreview_mt` flag. It's considered a preview, because it's to be used with care when dealing with data structures that are not thread-safe. But it has proven to work well in production use.
> 8. Nil handling takes a bit getting used to (coming from Ruby)
But once you're used to it, it's sooo much helpful. It just helps to avoid a lot of potential bugs which you would have to take extra care for in Ruby.
[+] [-] heynowheynow|3 years ago|reply
Alternatives: if you don't mind your eyes bleeding with C++-verbosity and tracking liveness yourself, there's Rust. Sure Go looks cute until you have a million users emailing you trivial questions they should've asked a group.
And if you want something similar to Crystal but with even stricter and more granular semantics than Rust with an even smaller community. there's Pony. It was built around the Orca GC. There's Nim too. Finally, one can use Haskell to built that critical payment service and maintain absolute job security. Meanwhile, the Erlang/Elixir OTP stack stays performant, although no one is quite sure how to package, deploy, and manage its lifecycle properly.
[+] [-] daptaq|3 years ago|reply
Emacs' dumb-jump appears to have some basic support for go to definition: https://github.com/jacktasia/dumb-jump/blob/master/dumb-jump...
But out of curiosity, what is the issue from a technical point of view?
[+] [-] bb1234|3 years ago|reply
This works on Doom Emacs!
[+] [-] freediver|3 years ago|reply
Crystal powers 90% of the Kagi search backend (reminder being Python). Highlights are great performance and concurency handling. Biggest downsides at this moment are compilation speed (does not take advantage of multi CPU cores) and debugging tools.
Overall our experience has been fantastic (we adopted it while still in beta) and the pace the language is developing is great.
[+] [-] widdershins|3 years ago|reply
Of course, no ads or trackers must help - when I look at the Network tab in developer tools the comparison with a google search is stark. ~4 requests vs. google's ~50.
[+] [-] californical|3 years ago|reply
Never would’ve expected it to be using Crystal though! That’s really neat. Are there open source bits? I’d love to see some enterprise-level Crystal examples
[+] [-] jm4|3 years ago|reply
[+] [-] simonebrunozzi|3 years ago|reply
p.s. hi Vlad :)
[+] [-] sph|3 years ago|reply
[+] [-] compumike|3 years ago|reply
https://github.com/compumike/crystal-docker-quickstart
For example, you may do:
Good luck and enjoy! :)I've written about Crystal before and am using it in production... see https://news.ycombinator.com/item?id=32216786 and https://news.ycombinator.com/item?id=32081943
[+] [-] bartmika|3 years ago|reply
From my experience so far Crystal feels like a performant language with the wonderful feel of Python. Definitely check this language out if this is the first time you're hearing about it.
[+] [-] reil_convnet|3 years ago|reply
[+] [-] straight-shoota|3 years ago|reply
To celebrate that there is going to be a live event next Monday: https://forum.crystal-lang.org/t/10-years-of-crystal-celebra...
We're exploring the history and future of the language with past and current core contributors as well as industry guests.
[+] [-] wing328hk|3 years ago|reply
Hopefully this will save you some time in manually creating the API clients in Crystal.
[1] https://openapi-generator.tech/
[+] [-] eric4smith|3 years ago|reply
However it really needs a bit of “wow” factor to take off.
We’ve used it here and there in dribs and drabs but don’t see a reason to use it in a new project when there is Elixir and/or Rust.
Elixir brings the easy to use concurrency almost automatically. This and other features make it almost unbeatable for web and backend stuff.
Rust is just as fast as crystal. Albeit harder to grok.
Python was literally saved by the numerical libraries. Or there would not be real reason to keep using it.
I keep one weather eye open on crystal to see how it’s doing but have seen no real reason to start a new project with it as yet.
For me the syntax is not reason enough as yet. Elixir is maybe easier and functional to boot. Being object oriented in 2022 is not a good reason either.
I’m an old rubyist and I wish Crystal the best. I’ve been following it since it was a gleam in the eye, But … why? And for what??
[+] [-] mgarciaisaia|3 years ago|reply
Back when I joined Manas.Tech and learnt about Crystal, THE wow factor for me was the way `if` constraints optional types when you check it: https://crystal-lang.org/reference/1.5/syntax_and_semantics/...
That provides you the flexibility of having union types (variable may be `Thing1` or `Thing2`) for generic purposes, AND type-safetiness (is that a word?) when dealing with specific paths of your program that apply differently to some of the subtypes of the variable.
I think Swift and Kotlin support (some of?) that now. It was really new for me back in the day (around 2014?).
But that's from a coding point of view - not that much about niches, as you talk about.
[+] [-] siproprio|3 years ago|reply
By the way, how are we on data-science friendly IDEs? Debugging? Automatic thorough documentation generator? Tooling in general? Is the time to first plot fast?
Where I work, we desperately need a fast python.
[+] [-] kimburgess|3 years ago|reply
There's some interesting things you can do with the type system too, like capturing dimensionality in the type: https://git.sr.ht/~kb/matrix/tree/main/item/src/matrix.cr
One missing item though is SIMD support: https://github.com/crystal-lang/crystal/issues/3057
Re docgen - that's built into the compiler: https://crystal-lang.org/reference/1.5/syntax_and_semantics/...
[+] [-] mumblemumble|3 years ago|reply
ML and data engineering is a different story, of course. Also, I wouldn't be surprised if something clever could be done with a structural type system.
[+] [-] e12e|3 years ago|reply
It sounds like Julia would be a better fit than Crystal?
Ironically they have similar problems: compile/start-up time (though crystal has working ahead of time compilation - AFAIK Julia developers are still working on speeding up "first run" in various ways).
[+] [-] db65edfc7996|3 years ago|reply
[+] [-] dj_mc_merlin|3 years ago|reply
Full multi tasking, POSIX compliant yadda-yadda actual OS written in Crystal. The author was also apparently in high school at the time.
[+] [-] juanse|3 years ago|reply
As other said, it just needs a push and a few more important libraries. Really wishing that finally takes off.
[+] [-] nine_k|3 years ago|reply
The language is nice though. It seems like it would benefit from a bit more publicity.
[+] [-] nTalle|3 years ago|reply
Among the problems :
- A too long compilation. For 2 projects, the compilation in dev env takes more than 30 seconds for each compil, the developer experience is dead at this cadence.
- IDE integration: auto-completion, go to def, API docs, etc works when it wants (almost never).
- The community is too small which results in a lack of docs, examples, help. I spent days searching in Github projects, just to see examples of basic things.
- Instead of focusing on a main framework that makes everyone agree, everyone makes their own framework, their own libs (including me). The result is a lot of time and energy spent on duplicate packages and frameworks that are not necessarily maintained.
I continue to follow the evolution from afar, one day it may be possible to integrate Crystal in WASM, acceptable compile times, maybe a productive main framework :)
[+] [-] jbirer|3 years ago|reply
[+] [-] didip|3 years ago|reply
[+] [-] mumblemumble|3 years ago|reply
[+] [-] bovermyer|3 years ago|reply
It's easy to write, and comparable in performance to Go and similar.
Rust, Zig, and Nim are solving different problems.
[+] [-] frou_dh|3 years ago|reply
[+] [-] kinjba11|3 years ago|reply
Nim is very close to Crystal. Some parts that might lead you to prefer Crystal however:
- Nim compiles to C code, meaning Nim is coupled to what C can do. I find compiling to C to be distasteful, C is not meant to be a compilation target. We should be getting away from C, IMO. Nim is limited to what C can achieve, and the design of the language trends towards "here's how this translates to C" as a result. Compiling to C is also an extra layer of abstraction, as now for instance with debugging you have to go through the C layer. Crystal like Rust uses LLVM
- Crystal also uses Ruby syntax, which many prefer. I have grown to dislike semantic whitespace such as how Python works, so this is a plus for me.
- Crystal has a garbage collector, period, and leans into that. Whereas Rust, Zig, and Nim want to give you complete control over memory, Crystal is more focused on being a better high-level programming language, competing with the likes of JVM/NET/Go/Ruby. This focus is likely Crystal's main edge. The only other single-executable opinionated GCed language is Go. Crystal's type system is much better than Go's. If Crystal can reduce compile times and capture some of Go's pragmatic aura, it will see more success.
[+] [-] sph|3 years ago|reply
In some applications memory allocation is not that important, so it's nice not having to think about it at all.
I've gone deep into Rust recently, but Crystal might still eat Python's lunch, a language I've fallen out of love with.
[+] [-] insane_dreamer|3 years ago|reply
I use Python for work because of the math/sci libraries and ecosystem, but would otherwise use a Ruby-inspired language.
[+] [-] robertlagrant|3 years ago|reply
[+] [-] jasinjames|3 years ago|reply
This isn't about the language, but I was surprised to see that Nikola motors is a sponsor. Wasn't that company a fraudulent Hydrogen Fuel vehicle startup[1]? I wonder what the story is there- I find it hard to imagine anyone would be doing much software engineering at the company in the first place, even if it *were* working on the technologies they claimed to.
[1] https://www.youtube.com/watch?v=88fWUZhYb04
[+] [-] straight-shoota|3 years ago|reply
[+] [-] eric4smith|3 years ago|reply
Just because the Pr0n industry overwhelmingly uses PHP does not mean People should not use PHP.
Bad people use good tools too.
[+] [-] rvz|3 years ago|reply
I think you know the answer.
[+] [-] revskill|3 years ago|reply
[+] [-] straight-shoota|3 years ago|reply
* https://github.com/spider-gazelle/spider-gazelle
* https://luckyframework.org/
[+] [-] nurettin|3 years ago|reply
[+] [-] zw963|3 years ago|reply
https://github.com/luckyframework/lucky
Development by folks come from thoughtbot.
[+] [-] chaosprint|3 years ago|reply
[+] [-] haarts|3 years ago|reply
I expect full WASM support in the near future.
[+] [-] TwentytwoSeven|3 years ago|reply
[deleted]