5 ms·

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

by deedubaya 8y ago

patagonia 8y ago
That just seems nuts in a world where AMD is putting out affordable 32 core chips.
- weberc2 8y ago
  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?
  - kjeetgill 8y ago
    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.
    - weberc2 8y ago
      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.
    - sriram_malhar 8y ago
      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.
    - jashmatthews 8y ago
      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.
- vesak 8y ago
  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 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?
arthurcolle 8y ago
My head shakes with confusion
- vanderZwan 8y ago
  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.
  - devmunchies 8y ago
    > just because concurrency isn't fixed yet concurrency works great in Crystal. Its "parallelism" that they don't have yet.
  - kjeetgill 8y ago
    No one's saying don't release what's good. They're just saying parallelism is worth delaying the big 1.0 for.
    - vanderZwan 8y ago
      Ah, I understood it as "concurrency (actually parallellism, thanks devmunchies) is delayed until the big 1.0"
newtonapple 8y ago
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 https://news.ycombinator.com/item?id=13213619. But, Windows support might be held back: https://dev.to/dougeverly/comment/lob https://dev.to/dougeverly/comment/lob.

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

patagonia 8y ago

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

weberc2 8y ago
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?
- kjeetgill 8y ago
  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.
  - weberc2 8y ago
    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.
  - sriram_malhar 8y ago
    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.
  - jashmatthews 8y ago
    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.
vesak 8y ago
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 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?

arthurcolle 8y ago

My head shakes with confusion

vanderZwan 8y ago
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.
- devmunchies 8y ago
  > just because concurrency isn't fixed yet concurrency works great in Crystal. Its "parallelism" that they don't have yet.
- kjeetgill 8y ago
  No one's saying don't release what's good. They're just saying parallelism is worth delaying the big 1.0 for.
  - vanderZwan 8y ago
    Ah, I understood it as "concurrency (actually parallellism, thanks devmunchies) is delayed until the big 1.0"

newtonapple 8y ago

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 https://news.ycombinator.com/item?id=13213619. But, Windows support might be held back: https://dev.to/dougeverly/comment/lob https://dev.to/dougeverly/comment/lob.