this post was submitted on 27 Dec 2024
6 points (100.0% liked)

General Programming Discussion

8293 readers
2 users here now

A general programming discussion community.

Rules:

  1. Be civil.
  2. Please start discussions that spark conversation

Other communities

Systems

Functional Programming

Also related

founded 6 years ago
MODERATORS
top 6 comments
sorted by: hot top controversial new old
[–] Ephera@lemmy.ml 2 points 1 year ago (2 children)

Only Clojure supports parallelism.

It's wild to me that this is said almost between the lines. In this particular benchmark, it obviously didn't help, but for many workloads that's going to make a massive difference or even leave Clojure as the only viable choice.

[–] yogthos@lemmy.ml 3 points 1 year ago (1 children)

Indeed, and it's also worth noting that doing parallelism in Clojure is inherently easier than in an imperative language since data is immutable by default. If you're using Python or Ruby then you have to consider parallelism up front in your design, meanwhile with Clojure you can just swap map with pmap.

[–] Ephera@lemmy.ml 2 points 1 year ago (1 children)

Ah, interesting. I'm currently in the Rust rabbit hole, which takes a very different path towards race condition safety (it's imperative and the compiler separately checks that you're not using mutability in parallel contexts), but you actually get quite a similar feature, in that you can swap .iter().map() with .par_iter().map() (via a library).

[–] yogthos@lemmy.ml 2 points 1 year ago

Yeah, borrow checking approach in Rust is pretty neat since it lets the compiler track exactly where a data structure is being mutated at compile time. Rust approach is more efficient overall as well, but structural sharing has its own benefits as well since you get stuff like history for free. XTDB is a neat project that leverages this property for a temporal db.

[–] lukewarm_ozone@lemmy.today 1 points 1 year ago* (last edited 1 year ago) (1 children)

I'm not sure what the author meant by this. Python does support parallelism via multiprocessing (and in experimental versions, via threads in no-GIL builds), e.g. like this. It's a bit questionable whether it'd help here, because the overhead of sending the inputs between workers may be comparable to the speedup, but it's certainly possible, and very common in real tasks.

(I'm not familiar with Ruby, but from some googling it seems the situation is about the same as Python, but there's not a stdlib implementation and instead you need to use something third-party like the parallel gem.)

[–] Ephera@lemmy.ml 1 points 1 year ago

The author is referring to the GIL, I'm pretty sure. Both Python and Ruby have it. I guess, they should've written "only Clojure supports true multithreading", but that you're able to spawn multiple processes is kind of a given (and has quite some disadvantages for certain workloads).

That Python has experimental no-GIL builds is good, but I wouldn't seriously consider using that until they've had it in a stable release and thrown some bug fixes onto it. Well, and even then, there might not be much point in trying to use it, until libraries have adopted it...