Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Crystal Programming Language

crystal-lang.org

Post reply on HN
Print view View original

71–80 of 116 posts

Re: The Crystal Programming Language

#71

Post by straight-shoota »

u89012 wrote: post #61

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…

> 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.

Re: The Crystal Programming Language

#72

Post by u89012 »

daptaq wrote: post #64
u89012 wrote: post #61

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…

> 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! 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?

Good to know. I've got zero emacs skills and I'm on vscode and nothing works there. From what I understand the lack of type info until the whole program is compiled creates this issue.

Re: The Crystal Programming Language

#73

Post by Nextgrid »

freediver wrote: post #45
widdershins wrote: post #38

Earlier quoted context omitted.

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.

We obssess over performance, thanks for noticing that :)

I find Kagi consistently faster to respond than DDG.

Re: The Crystal Programming Language

#74

Post by kitd »

sph wrote: post #55
freediver wrote: post #32

Huge props for the Crystal lang team. 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.

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...

Not OP, but the concurrency model is similar to Go with its use of channels. At the moment the runtime is single-core, but the chosen model should permit multi-core (when they enable it by default) with little to no changes to user source.

Tbh, I prefer it that way round than try to retrofit multi-core onto a model that wasn't designed for it. But yes, single-core feels a bit behind the curve in 2022.

Re: The Crystal Programming Language

#75

Post by heynowheynow »

u89012 wrote: post #61

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…

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.

Re: The Crystal Programming Language

#76

Post by straight-shoota »

sph wrote: post #55
freediver wrote: post #32

Huge props for the Crystal lang team. 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.

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...

concurrency != multi-threading.

Crystal's concurrency is based on fibers (green threads) which works very well even on a single thread (it scales to multiple threads, as well)

And for many use cases with high parallelization and little shared state (including web applications such as a search engine), multi-threading isn't necessary. Synchronization overhead is a serious performance killer. You can get much more performance out of running N processes with a single thread instead of a single process running N threads.

Re: The Crystal Programming Language

#77

Post by heynowheynow »

straight-shoota wrote: post #66
daptaq wrote: post #64

Earlier quoted context omitted.

> 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! 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?

The technical challenge is that a Crystal program needs to be inspected as a whole. Simplified, changes in location A can have effects on some completely unrelated location B. That makes it hard to cache intermediary results and a semantic analysis needs to cover the entire program (including the standard library), not just the files that were changed since the last time. This applies to the responsiveness and memory…

This is the same problem with Ruby, Python. or any interpreted language.

What most LSPs do is approximate it rather than worry about perfection and deliver nothing.

Re: The Crystal Programming Language

#79

Post by straight-shoota »

jjtheblunt wrote: post #25
axelthegerman wrote: post #13

Earlier quoted context omitted.

Probably because of the Ruby inspired syntax which just brings joy. Hopefully the ecosystem can grow and partially catch up as well

i've seen that said so many times, and fail to understand why Ruby syntax brings joy. Personally, I thought the muddled Proc, block, and lambda situation a mess, coming from Scheme 30 years ago to Ruby 20 years ago.

I can gladly point out that Crystal has a much cleaned up syntax for blocks and procs (compared to Ruby): https://crystal-lang.org/reference/1.5/syntax_and_semantics/...

Re: The Crystal Programming Language

#80

Post by heynowheynow »

db65edfc7996 wrote: post #4
bovermyer wrote: post #3

Earlier quoted context omitted.

Crystal's performant enough, but its key differentiating feature is its Ruby-like syntax. It's easy to write, and comparable in performance to Go and similar. Rust, Zig, and Nim are solving different problems.

Nim and Crystal feel like they are in exactly the same space? GC, fast, single executable compilation without runtime (I would also throw Go into this list).

Pony does stricter sharing semantics than Rust (multicore) with actors and allegedly one of the fastest GCs ever developed. Its community is even smaller than Crystal's. Pony was developed essentially as a PoC to demonstrate the GC.
Post reply on HN