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.
The Crystal Programming Language
91–100 of 116 posts
Re: The Crystal Programming Language
#92Earlier quoted context omitted.
> 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…
> 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
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/)
Re: The Crystal Programming Language
#93Huge 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.
Funny, I submitted this on HN because I've read that Kagi is powered by Crystal, and then went and took a look at it.
p.s. hi Vlad :)
Re: The Crystal Programming Language
#94Earlier quoted context omitted.
I think that’s too expansive of a definition of “runtime.” The context required by C and Rust programs is generally internal, meaning that interacting with the dynamic allocator doesn’t require the programmer to be aware of the implementation’s invariants. This is in contrast to a managed language like Java, where using a managed object from C via JNI requires coordination with the runtime (which in turn preserves th…
But you have to know that as well for C - there are for example several Linux system calls you really should not call manually because that would fuck up the internal state in LibC. Yes, the runtime is really small, comparatively speaking, but it is still a runtime.
Which system calls are you thinking of? The only ones that I can think of would be brk(2) and sbrk(2), but any recent libc should be resilient to calls to those.
That being said, I'll grant that the distinction between "tiny runtime" and "no runtime" isn't useful and that C can be said to have a runtime insofar as most systems provide a `crt0` or equivalent.
Re: The Crystal Programming Language
#95Earlier quoted context omitted.
> 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
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/ )
That just installs Visual Studio:
https://github.com/neatorobito/scoop-crystal/blob/main/bucke...
no thank you.
Re: The Crystal Programming Language
#96Points for the syntax and speed. 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.…
(Manas.Tech employee here)
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.
Re: The Crystal Programming Language
#97Earlier quoted context omitted.
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 sys…
Static typing is like salt, sprinkle a little bit and it enhances and gives flavor to your food. Too much of it and it completely ruins the dish.
Why would you want "a little" static typing? What does that mean? I used to write python in vim and hated it, made tons of mistakes that were time consuming to find. Type hinting religioussly and using pylance in vscode sped me up a great deal. But I still make those mistakes sometimes, and they are still troublesome to find. Sometimes they pass unit tests because the types are off in the test too. I think a compiled strongly and statically typed language with excellent type inference is the best of both worlds, freedom with a safety net. The problem with interpreted or jit languages is that even with strong typing, inference won't save you until runtime. I'm enjoying julia, but finding type errors at runtime is a downside.
Re: The Crystal Programming Language
#98Re: The Crystal Programming Language
#99Earlier quoted context omitted.
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.
I totally agree with this idea, Crystal core member seems to think less of it from a beginner programmer's perspective.
Re: The Crystal Programming Language
#100Earlier quoted context omitted.
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 perf…
Hope a lot of people can see this, detailed explanation come from Crystal core developers.
because a lot of beginners complain that Crystal's fiber doesn't work on multiple cores/multiple threads and then give up using it, it's probably not as important as people think.
Even many beginners mistakenly believe that the Crystal language does not support the creation of operating system native Thread， this is a huge misunderstanding for Crystal.