Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby methods are colorless

jpcamara.com

Post reply on HN
Print view View original

31–40 of 242 posts

Re: Ruby methods are colorless

#31

Post by eduction »

>Because threads share the same memory space they have to be carefully coordinated to safely manage state. Ruby threads cannot run CPU-bound Ruby code in parallel, but they can parallelize for blocking operations

Ugh. I know Ruby (which I used to code in a lot more) has made some real progress toward enabling practical use of parallelism but this sounds still pretty awful.

Is there any effort to make sharing data across threads something that doesn't have to be so "carefully coordinated" (ala Clojure's atom/swap!, ref/dosync)?

Is the inability to parallelize CPU-bound code to do with some sort of GIL?

Re: Ruby methods are colorless

#32

Post by curtisblaine »

So maybe it's me, but isn't that line mapping on `&:value` in Ruby the exact equivalent of doing `Promise.all` on a bunch of async functions in Javascript, with the downside that you don't explicitly say that the array you calling `value` on is a bunch of asynchronous things that need to be (a)waited for to realize? In other words, since you have color anyway, isn't it better to highlight that upfront rather than hiding it until you need to actually use the asynchronous return values?

Re: Ruby methods are colorless

#33

Post by hombre_fatal »

explaininjs wrote: post #27
thechao wrote: post #15

I've implemented coroutines in C and C++; my preferred multitasking environment is message-passing between processes. I'm not quite sure what the async/await stuff is buying us (I'm thinking C++, here). Like, I get multi-shot stackless coroutines, i.e., function objects, but I don't get why you'd want to orchestrate some sort of temporal Turing pit of async functions bleeding across your code base. I dunno. Maybe I'm…

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code: a := &blah{} rA, err := engine.doSomethingWithA() b := &bloop{} rB, err := engine.doSomethingWithB() This might have started out with both the doSomethings being v…

Of course, the other nice thing about the JS example compared to Go is that it's trivial at the callsite to do this:

    const [[rA, errA], [rB, errB]] = await Promise.all([
      engine.doSomethingWithA(),
      engine.doSomethingWithB()
    ])
At least these days you can ask an LLM to write the WaitGroup boilerplate for you in Go.

Re: Ruby methods are colorless

#34

Post by clayg »

I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining.

I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro`

Python is currently going through an "coloring" as the stdlib and 3rd-party libraries adapt to the explicit async/await syntax and it's honestly kind of PITA. Curious if there's any more info on how Ruby achived this.

Re: Ruby methods are colorless

#35

Post by mattgreenrocks »

clayg wrote: post #34

I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining. I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro` Python is currently going through an "colori…

Unless I'm misunderstanding: isn't the JVM's virtual threads another instance of this colorlessness?

Re: Ruby methods are colorless

#36

Post by fny »

I'm confused, and please correct me if I'm wrong.

Aren't all these calls blocking? Doesn't `File.read` still block? Sure it's multithreaded, but it still blocks. Threading vs an event loop are two different concurrency models.

Re: Ruby methods are colorless

#37

Post by mp1mp2mp3 »

BiteCode_dev wrote: post #26
throw10920 wrote: post #20

Earlier quoted context omitted.

> fully colorless for async means you don't know when things are async or not The IDE can tell you.

Given Ruby culture of monkey patching, not always. Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.

> ...culture of monkey patching...

I haven't seen more than a handful of PRs with monkey-patching in the last decade and even then they are accompanied by long-winded explanations/apologies and plans for removal ASAP (eg monkey-patching an up streamed fix that hasn't been released yet).

Also, ruby classes/methods can tell you all about themselves, so if you haven't got ruby-lsp up and running (and even if you do) you can always open a repl (on its own, in the server process, or in a test process) and ask the interpreter about your method. It's pretty great!

It's definitely the case that the editor's ability to understand code via static analysis is limited compared to other languages, but it's not like we ruby devs are navigating in the dark.

Re: Ruby methods are colorless

#38

Post by hyualsdfowjasd »

clayg wrote: post #34

I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining. I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro` Python is currently going through an "colori…

The C code in Ruby has to yield to the scheduler when it detects a fiber.

For historical context, python had several "colorless" attempts but none achieved widespread adoption.

Re: Ruby methods are colorless

#39

Post by DarkNova6 »

clayg wrote: post #34

I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining. I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro` Python is currently going through an "colori…

Java has shown that a sufficiently strong runtime can take the burden onto itself long after the facts have been established.

Python in contrast has a runtime ultimately held back by its deep integration with the C-ecosystem which creates more black-boxes inside the runtime than you can find inside a swiss cheese.

Similar with C# and Rust. No strong runtime, no colorless functions for you.

Re: Ruby methods are colorless

#40

Post by DarkNova6 »

thechao wrote: post #15

I've implemented coroutines in C and C++; my preferred multitasking environment is message-passing between processes. I'm not quite sure what the async/await stuff is buying us (I'm thinking C++, here). Like, I get multi-shot stackless coroutines, i.e., function objects, but I don't get why you'd want to orchestrate some sort of temporal Turing pit of async functions bleeding across your code base. I dunno. Maybe I'm…

> Anyways; good for Ruby! Async/await just seems very faddish to me: it didn't solve any of the hard multithreading/multiprocessing problems, and introduced a bunch of other issues. My guess is that it was interesting type theory that bled over into Real Life.

I think what happened what that JavaScript absolutely necessitated the addition of async/await to avoid callback hell (due to its single-threaded mandate)... just to create a new kind of hell all of its own.

But before the long-term consequences within large code bases could be observed, the cool kids like C# & friends jumped on the bandwagon believing that "more syntax equals more better code".

Post reply on HN