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

61–70 of 242 posts

Re: Ruby methods are colorless

#61

Post by explaininjs »

hombre_fatal wrote: post #33
explaininjs wrote: post #27

Earlier quoted context omitted.

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.

Indeed. And breakpoints and stepping across concurrent context actually works in JS, which is nice.

Re: Ruby methods are colorless

#62

Post by explaininjs »

Fire-Dragon-DoL wrote: post #57
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…

I'm with you here, actor model is the way to go. I thought Go style could be better, but the Go type system is completely inadequate to support that style: it is impossible to guaranteed that a goroutine is panic free, it is not possible to put a recover in the goroutine unless that code is under author's control (could be a lib) and a goroutine panic takes down the whole app. Suddenly I want a wrapper around each go…

That sounds a lot like async/await. Any errors thrown in an async context bubble to the callsite awaiting it.

Re: Ruby methods are colorless

#63

Post by throwitaway1123 »

jayd16 wrote: post #51
explaininjs wrote: post #27

Earlier quoted context omitted.

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…

Honestly, despite that blog, async coloring is a feature. The pattern enforces implicit critical sections between yields and the coloring is how the dev can know what will yield.

This is a really interesting point. You almost never hear async function coloring being conceptualized as a feature rather than a hindrance. Async function coloring is kind of analogous to the borrow checker in Rust. It makes you think about concurrency the same way that the borrow checker makes you think about memory ownership and lifetimes.

Re: Ruby methods are colorless

#64

Post by thwarted »

monkpit wrote: post #54
thwarted wrote: post #21

> Async code bubbles all the way to the top. If you want to use await, then you have to mark your function as async. Then if someone else calling your function wants to use await, they also have to mark themselves as async, on and on until the root of the call chain. If at any point you don’t then you have to use the async result (in JavaScript’s case a Promise ). I find many descriptions of async code to be confusin…

> This example seems crazy to me […] To be fair, this is sort of pointless in JS/TS because an async function returns a promise type by default, so the return value has to be ‘await’ed to access the value anyways. There are linter rules you can use to ban ‘return await’. The only benefit to ‘return await…’ is when wrapped with a try/catch - you can catch if whatever you ‘await’ed throws an error.

Well, that was a simplistic contrived example, it may make sense to do this if you have other functionality you want to put in the wrapper. But I've seen more of these blind wrappers, the result of stuffing async and await keywords around in some misguided attempt to make things go faster, in code than is really warranted so it's not being made clear that examples like this are for explanatory purposes and shouldn't be cargo-culted (if anything should be cargo-culted).

Re: Ruby methods are colorless

#65

Post by dang »

Related:

What color is your function? (2015) - https://news.ycombinator.com/item?id=28657358 - Sept 2021 (58 comments)

What Color Is Your Function? (2015) - https://news.ycombinator.com/item?id=23218782 - May 2020 (85 comments)

What Color is Your Function? (2015) - https://news.ycombinator.com/item?id=16732948 - April 2018 (45 comments)

What Color Is Your Function? - https://news.ycombinator.com/item?id=8984648 - Feb 2015 (146 comments)

Re: Ruby methods are colorless

#66

Post by Lio »

eduction wrote: post #31

>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 acr…

It all depends on your Ruby runtime.

If you want parallel threads then you can use JRuby and your threads will run in parallel on the JVM. I've used the Concurrent-Ruby gem to coordinate that[1].

It has copies of some of the Clojure data structures.

Otherwise, Ractors the up coming solution for MRI Ruby.

1. https://github.com/ruby-concurrency/concurrent-ruby

Re: Ruby methods are colorless

#67

Post by anonymoushn »

DarkNova6 wrote: post #39
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.

Greenlet has been available for Python since 2006. Troubles with asyncio are mostly self-inflicted.

Re: Ruby methods are colorless

#68

Post by Rapzid »

throw10920 wrote: post #22

As they should be. I object to doing what a computer can do for me (in programming), and manually creating separate versions of functions that are identical up to async absolutely falls into that category.

They have different signatures because they return different things.

Re: Ruby methods are colorless

#69

Post by moralestapia »

The argument for "color"ed functions in Javascript is flawed and comes from somebody with a (very) shallow understanding of the language.

Javascript is as "colorless" any other programming language. You can write "async"-style code without using async/await at all while it being functionally equivalent.

Async/await is just syntactic sugar that saves you from writing "thenable" functions and callbacks again and again and again ...

Instead of:

  function(...).then(function() {
    // continue building your pyramid of doom [1]
  })
... you can just do:

  await function()
That's literally it.

1: https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)

Re: Ruby methods are colorless

#70

Post by anonymoushn »

hyualsdfowjasd wrote: post #45
DarkNova6 wrote: post #39

Earlier quoted context omitted.

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.

> Similar with C# and Rust. No strong runtime, no colorless functions for you. Zig is the exception here but not sure how well it worked out in practice.

Well, the feature is temporarily killed, but users can enjoy zigcoro which exposes a similar API until the old async is back.
Post reply on HN