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

171–180 of 242 posts

Re: Ruby methods are colorless

#171

Post by lolinder »

akoboldfrying wrote: post #103
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…

It's a big neon sign that says " Either this function is expensive, or it isn't but some framework somewhere that sometimes needs to call expensive functions might also need to call this function using the same syntax".

No, because in JavaScript/TypeScript you can happily await any function that you'd like on the chance that it sometimes returns a Promise. If a framework demands that you return a Promise unnecessarily, that's on the framework, not the language.

Re: Ruby methods are colorless

#172

Post by jerf »

fny wrote: post #36

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.

You have to watch your definition of "blocking". Node, well, I won't say it created the definition of "blocking" that means "it blocks your entire OS process regardless of how many other things you're trying to do concurrently", but it certainly popularized it, and a lot of people sloppily project the negative aspects of that into threaded languages. In a threaded language, yes, you block on a .Read call until it is complete in that thread, but you don't block the whole OS process; other threads can and do continue on.

Re: Ruby methods are colorless

#173

Post by moralestapia »

anonymoushn wrote: post #79
moralestapia wrote: post #69

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…

If you program with promises and without async/await, then your language is still missing something compared to languages that have coroutines in which functions that suspend and do not suspend may be composed (used by higher-order functions, etc.) in the same ways as each other. You've moved from the situation where both types of functions were present and must be handled differently to the situation where one type…

Can you give an example?

Re: Ruby methods are colorless

#174

Post by lolinder »

vips7L wrote: post #169
wiseowise wrote: post #143

Earlier quoted context omitted.

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Where do you see insanity like this?

Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().

That sounds more like a legacy problem than a problem with the async/await model in the abstract.

If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.

Re: Ruby methods are colorless

#175

Post by vips7L »

wiseowise wrote: post #144

Kotlin solved this pointless debate long time ago the moment they’ve released coroutines. Best of both worlds: you no longer have two functions with ReturnType and Promise . You just mark potentially blocking function with suspend and you’re done.

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.

Re: Ruby methods are colorless

#176

Post by mabster »

sqeaky wrote: post #58
jayd16 wrote: post #52

Earlier quoted context omitted.

Isn't async/await "scheduling heterogenous work with nuanced dependencies"? Or is that what you were implying? Although my real guess is ECS but that's more like the "everyone gets every thread for a time."

TLDR; I hadn't meant it that way, but in web pages it really is enough. Web pages generally don't have computation time to worry about, mostly just IO. This simplifies scheduling because whatever is coordinating the event loop in the browser (or other UI) can just background any amount of independent IO tasks. If there is computation screwing with share mutable state something with internal knowledge needs to be invo…

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 to deal with as they are generally low overhead which means all threads (processes really) are generally saturated with work at all times.

I don't really remember any global state with contention because that's generally very very slow, but maybe there were bits of our gameplay code I'm not aware of.

Re: Ruby methods are colorless

#177

Post by SleepyMyroslav »

anonymoushn wrote: post #149
SleepyMyroslav wrote: post #131

Earlier quoted context omitted.

Dislaimer i work in gamedev. I think what ppl do in gamedev with tasks/jobs ( different ppl call it differently ) and colorless async with functions that may yield at any time are different. Yielding on I/O means you can not meet a deadline ( frame time ). Not on current hardware that has no I/O deadlines. Which means to me that there is no way we can share library code between async web and realtime part of a game.…

Doesn't it mean you can meet the deadline, but you cannot guarantee that your new textures will be loaded/TLS handshake with login server will be completed/etc. before the deadline happens?

Texture loading and TLS can not meet deadline for sure because we rely on APIs that do not support deadlines. They can only be best effort/background code.

The difference I believe is between updating each UI widget and doing something in case of still missing texture or yielding on the texture in some place of UI code and never touching rest of the UI in the frame.

Re: Ruby methods are colorless

#178

Post by DarkNova6 »

incrudible wrote: post #84
DarkNova6 wrote: post #40

Earlier quoted context omitted.

> 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)... j…

Javascript necessitates async because of its focus on UI. You just can not have good UI while blocking on the main (or UI) thread, you will inevitably have something like async and callbacks, so you might as well embrace it. Whether that is a good tradeoff for a server is a different question.

What you need is concurrency. And async/await is just one form of concurrency.

I don’t see why you would need threads to create a stackful coroutine implementation. However, what you would indeed need is a much more heavy runtime.

Re: Ruby methods are colorless

#179

Post by DarkNova6 »

rpeden wrote: post #97
DarkNova6 wrote: post #40

Earlier quoted context omitted.

> 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)... j…

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.

Re: Ruby methods are colorless

#180

Post by vips7L »

lolinder wrote: post #174
vips7L wrote: post #169

Earlier quoted context omitted.

Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().

That sounds more like a legacy problem than a problem with the async/await model in the abstract. If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.

There’s lot of programming models that don’t require async or it’s complexity. Not everything is a web server that needs to serve 100k requests.
Post reply on HN