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

201–210 of 242 posts

Re: Ruby methods are colorless

#201

Post by phplovesong »

vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

Its a bad feature. The thing is it does not matter if its ”obvious” as anything that touches async needs to be async too. Its a bad paradigm, CSP is obviously a better way to do concurrency. As async is usually only IO bound, but how about CPU bound? In the node ecosystem CPU bound tasks are not something you do with async/await.

Re: Ruby methods are colorless

#202

Post by vlucas »

phplovesong wrote: post #201
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

Its a bad feature. The thing is it does not matter if its ”obvious” as anything that touches async needs to be async too. Its a bad paradigm, CSP is obviously a better way to do concurrency. As async is usually only IO bound, but how about CPU bound? In the node ecosystem CPU bound tasks are not something you do with async/await.

In node, you generally don't want to do anything CPU bound.

Re: Ruby methods are colorless

#203

Post by vips7L »

wiseowise wrote: post #195
vips7L wrote: post #175

Earlier quoted context omitted.

I don’t see how. Only suspending functions can call other suspending functions. You still end up having to mark your call stack all the way up.

runBlocking {}

Right that solves the problem if you can block. But in applications that are async everywhere, like a web app, you end up having to mark everything as suspend all the way up the chain.

Re: Ruby methods are colorless

#205

Post by modal-soul »

dragonwriter wrote: post #183
spankalee wrote: post #121

Earlier quoted context omitted.

Using promises is basically no different than using async functions, and definitely doesn't "uncolor" your functions. Any function that calls another that returns a Promise will have to return a Promise to represent completion correctly. That's the color.

> Any function that calls another that returns a Promise will have to return a Promise to represent completion correctly No, it doesn't, closures let you update values in the wcope of the parent in .then() callbacks and then you can loop in the function and wait for completion and return a non-Promise value.

This is not true. If your sync function loops until the value is set, then the Promise will never resolve, since it never yields to the event loop.

Re: Ruby methods are colorless

#206

Post by munificent »

vips7L wrote: post #87
munificent wrote: post #82

Earlier quoted context omitted.

It fills me with delight that apparently my lasting contribution to computer science is a piece of writing that also contains the phase "Spidermouth the Night Clown".

Don't sell Crafting Interpreters short!

Fair. But that one has a hand-drawn picture of an alligator eating characters and pooping tokens, so it's in about the same category of maturity. :)

Re: Ruby methods are colorless

#207

Post by caditinpiscinam »

vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

If explicitly marking expensive IO operations using async is a feature, then why don't languages with async make their "print" functions asynchronous?

Re: Ruby methods are colorless

#208

Post by rpeden »

DarkNova6 wrote: post #179
rpeden wrote: post #97

Earlier quoted context omitted.

Async and await appeared in C# well before they were added to JavaScript, so I'm not sure the reasoning of your timeline makes sense.

You are right. I already saw it on other replies. Thanks for pointing it out here as well.

Hopefully I didn't seem too pedantic. I don't think C# having it first necessarily diminishes your point about the use of async and await in JS.

Async and await were nice additions in C# to make working with tasks more convenient, but there were other ways to manage async tasks without ending up with a tower of callbacks. The situation was messier in JS.

Re: Ruby methods are colorless

#209

Post by Rapzid »

masklinn wrote: post #120
Rapzid wrote: post #74

Earlier quoted context omitted.

The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. If you are blocking the caller you have not "solved" the colored function "problem".

> The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. That is an end not a mean. Again in my experience the vast majority of devs could not give less of a shit about “not blocking the caller” by default. What most devs want is a reasonably cheap way to get a high amount of concurrency. If anything not blocking the caller by default is g…

And it looks pretty much exactly like using threads, which is why they are working so hard on structured concurrency.

Go has NOT solved the problem in a fungible way, as evidence by all the dual APIs; methods that return a channel, and those that don't.

CSP is great at modeling data flow, but IMHO it's lesser than async/await imperative programing for modeling more standard business logic flows.

Re: Ruby methods are colorless

#210

Post by mabster »

sqeaky wrote: post #197
mabster wrote: post #176

Earlier quoted context omitted.

It doesn't sound to me like the engines you dealt with use ECS, which are usually resolved with a job system (your work units and functors), but correct me if I'm wrong. The good job systems I've dealt with have their dependencies in the functors. So you "wait" on a job to finish, which is really a while loop that plucks and executes other jobs while the dependency job hasn't finished. This kind of job system is nice…

The ECS concerns don't really relate to threading concerns. I have worked with and without ECS systems both with and without good threading models. ECS writes do create possible issues if write-locks need to be acquired but that isn't usually so big of a deal.

In the "you're still going to have to wait for something" sense, sure. But the reason ECS exists is because the industry had to change our architecture when we moved to many core CPUs to take advantage.

I'm battling to understand what you want then, sorry. The systems that you say you would like to use (discrete jobs with dependencies) are the kind of systems the industry has been using since the advent of data-oriented architecture, which includes ECS. That is, a job worker process per core plucking off work and doing it.

In the engines I've dealt with, we don't usually have write locks, instead preferring copies of "last frame data" and "next frame data". And all our "read locks" are waits for jobs. Our game code is generally single threaded, but the main loop pretty much just kicks off and waits for jobs.

I guess what is a good threading model to you?

(As a side note I've worked on projects that use ECS on a single core and they still confer benefits there even though that's not what they were invented for)

Post reply on HN