Parallelism in Crystal (opens in new tab)

There's actually a surprising amount available in the stdlib for your typical web project. By way of example, I'd always hated how in Ruby each API wrapper gem would make their own decision on which HTTP client they used, so you could end up pulling in 3 or 4 separate libraries just to make HTTP calls to a 3rd party API. People may disagree but I think this is (was?) largely due to Ruby's Net:HTTP feeling janky to use, at least compared to Faraday and the like. Here, the HTTP modules within the standard library feel right, and I've not needed to reach out for all that much from the ecosystem.

But as a simple example I accept that API calls to third party services is low hanging fruit so in terms of finding drivers for lower level protocols I've not had an issue that I'd class as a blocker. There are times where I've had to extend libraries or write a parser for this-and-that (e.g. PostGIS and Paseto, both of which were unused this time round) but I find I need to do this less and less as time goes on.

You do need to reach into the forums or gitter on rare occasions but I can count on one hand the number of times I've needed to, and it's typically because I was trying to do something unusual and quite low-level on the HTTP stack - as in something I've never had to do in a non-Crystal project, such as sending a specific packet. I've always found help there too and people are happy to engage.

It's obviously far smaller, but I've had luck so far with everything I need being available. What I've seen, mostly Postgres, Redis, and XML/HTML parsing, have also worked flawlessly so far.

Having performance improvements of 100x in real-world scenarios is just astonishing. Ruby is still my go-to, especially because debugging and console support are so much better. But everything that gives me time to think gets reimplemented.

["crystal lang" <question>] usually works for google.

Not yet but not far off... It's an e-learning platform and student management system, backed by postgres and fronted with React. For the most part it has worked well but I need to do a bit more tightening up before I'm happy releasing it into the wild.

The Crystal underbelly is here https://github.com/rishavs/noir

the api is consumed by a vanilla js spa. I talk more about my VanillaJS spa's architecture here https://dev.to/rishavs/making-a-single-page-app-in-ye-good-o...

That's nonsensical. There is surely at least as much synchronization overhead with 4 threads as with 2.

> Because it's a much saner, coherent, and easier to use language with less footguns...

Which for parallelism probably switches the question to “why Crystal over Pony”, since Crystal seems to preserve the key C++ footguns specifically linked to parallelism.

> and, if we're realistic, it might never go anywhere...

I don’t see why this should be the case, unless we as a community decides it will not go anywhere.

Because you are tying yourself to a specific ISA. This is bad even within the same chip family. If you want to migrate your x86 32 bit code to 64 bit then you have to rewrite everything.

I’m asking because they presented Crystal as Ruby with OOP and high performance. I’m asking because I’m curious, is it the ruby syntax that much better?