6 ms·

I'm confused about the state of threading in Crystal. See the last message in : https://github.com/crystal-lang/crystal/issues/1967#issuecomment-391321948 https

I'm confused about the state of threading in Crystal. See the last message in : https://github.com/crystal-lang/crystal/issues/1967#issuecomment-391321948 https://github.com/crystal-lang/crystal/issues/1967#issuecom... I'm hoping to see more languages with light-weight threads automatically mapped (multiplexed) to physical threads, like in Go. So far, based on the crowd-sourced table I started working on, it is otherwise only Ada, Haskell and Pony (in addition to Go) that seems to meet these criteria: https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0 https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...

RX14 8y ago
Crystal will eventually have go-style parallelism as well as go-style concurrency. It's a hard thing to implement, and we don't have the resources of google (in fact we have very little resources at all) so it's taking time. Until 3 weeks ago, nobody at all was working full-time on crystal, it was entirely a spare-time project, so progress is slow, i'm incredibly proud of what we've managed to achieve so far and looking forward to more in the future. Really, the best way to help the language is to donate: https://salt.bountysource.com/teams/crystal-lang https://salt.bountysource.com/teams/crystal-lang
- samuell 8y ago
  Great to hear, thanks for the info!
lkurusa 8y ago
Last time I checked/heard about Crystal, it had support for concurrency, but not parallelism yet.
- sam0x17 8y ago
  coming VERY VERY soon. They already have go-like parallelism working in a branch.
  - RX14 8y ago
    it's not very very soon - it'll be more than 2 months - but it is coming.
    - asterite 8y ago
      I wouldn't commit to any specific date. It's not something you can timebox.
    - sam0x17 8y ago
      That's better than 1-2 years, so like I said, very very soon
dom96 8y ago
AFAIK you can add Nim to your list too. The Nim threadpool module[1] allows you to spawn M lightweight threads onto N kernel threads. 1 - https://nim-lang.org/docs/threadpool.html https://nim-lang.org/docs/threadpool.html
- girvo 8y ago
  Which, I'd like to say, is extremely easy to use in production, and actually quite easy to marry with the built-in kqueue/inotify/etc. event loop async/await!
sam0x17 8y ago
Boehm-gc -- the garbage collector used by crystal, is multi-threaded already.
pjmlp 8y ago
Java and .NET do that as well. On Java's case it is up to the JVM implementors to decide, the spec does not impose OS threads. Hence why you can find the terms green and red threads on old Java related docs. Then both support tasks which get multiplexed into the underlying runtime threads.
bmichel 8y ago
Did you look at Erlang/Elixir?
- Mikeb85 8y ago
  Erlang isn't in the same category as the languages being discussed here. It's great for long running parallel tasks, but is slow af.
  - freedomben 8y ago
    Erlang is slow af? That doesn't harmonize with the benchmarks I've seen, but I'm open minded. Do you have anything I can read?
    - Mikeb85 8y ago
      It's common knowledge that it's nowhere near compiled languages for computational speed. It's advantage is massive parallelism and reliability. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Saying Erlang is slow is like saying Ruby is slow. But both are built for problems other than crunching numbers. Not a knock on either language. Crystal is built in the same vein as Nim - meant to be as quick as C++ but easier to write. Erlang was built for a different use case altogether.
      - freedomben 8y ago
        Thanks, much appreciated.
        igouy 8y ago
        Also shown on the benchmarks game website — "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." (quoted from the Erlang FAQ). https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/... iow the performance of apps which use Erlang a lot, is not necessarily limited by the performance of the Erlang implementation.

RX14 8y ago

Crystal will eventually have go-style parallelism as well as go-style concurrency. It's a hard thing to implement, and we don't have the resources of google (in fact we have very little resources at all) so it's taking time. Until 3 weeks ago, nobody at all was working full-time on crystal, it was entirely a spare-time project, so progress is slow, i'm incredibly proud of what we've managed to achieve so far and looking forward to more in the future. Really, the best way to help the language is to donate: https://salt.bountysource.com/teams/crystal-lang https://salt.bountysource.com/teams/crystal-lang

samuell 8y ago
Great to hear, thanks for the info!

lkurusa 8y ago

Last time I checked/heard about Crystal, it had support for concurrency, but not parallelism yet.

sam0x17 8y ago
coming VERY VERY soon. They already have go-like parallelism working in a branch.
- RX14 8y ago
  it's not very very soon - it'll be more than 2 months - but it is coming.
  - asterite 8y ago
    I wouldn't commit to any specific date. It's not something you can timebox.
  - sam0x17 8y ago
    That's better than 1-2 years, so like I said, very very soon

dom96 8y ago

AFAIK you can add Nim to your list too. The Nim threadpool module[1] allows you to spawn M lightweight threads onto N kernel threads. 1 - https://nim-lang.org/docs/threadpool.html https://nim-lang.org/docs/threadpool.html

girvo 8y ago
Which, I'd like to say, is extremely easy to use in production, and actually quite easy to marry with the built-in kqueue/inotify/etc. event loop async/await!

sam0x17 8y ago

Boehm-gc -- the garbage collector used by crystal, is multi-threaded already.

pjmlp 8y ago

Java and .NET do that as well. On Java's case it is up to the JVM implementors to decide, the spec does not impose OS threads. Hence why you can find the terms green and red threads on old Java related docs. Then both support tasks which get multiplexed into the underlying runtime threads.

bmichel 8y ago

Did you look at Erlang/Elixir?

Mikeb85 8y ago
Erlang isn't in the same category as the languages being discussed here. It's great for long running parallel tasks, but is slow af.
- freedomben 8y ago
  Erlang is slow af? That doesn't harmonize with the benchmarks I've seen, but I'm open minded. Do you have anything I can read?
  - Mikeb85 8y ago
    It's common knowledge that it's nowhere near compiled languages for computational speed. It's advantage is massive parallelism and reliability. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Saying Erlang is slow is like saying Ruby is slow. But both are built for problems other than crunching numbers. Not a knock on either language. Crystal is built in the same vein as Nim - meant to be as quick as C++ but easier to write. Erlang was built for a different use case altogether.
    - freedomben 8y ago
      Thanks, much appreciated.
      - igouy 8y ago
        Also shown on the benchmarks game website — "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." (quoted from the Erlang FAQ). https://benchmarksgame-team.pages.debian.net/benchmarksgame/dont-jump-to-conclusions.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/... iow the performance of apps which use Erlang a lot, is not necessarily limited by the performance of the Erlang implementation.