Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

Well, here is why not. AFAK, it still lacks support for parallelism / multicore programming. Please correct me if I'm wrong.

Once it has that, I'll be happy to learn it, but currently it's concurrency seems to be as limited as Racket's. That's a big obstacle for early adoption, since the trend is going towards 64 cores sooner than later. My current CPU already has 8 physical cores and 16 logical cores, and I'd like to use all of them.

This is not a critique on Crystal or Racket, I understand perfectly well the challenges that parallelism poses to language implementers. But it's definitely a massive shortcoming.

View on HN

This is a big advantage of Nim (https://nim-lang.org/), which on the face of it is a pretty similar kind of language with a more Python-like syntax. Nim supports real threads with message passing channels (similar to Go).

> Nim supports real threads with message passing channels (similar to Go).

Could you specify what are the differences from Go, in this regard are, please?

Sure - I'm no expert in concurrency in programming languages as such but here's my understanding: so Nim supports what are essentially native operating system threads but with a difference from most languages being that each thread has its own garbage collected heap. Nim supports shared memory if you so choose to use it with a shared heap. Nim also supports a channel based communication system similar to Go's.

Nim also supports lighter-weight parallelism with the `spawn` (unsafe, unstructured parallelism which schedules a procedure to run in a thread pool) and `parallel` (lets you use a subset of the Nim language to create concurrency safe tasks) keywords which pass tasks to thread pools in the background. You can read more about Nim's concurrency here: https://nim-lang.org/docs/manual.html#parallel-spawn-spawn-s...

Go has Goroutines which use less resources than threads on most operating systems while also taking advantage of multicore CPUs (I assume they must run in a thread pool running in the background?). It also supports a select case statement which is a nice bit of syntax sugar for managing multiple channels, which Nim doesn't support (although its macro system is pretty powerful, so you could plausibly come up with an equivalent). Go does not support shared memory communication as a language feature, although some libraries apparently give you that option.

All the goroutines share the heap, so go does support shared memory, it's just you're encouraged to use channels instead because they're easier to get right.

Crystal has the foundation for parallelism, it has the same concurrency model as go. Adding parallelism will happen before 1.0. Adding parallelism to crystal is easy, it's already been done in a branch and it works fine. The problem is getting the implementation fast enough that it doesn't regress performance for IO bound workloads. It's coming, just wait :)

> AFAK, it still lacks support for parallelism / multicore programming.

Yeah this is a deal-breaker. And it's kinda weird that the article is pitching Crystal as a replacement for Go, Elixir, and Rust with that kind of limitation.

I guess this is just the ramp-up into one more trip around the giant ferris-wheel that is language popularity cycles.

Are you sure Racket doesn't support parallelism?

It does, in at least two different ways:

1. via `places` - basically spawning a new OS-level process and communicating with it. Has an advantage of being able to talk to processes on other machines.

2. via `futures` - OS-level threads, which insert synchronization points automatically where necessary. You have to structure your code in a particular way to make them not to sync, at which point you get a safe parallelism within a process. You get a future visualizer which helps in finding unsafe (syncing) memory accesses.

So the support for parallelism may be nowhere near Erlang or Pony, a bit worse than Java and a bit better than Python or Ruby.

It definitely seems like it does https://docs.racket-lang.org/guide/parallelism.html

Racket's support for parallelism with futures and places is in my experience almost unusable. I don't understand why they have chosen these horrible abstractions rather than providing access to OS-level threads plus some reasonable synchronization mechanisms like channels, shared memory, or actors.

Before you criticize me for this statement, please let me assure you that it's based on plenty of experience. I'm using Racket for almost all my programming since Racket 2 and have contributed libraries.

My hope is that they add good parallelism support in Racket 7, and since it's based on Chez scheme all thread support should already be built in. Places suck.

Reply on news.ycombinator.com