| ▲ | sumnole 7 hours ago |
| For those that don't know: Crystal is like a typed Ruby with the performance and concurrency flow of Go. |
|
| ▲ | Shorel 6 hours ago | parent | next [-] |
| That actually sounds awesome. Mainly because normal Ruby is an awesome language to write code, and it is also a language that's tried and lost the spotlight because its performance is really, really low, even when compared only with other interpreted languages. |
| |
| ▲ | kenhwang 2 hours ago | parent [-] | | Ruby caught a second wind when they started putting effort into their JIT, which in our testing made it quite a bit faster than every interpreted language except JS in real world performance. But then Python got a second wind in performance with better rewrite in Rust integration, but it looks like with the latest DHH keynote, Ruby might also go down that path. My opinion is that I/O and concurrency ease of use and performance continues to be Ruby's weak point vs other interpreted languages. Which also happens to be Go's very few strong points. |
|
|
| ▲ | onlyrealcuzzo 6 hours ago | parent | prev | next [-] |
| > Crystal is like a typed Ruby with the performance and concurrency flow of Go. I'm not up to date, but the scheduling engine was far behind Go in terms of parallelism. Crystal was always quite good at concurrency. But Go is popular because it's so good at parallelism (and relatively safe with a garbage collector). I know Crystal has been working on this for the last few releases, but I'd be surprised if it's matching Go on parallelism. Go's runtime is quite the engineering feat. It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages... |
| |
| ▲ | straight-shoota 2 hours ago | parent | next [-] | | Crystal core dev speaking. In the previous release (1.21) we enabled Execution Contexts as a parallelism engine.
https://crystal-lang.org/2026/07/12/releasing-execution-cont... It's even more flexible than Go because you can tune different contexts for specific workloads.
Go still has more advanced optimizations and overall better thread-safety in libraries. But we're working on that... | |
| ▲ | pjmlp 4 hours ago | parent | prev | next [-] | | Go is popular because Docker and Kubernetes made it popular, and it was designed by UNIX idols. If only it had a few more features from 1970's languages, designed outside Bell Labs, or even those from Limbo that it still doesn't support. | |
| ▲ | giancarlostoro 5 hours ago | parent | prev | next [-] | | Goroutines are roughly 2kb in memory, and Crystal fibers are roughly 4KB, which is insane in any regard. I think Crystal is really interesting and worth considering, especially if you want something native that has OOP, I really would love to see Crystal used more in general. | | |
| ▲ | ButlerianJihad 5 hours ago | parent [-] | | That is especially insane, when we consider that "B" means "bytes" while "b" means "bits", and "kb" means 1,000 bits, while "KB" means 1,024 bytes (8,192 bits)! Happy International Caps Lock Day!!1 | | |
| ▲ | giancarlostoro 2 hours ago | parent [-] | | The one time I don't double check my capitalization for bytes vs bits... The sad thing is I usually double check as I type them, must have been in the middle of something and not noticed. |
|
| |
| ▲ | goatlover 5 hours ago | parent | prev | next [-] | | Does it outperform Erlang/OTP? | |
| ▲ | DetroitThrow 6 hours ago | parent | prev [-] | | >It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages... I will say this comes with the asterisk that it heavily depends on what your concurrent system/problems looks like! ...but more often than not when dealing with web problems and network IO, the shape of concurrency/parallelism I need looks exactly like Goroutines, and even as someone who uses Rust/tokio daily: the Go runtime is an incredibly engineered system that usually beats Rust in my experience for application dev tasks. Anyways, I love Crystal's syntax around concurrency! I wish we lived in a world where it had tons of Google engineers optimizing the runtime :) |
|
|
| ▲ | flossly 5 hours ago | parent | prev | next [-] |
| ...and a community the size of Elm. |
|
| ▲ | sevenzero 7 hours ago | parent | prev [-] |
| [flagged] |
| |
| ▲ | bdcravens 7 hours ago | parent | next [-] | | If you mean pre-packaged jobs in that specific language, you're correct. However, if you're a Rubyist needing native performance, it's another tool in your toolbox. | |
| ▲ | nilamo 6 hours ago | parent | prev | next [-] | | AI killed the language wars. Now you can use whatever you want for whatever you want, wherever you want. Which means you can have fun trying new languages with every new project :) | | |
| ▲ | sevenzero 6 hours ago | parent | next [-] | | Yea but that doesnt help with companies still hiring for language specific roles. Also you gotta be able to check LLM generated code which requires proficiency in the given language. | |
| ▲ | Thaxll 6 hours ago | parent | prev [-] | | It's not true though, languages have different level of maturity in different domains. If you ask Claude create me a Crystal controller for Kubernetes, good luck with that. |
| |
| ▲ | jcmontx 6 hours ago | parent | prev | next [-] | | It's another tool in the belt. You don't have to be an AH about it | |
| ▲ | lirolero 7 hours ago | parent | prev [-] | | [dead] |
|
