Is it just me, or does Crystal have a disproportionate amount of Windows demand? I feel like every time Crystal comes up, someone asks (or complains) about Windows support.
I sponsored a bunch of work on this years back; I wanted it so I didn't have to use Go for cross-platform binaries for a CLI client. I ended up having to use Go, but I hope one day it ships so I can avoid it a little more (I don't hate it, but prefer crystal).
I don't think it's disproportionate. Windows is a huge platform with lots of developers. Also you don't hear anyone asking for other OS support because all other major operating systems are supported. So there's no real comparison.
Crystal is a nice language to write utilities with. Usually with utilities you want to distribute it to other people, many of them can't just install the whole toolchain to run the code. So naturally we want a fully portable windows exe file that can be run independently.
Used VS since 2001. Then started developing on Linux and Mac, which I prefer. But here you don't need the full VS installation, only the build tools and Windows 10 SDK, and apparently it can be installed by a script. It's a non issue. Otherwise use WSL then you won't need VS https://crystal-lang.org/install/on_wsl/
# A very basic HTTP server
require "http/server"
server = HTTP::Server.new do |context|
context.response.content_type = "text/plain"
context.response.print "Hello world, got #{context.request.path}!"
end
puts "Listening on http://127.0.0.1:8080"
server.listen(8080)
Nicely concise!
This would be the Python equivalent:
# A very basic HTTP server
from http.server import BaseHTTPRequestHandler, HTTPServer
class RequestHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header('Content-type', 'text/plain')
self.end_headers()
self.wfile.write(bytes(f"Hello world, got {self.path}!", 'utf8'))
httpd = HTTPServer(('', 8080), RequestHandler)
print("Listening on http://127.0.0.1:8080")
httpd.serve_forever()
1: The comment
2: Printing the status message ("Listening on ...")
3: Outputting "Hello world, got {request.path}!"
Aka http request parsing and string extrapolation.
I couldn't quite determine the reason of being of the Crystal language. Could someone with experience with the language explain what is its appeal, and why it would be worth trying/learning?
Crystal is basically taking Ruby and adding compilation and a strong static type system.
I enjoy writing it but don’t think there’s any particular reason to try/learn it, unless you happen to also be a ruby dev who prefers compiled, strongly typed languages.
Why would a language need a specific reason to exist? It's a nice language with Ruby-ish syntax, strict typing, a go-like runtime and it compiles down to something quite fast if you take a little bit of care.
I interpret the question less as asking for justification for why it exists and more as wanting to learn what problems it ought to be used to solve because of an interest in putting it in one's "toolbox" as it were.
To me, it kind of sits between Golang and Rust in terms of intent. I think the goal is to deliver reliable runtime characteristics at the speed of a compiled language, while generally only demanding as much specificity as higher-level interpreted languages (i.e. Ruby). For me I reach for it when I want something that's fast (like go or Rust) but which I can write quickly (like Python or Ruby).
Reason; no idea - but the appeal for me is it's very ruby-like, and super fast (except, compiling). Some programs I've moved from ruby use >10x less memory, and are generally faster. It's mostly as a nice to write as ruby, except the compile time. Concurrency is very go-like, and there are a reasonable amount (not ruby-like though) level of libraries for use.
As far as I understand, work on Crystal started when Ruby on Rails was the hottest web framework. The original purpose was going to be running your RoR apps that outgrew MRI. Yes, code would have to be adapted to run on Crystal, but that would be much easier than rewriting everything in a completely new language.
My understanding, it's ruby like, but statically typed and compiled. Basically instead of trying to retrofit ruby with these features without breaking things (like Shopify and friends do with JITs, AOTs, sherbert, etc), this is bottom up approach around these features.
Due to it's infancy the packages are sparse, so what some people do is a hybrid approach, where they write their thing in Ruby/Rails and kick out the slower parts to Crystal. This kinda gives the best of both worlds. Crystal (last I checked) had slow compile times, so gives you the dev velocity and package availability of ruby, plus the speed of a compile language when you need it. The compile times on Crystal stay low because you're only writing a small parts/microservices of your application in Crystal.
> where they write their thing in Ruby/Rails and kick out the slower parts to Crystal
What's the story on Crystal/Ruby interop these days? I work on a Rails app that does document automation, and I could definitely find some specific < 1000 LOC segments that would benefit hugely from being 1:1 rewritten into Crystal and integrated with the rest of the app.
It generates efficient code (similar to a C program, e.g. you could write a reasonable ray tracer), and is concise. Many Ruby programs would not see a size expansion from being written in Crystal. It's also good at interoperating with C programs; it's employs LLVM in a fairly orthodox manner (so, for example, if you run `perf` under Linux, you will get good symbolic output)
I think the Achilles heel for Crystal is its compilation time on small programs with large dependencies. Note the time to build the entire compiler and standard library is not extraordinary for a large program. It's more like, a small program adding its first few dependencies will find itself pulling in a lot of the standard library to compile, and then will level off in its compilation time.
To illustrate why this may be the case, consider the Crystal feature allowing redefining parts of classes, including ones in the standard library. This is both very useful, and if you think about how it affects features like incremental compilation, immensely complicating.
Here's some practical crystal programs.
This Postgres wire protocol driver is comparable to libpq in performance, and supports a lot of features in the protocol, too:
https://github.com/will/crystal-pg/
I have been running https://mailflowmonitoring.com for the past 6 years on Amber (A Crystal framework) it flawlessly manages the sending and tracking of round trip emails for tens of thousands of pings a day.
84 comments
[ 2.9 ms ] story [ 161 ms ] threadWhat's the state of Windows support.
How did the compiler speed drama unfold?
https://github.com/crystal-lang/crystal/issues/5430
> UPDATE 2023-04-24:
> All the main platform features for Windows are finished!
> There are still some smaller stories pending. Project board: https://github.com/orgs/crystal-lang/projects/11/views/5
> You can support the ongoing development financially: Windows suppport (https://opencollective.com/crystal-lang/projects/windows-sup...) project on Open Collective.
The same thing was happening with Bun, and yet I've met lots of Windows developers who hate JavaScript.
I'll enjoy my time here when I can get it.
I don't think it's disproportionate. Windows is a huge platform with lots of developers. Also you don't hear anyone asking for other OS support because all other major operating systems are supported. So there's no real comparison.
https://crystal-lang.org/install/on_windows
https://forge.rust-lang.org/infra/other-installation-methods...
- words or lines taken from a book or a speech
- an official statement about something special that somebody has done, especially about acts of courage in a war
- an act of citing or being cited
- an order to appear in court
https://www.oxfordlearnersdictionaries.com/definition/englis...
Consider I am citing myself.
> The best tooling for each OS is the one from the OS vendor themselves.
and here is their defense of that position:
> As per Oxford Learner's Dictionaries
because yes, the dictionary is the correct place to find information about operating systems. LOL
Also, the MSVC compiler itself often produces much worse code than clang or gcc. I am regularly astonished by its stupidity.
> let alone everything else expected from Windows applications across the board.
For example?
https://github.com/mstorsjo/llvm-mingw
https://packages.msys2.org/base/mingw-w64-gcc
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
This would be the Python equivalent:
Would like to see it in more languages.Which companies use Crystal in anger / production in front of real users?
Mentioned in the crystal conf talk held by a Kagi Developer
https://youtube.com/r7t9xPajjTM
Also, >300 MB of RAM usage (in docker. Some might be the system) with only 2 users after running for a while seems a bit too much
I’m not the first one facing these issues.
https://crystal-lang.org/reference/1.11/index.html
I couldn't quite determine the reason of being of the Crystal language. Could someone with experience with the language explain what is its appeal, and why it would be worth trying/learning?
Thanks!
I enjoy writing it but don’t think there’s any particular reason to try/learn it, unless you happen to also be a ruby dev who prefers compiled, strongly typed languages.
Thank you!
Due to it's infancy the packages are sparse, so what some people do is a hybrid approach, where they write their thing in Ruby/Rails and kick out the slower parts to Crystal. This kinda gives the best of both worlds. Crystal (last I checked) had slow compile times, so gives you the dev velocity and package availability of ruby, plus the speed of a compile language when you need it. The compile times on Crystal stay low because you're only writing a small parts/microservices of your application in Crystal.
What's the story on Crystal/Ruby interop these days? I work on a Rails app that does document automation, and I could definitely find some specific < 1000 LOC segments that would benefit hugely from being 1:1 rewritten into Crystal and integrated with the rest of the app.
Http micro service, IPC, or FFI.
There were some attempts to do inline crystal, like what Mojo does in Python, but I don't know if any of them became stable long term solutions.
There's probably a way to get native C ext speed, you can see an old attempt here:
https://www.akitaonrails.com/2016/07/06/trying-to-match-c-ba...
But at any rate, it'll be better than ruby.
I think the Achilles heel for Crystal is its compilation time on small programs with large dependencies. Note the time to build the entire compiler and standard library is not extraordinary for a large program. It's more like, a small program adding its first few dependencies will find itself pulling in a lot of the standard library to compile, and then will level off in its compilation time.
To illustrate why this may be the case, consider the Crystal feature allowing redefining parts of classes, including ones in the standard library. This is both very useful, and if you think about how it affects features like incremental compilation, immensely complicating.
Here's some practical crystal programs.
This Postgres wire protocol driver is comparable to libpq in performance, and supports a lot of features in the protocol, too: https://github.com/will/crystal-pg/
The Crunchy Bridge CLI: https://github.com/CrunchyData/bridge-cli
- compiled so easy to deploy
- easy to write compared to Rust, when you don't care about being super reliable
- still keeps things typed and better than in Ruby
- lower memory usage than Ruby/Python (and usually an easy 10x jump in performance)
I'm relying on it a lot with simple lambda automation. If I wanted to write an efficient server, I'd probably use rust though.
https://crystal-lang.org/reference/1.11/guides/concurrency.h...
https://crystal-lang.org/2019/09/06/parallelism-in-crystal/