3 ms·

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 who

by u89012 4y ago

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!

daptaq 4y ago
> 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.el#L701 https://github.com/jacktasia/dumb-jump/blob/master/dumb-jump... But out of curiosity, what is the issue from a technical point of view?
- straight-shoota 4y ago
  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 consumption of the language server as well as the regular compilation process. So this is an important topic, and we're working on improvements. It's a complex topic, but there are some ideas.
  - heynowheynow 4y ago
    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.
    - zw963 4y ago
      I totally agree with this idea, Crystal core member seems to think less of it from a beginner programmer's perspective.
- u89012 4y ago
  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.
straight-shoota 4y ago
> 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 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.
- svnpenn 4y ago
  > Windows support is pretty stable and almost complete by now. This isn't really a genuine statement. Currently Crystal Requires a full installation of Visual Studio on Windows: https://github.com/crystal-lang/crystal/issues/6170 https://github.com/crystal-lang/crystal/issues/6170
  - beta-ziliani 4y ago
    It just requires the build tools. If you use scoop, that entails to: > run `scoop install vs_2022_cpp_build_tools` (from the "required libraries" link in https://crystal-lang.org/install/on_windows/ https://crystal-lang.org/install/on_windows/)
    - 4y ago
heynowheynow 4y ago
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.
bb1234 4y ago
> 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! This works on Doom Emacs!

by u89012 4y ago

daptaq 4y ago

> 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.el#L701 https://github.com/jacktasia/dumb-jump/blob/master/dumb-jump... But out of curiosity, what is the issue from a technical point of view?

straight-shoota 4y ago
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 consumption of the language server as well as the regular compilation process. So this is an important topic, and we're working on improvements. It's a complex topic, but there are some ideas.
- heynowheynow 4y ago
  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.
  - zw963 4y ago
    I totally agree with this idea, Crystal core member seems to think less of it from a beginner programmer's perspective.
u89012 4y ago
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.

straight-shoota 4y ago

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

svnpenn 4y ago
> Windows support is pretty stable and almost complete by now. This isn't really a genuine statement. Currently Crystal Requires a full installation of Visual Studio on Windows: https://github.com/crystal-lang/crystal/issues/6170 https://github.com/crystal-lang/crystal/issues/6170
- beta-ziliani 4y ago
  It just requires the build tools. If you use scoop, that entails to: > run `scoop install vs_2022_cpp_build_tools` (from the "required libraries" link in https://crystal-lang.org/install/on_windows/ https://crystal-lang.org/install/on_windows/)
  - 4y ago

heynowheynow 4y ago

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.

bb1234 4y ago

> 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! This works on Doom Emacs!