Hacker News Reader

Comment by deedubaya | Hacker News Reader

iirc, it was removed/postponed to make reaching 1.0 more obtainable

That just seems nuts in a world where AMD is putting out affordable 32 core chips.

I'm a big fan of shared memory parallelism from a performance standpoint, but I don't see any reason why v1.0 of a language must support this. Stable APIs enable a lot more than shared memory parallelism, which is, for the most part, a performance optimization. If you can delay the parallelism story by a few months to move the stability story up a year, why not?

I would call it much more than just a performance optimization.

A good story on parallelism is fairly high on anyone's list looking to move away from a GIL language like Python and I believe Ruby.

As I'm sure you're aware, parallelism isn't always easy to bolt on afterwards. Once a glut of your code is written violating your (unwritten) memory model you're never quite sure if you've gotten rid of that last race condition.

You're describing a performance optimization. Yes, if you write unoptimized code, it often takes some refactoring to support the optimization. Also, Python and Ruby are proof that languages can be tremendously successful at solving a huge array of problems without shared memory parallelism in v1.0. Besides, Crystal is presumably much faster than either of these languages with a single thread, so the relative advantage of (CPU) parallelization is much less.

Crystal's programming model is about concurrent actors that don't share memory. Nothing should break when they move to multiple threads/event loops; it just needs the scheduler to schedule multiple fibers onto different threads. It's a solved problem.

It's actually pretty low on the list. Ruby already has a production-ready implementation without a GIL: JRuby.

Normal workloads like serving web requests or processing background jobs aren't impacted by the GIL. You simply run one process per core just like with NodeJS. Huge, huge sites successfully run on Ruby/Python. YouTube, GitHub, AirBnB, ZenDesk, Zapier etc.

Larry Hasting's has some talks online on the Python GILectomy. The major issues are around how to keep the VM simple and fast. IUUC the C extension issues are fairly minor in comparison because the GIL never guaranteed much anyway.

There are very few cases where threading is essential, where you cannot work just with communicating processes. I cannot think of anything but FPS games (perhaps you can).

Crystal already has fibers, eventloop and CSP-style channels. See https://crystal-lang.org/docs/guides/concurrency.html

All languages don't have to be good at everything. See IEEE 2018 top programming languages list puts Python at the top. How's its parallelism story these days?

Do you have a reference to this? As far as I'm can tell, core devs are still aiming to ship parallelism w/ 1.0: https://news.ycombinator.com/item?id=13213619. But, Windows support might be held back: https://dev.to/dougeverly/comment/lob.

My head shakes with confusion

Why? If they wait with releasing new versions because of a big blocking thing (concurrency) even though there are other things to fix and improve at the same time, they might lose people from the community. If your language is in beta you want to keep polishing a language as it develops, and keep making it easier for the users.

I see no reason not to release these changes to the world just because concurrency isn't fixed yet:

> This release is focused on polishing APIs, bug fixing the compiler, keep working on windows support and some intermediate language changes for future releases. There were 119 commits since 0.25.1 by 24 contributors.

> just because concurrency isn't fixed yet

concurrency works great in Crystal. Its "parallelism" that they don't have yet.

No one's saying don't release what's good. They're just saying parallelism is worth delaying the big 1.0 for.

Ah, I understood it as "concurrency (actually parallellism, thanks devmunchies) is delayed until the big 1.0"

Reply on news.ycombinator.com