Ruby methods are colorless

https://jpcamara.com/2024/07/15/ruby-methods-are.html

by pmontra • 2 years ago

187 223 2 years ago

thechao• 2 years ago

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 old now?

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.

anonymoushn9• 2 years ago

If you have hundreds or thousands of connection-handlers or scripts-attached-to-game-objects, then it can be useful to write code in those without dividing the code into basic blocks each time I/O might be performed or time might pass in the game.

I generally agree that manually migrating everything to "be async" in order to achieve this exposes at the very least a lack of belief that computers can be used to automate drudge work.

mikepurvis• 2 years ago

I really like the patterns that it enables for situations with a lot of parallel IO. Easy example is any kind of scraper, where you're fetching large numbers of pages and then immediately processing those to generate more requests for the links and assets referenced within.

skywhopper• 2 years ago

My theory is that JavaScript programmers who were forced into thinking this way for decades with their single-threaded runtime have infected other languages with the idea that this style of coding is not only good but furthermore that it needs to be explicit.

Thank goodness we have wiser language developers out there who have resisted this impulse.

Erem• 2 years ago

Didn’t async/await originate in c#?

explaininjs9• 2 years ago

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 very quick painless procedures. But over time they’ve grown into behemoth network requests and very thing is slow and crappy. No, it’s not exactly hard to spin up a go routine to handle the work concurrently, but it’s not trivial either - and importantly, it’s not immediately obvious that this would be a good idea.

Contrast to TS:

   let a = {blah}
   let [rA, err] = engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] engine.doSomethingWithB()

Now, time passes, you perform that behemoth slowing down of the doSomethings. You are forced by the type system to change this:

   let a = {blah}
   let [rA, err] = await engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] await engine.doSomethingWithB()

It’s now immediately obvious that you might want to run these two procedures concurrently. Obviously you will need to check the engine code, but any programmer worth their salt should at least seek to investigate concurrency when making that change.

I wouldn’t be bringing this up if I hadn’t made 10x+ performance improvements to critical services within a month of starting at a new company in a new language on a service where the handful of experienced go programmers on the team had no idea why their code was taking so long.

hombre_fatal• 2 years ago

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.

jayd164• 2 years ago

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.

asp_hornet2• 2 years ago

Only if those doSomething methods were written as asynchronous to begin with.in your original example, doSomethingA was simple, why would it be an async method. If your answer is write every method async for a rainy day, then whats the point.

DarkNova64• 2 years ago

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".

incrudible• 2 years ago

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.

rpeden2• 2 years ago

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.

masklinn7• 2 years ago

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.

It’s not really “a new kind of hell”, there’s a logical progression from callbacks to reified callback (promises) to coroutines, and each step makes concurrency more manageable so you do more of it until you hit a new wall.

And client-side JS probably can’t ever be preemptive, so not only would a thread model require adding a ton of tooling at once it would still behave quite strangely.

sqeaky4• 2 years ago

I think the async/await patterns solve one problem really well: UI latency.

My UI background is web testing and C++ game UIs in C++. There are like 3 patterns in multithreaded games. Thread per responsibility (old/bad), Barriers blocking all threads and give each game system all the threads, or something smart. Few games do something smart, and the thread per responsibility is not ideal and we will ignore it for now.

In games often pausing everything and letting the physics system have all the threads for a few milliseconds is "fast enough". Then the graphics systems will try to use all the threads, and so on so that eventually everything will get all the threads even thought everything else rarely needs it. Sometimes two things are both close to single threaded and have no data contention so they might both be given threads, but this is almost always a manually decided things by experts.

This means that once UI, the buttons, the text, cursors, status bars, etc, gets its turn there won't be any race conditions (good), but if it needs to request something from disk that pause will happen on a thread in the UI system (bad and analogous to web sites making web API calls) so UI latency can be a real problem. If any IO small or some resource system has preloaded it then there isn't a detectable slowdown, but there are still plenty of silly periods of waiting. There is also a lot of time when some single threaded part of the game isn't using N-1 hardware threads and all that IO could have been asynchronous. But often game UIs are a frame behind the rest of the game simulation and there is often detectable latency in the UI like the mouse feeling like it drags or similar.

Allowing IO to run in the back while active events are processed can reduce latency and this is the default in web browsers. IO latency in web pages is worse than in games and other computation seems smaller than games, so the the event loop is close to ideal. A function is waiting? throw it on the stack and grab something else to do! This means that all the work that can be done while waiting on IO is done and when does well makes a UI snappy.

If that were available sensibly in games it could allow a game designed appropriately to span IO across multiple frames and be snappy without stutters. With games using the strategy I described above latency in the game simulation or IO can cause the UI to feel sluggish and vice versa. In games caching UI details and trying to pump the frame rate is "good enough". If the UI is a frame behind but we have 200 frames per second, that isn't really a problem. But when it chugs and the mouse stops responding because the player built the whole game world out of dynamite and set it off the game will not process the mouse until that 30 minutes of physics work is done.

There are better scheduling schemes for games. I am a big fan of doing "something smart" but that usually means scheduling heterogenous work with nuanced dependencies and I have written libraries just for that because it isn't actually that hard. But if you don't have the raw compute demands of a game scheduling IO along side your UI computation is often "fast enough" and is any easy enough mental model for JS devs to grok and allow them freedom to speed things up with their own solutions like caching schemes and reworking their UIs.

jayd164• 2 years ago

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."

kubectl_h2• 2 years ago

I work on a large multi-threaded ruby code base and it's always a pain to deal with engineers introducing the async usage in it. Most of the time these engineers don't have a grasp on what fibers are good for and we have to painstakingly review their code and provide feedback that no, it's not magical concurrency, we have a limited number of fix sized connection pools for postgres, redis, memcache, etc available in the process and fibers have to respect those limits as much as threaded code. In fact it's better if you don't introduce any additional concurrency below the thread-per-request model if you can. Only in places like concurrent http calls do we allow some async/fiber usage but even then it ends up nominally looking like threaded code and the VM context switching time saved by using fibers instead of threads is trivial. Trying to use fibers instead of threads in typical CRUD workloads feels a little cargo culty to me.

Fibers are cool and performant but usually they should be limited to lightweight work with large concurrency requirements.

Glyptodon• 2 years ago

I wish there were limited forms of true parallelism available with fibers instead of it just being another concurrency construct limited by an interpreter lock. I feel like there should be an in-language construct for stuff that's safely parallel and narrow, and not just Ractors. But I do get that it'd be a footgun for many.

jayd164• 2 years ago

Ever done any UI programming or other paradigms where you have a specific OS thread used for cross runtime synchronization but you need to efficiently call background threads knowing exactly what's running where?

Async/await handles that well and so far the other paradigms just have not targeted these use cases well.

Message passing and promise libraries end up looking a lot like async/await with less sugar. (Compared to C#'s async/await implementation. The level of sugar depends on the language, of course.)

binary132• 2 years ago

In our C++ stack at work we accept HTTP requests, and then spawn internal IO which takes some time. During that time, we yield the handler thread to handle other requests. The arrival of the internal response sets up the next step in the request handler to resume, which needs the response message.

This can be done manually by polling status of descriptors, and stepping into and out of callables / passed continuations by hand, or it can be done with a task scheduling API and typesafe chained async functions.

Pick your poison, I guess, but it probably scales better than using synchronous IO and thread-per-request.

kmeisthax• 2 years ago

JavaScript has async/await because it solves a very specifically JavaScript problem: the language has no threads and all your code lives in the main event loop of the browser tab. If you do the normal thing of pausing your JavaScript until an I/O operation returns, the browser hangs. So you need to write everything with callbacks (continuation passing style), which is a pain in the ass and breaks exception handling. Promises were introduced to fix exceptions and async/await introduced to sugar over CPS.

There's also a very specifically Not JavaScript problem (that happens to also show up in Node.js): exotic concurrency scenarios involving lots of high-latency I/O (read: network sockets). OS kernel/CRT[0] threads are a lot more performant than they used to be but they still require bookkeeping that an application might not need and usually allocate a default stack size that's way too high. There's no language I know of where you can ask for the maximum stack size of a function[1] and then use that to allocate a stack. But if you structure your program as callbacks then you can share one stack allocation across multiple threads and heap-allocate everything that needs to live between yield points.

You can do exotic concurrency without exposing async to the language. For example, Go uses (or at least one point it did) its own thread management and variable-size stacks. This is more invasive to a program than adopting precise garbage collection and requires deep language support[3]. Yes, even moreso than async/await, which just requires the compiler transform imperative code into a state machine on an opt-in basis. You'd never, ever see, say, Rust implement transparent green threading[2].

To be clear, all UI code has to live in an event loop. Any code that lives in that event loop has to be async or the event loop stops servicing user input. But async code doesn't infect UI code in any other language because you can use threads and blocking executors[4] as boundaries between the sync and async worlds. The threading story in JavaScript doesn't exist, it has workers instead. And while workers use threads internally, the structured clone that is done to pass data between workers makes workers a lot more like processes than threads in terms of developer experience.

[0] Critical Runtime Theory: every system call is political

[1] ActionScript 3 had facilities for declaring a stack size limit but I don't think you could get that from the runtime.

async/await syntax in Rust also just so happens to generate an anonymous type whose size is the maximum memory usage of the function across yield points, since Rust promises also store the state of the async function when it's yielded. Yes, this also means recursive yields are forbidden, at least not without strategic use of `Box`. And it also does not cover sync stack usage while a function is being polled.

[2] I say this knowing full well that alpha Rust had transparent green threading.

[3] No, setjmp/longjmp does not count.

[4] i.e. when calling async promise code from sync blocking functions, just sleep the current thread or poll/spinwait until the promise resolves

sapiogram2• 2 years ago

For example, Go uses (or at least one point it did) its own thread management and variable-size stacks.

Go developer here: Yup, the language still works like that, and probably always will.

didip• 2 years ago

Async/await is just a sugar that many people happened to like.

As for me, I like Go's CSP better.

Fire-Dragon-DoL2• 2 years ago

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 goroutine that bubbles up the panic to the main thread without crashing the app, that sounds a lot like an erlang supervision tree

explaininjs9• 2 years ago

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

hosh2• 2 years ago

I have written Ruby, Elixir, and Typescript on Nodejs.

I have yet to see a good reason for async/await, other than syntax sugar on a flawed language architecture. The very thing people like about Nodejs (async reactor), creates a lot of problems in production web and data pipeline code.

As an aside, Elixir’s Task.async and Task.await are function helpers that work with message passing primitives. Code execution can be truly suspended, and messages are queued. Javascript’s async/await queues code execution rather than messages, and I think that leads to error prone code by design.

raggi• 2 years ago

async/await like many similar constructs buys you the ability to defer design decisions you would otherwise have to have made earlier. in a program that stays small, this is good, less work to do. in a program that grows large, this is a hazard and will likely lead to substantial debts down the line.

BiteCode_dev2• 2 years ago

I don't like colored function for obvious reasons, but fully colorless for async means you don't know when things are async or not.

There are a lot of things I dislike in JS, but I think the I/O async model is just right from an ergonomics point of view. The event loop is implicit, any async function returns a promise, you can deal with promises from inside sync code without much trouble.

It's just the right balance.

throw1092011• 2 years ago

fully colorless for async means you don't know when things are async or not

The IDE can tell you.

BiteCode_dev2• 2 years ago

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.

lmm10• 2 years ago

The IDE can tell you.

The only way the IDE can tell you is if the language tells it, or it guesses - and if it guesses then it will get it wrong sometimes. Which things are async or not is exactly the kind of thing that needs to be part of the language definition, so that all tools will agree about it and you won't have functions that are async in one IDE and not another, or async in a profiler but not an IDE, or...

wiseowise5• 2 years ago

I’m all ears how IDE will determine that function is blocking 20 layers deep into third party library I don’t even have source code of.

thwarted2• 2 years ago

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<T>).

I find many descriptions of async code to be confusing, and this kind of description is exactly why.

This description is backwards. You don't choose to use await and then decorate functions with async. Or maybe you do and that's why so many async codebases are a mess.

You don't want to block while a long running operation completes, so you decorate the function that performs that operation with async and return a Promise.

But Promises have exactly the same value as promises in the real world: none until they are fulfilled. You can't do further operations on a promise, you can only wait for it to be done, you have to wait for the promise to be fulfilled to get the result that you actually want to operate on.

The folly of relying on a promise is embodied in the character Whimpy from Popeye: "I'll gladly pay you Tuesday for a hamburger today".

Once you have a promise, you have to await on it, turning the async operation into a synchronous operation.

This example seems crazy to me:

    async function readFile(): Promise<string> {
      return await read();
    }

This wraps what should be an async operation that returns a promise (read) in an expression that blocks (await read()) inside a function that returns a promise so you didn't need to block on it!. This is a useless wrapper. This kind of construct is probably the significant contribution to the mess: just peppering code with async and await and wrapper functions.

await is the point where an async operation is blocked on to get back into a synchronous flow. Creating promises means you ultimately need to block in a synchronous function to give the single threaded runtime a chance to make progress on all the promises. Done properly, this happens by the event loop. But setting that up requires the actual operation of all your code to be async and thus callback hell and the verbose syntactic salt to even express that in code.

That all being said, this piece is spot on. Threads (in general, but in ruby as the topic of this piece) and go's goroutines encapsulate all this by abstracting over the state management of different threads of execution via stacks. Remove the stacks and async programming requires you to manage that state yourself. Async programming removes a very useful abstraction.

Independent threads of execution, if they are operating system managed threads, operating system managed processes (a special case of OS managed threads), green threads, or go routines, are a scheduler abstraction. Async programming forces you to manage that scheduling. Which may be required if you don't also have an abstraction available for preemption, but async leaks the single threaded implementation into your code, and the syntactic salt necessary to express it.

graypegg• 2 years ago

To be fair to the author, they do mention in the paragraph above that sample:

    Async code bubbles all the way to the top. If you want to use await, then you have to mark your function as async. [...] If at any point you don’t then you have to use the async result (in JavaScript’s case a Promise<T>).

I think it's just an artificially lengthy example to show how the responsibility of working with promises grows up the callstack. Interpreting it that way since the final function they define in that sample is `iGiveUp` which is not using the async keyword, but returns a promise. Definitely could be made a bit more clear that's it's illustrative and not that the async keyword is somehow unlocking some super special runtime mode separate from it's Promise implementation.

monkpit• 2 years ago

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.

thwarted2• 2 years ago

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

throw1092011• 2 years ago

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.

Rapzid6• 2 years ago

They have different signatures because they return different things.

goatlover5• 2 years ago

Not in languages like Ruby.

throw1092011• 2 years ago

The difference between returning a Foo and Promise<Foo> is utterly irrelevant in this case because the computer is capable of automatically handing the difference.

lmm10• 2 years ago

So use a language that knows how to be polymorphic over async. Just like you don't want to have to write one version of sort() for each possible array element type, but the solution isn't to make all array elements untyped, the solution is to have a language that can abstract over that.

mmaniac2• 2 years ago

Can you give an example of a language which is polymorphic in this way and how that looks?

throw1092011• 2 years ago

Yeah, that's the correct solution. I'm not arguing for the solution, I'm arguing for the problem, because a lot of people seem to think that the problem isn't real.

svieira• 2 years ago

Anytime this comes up I plug the excellent "Unyielding" (https://glyph.twistedmatrix.com/2014/02/unyielding.html) and "Notes on structured concurrency" (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) as the counterpoint to "What color is your function". Being able to see structurally what effects your invocation of a function will result in is very helpful in reasoning about the effects of concurrency in a complicated domain.

eduction• 2 years ago

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?

vidarh• 2 years ago

That's what Ractor is for, if you want full parallelization without processes.

And, yes, it's to do with a GIL/GVL. The lock is released during blocking IO, and some C extensions etc., so in practice for a lot of uses it's fine.

sqeaky4• 2 years ago

They ditched the GIL a while a ago. But there are smaller locks fighting for resources.

EDIT - I remember when patch notes years ago said the GIL was gone and this says there is a GVL, I guess there is some subtle difference.

then I think for practical purposes, "yes" is your answer, but not in precisely that name.

Lio• 2 years ago

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

curtisblaine• 2 years ago

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?

clayg• 2 years ago

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.

mattgreenrocks• 2 years ago

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

zogrodea3• 2 years ago

I think you're right. People describe Java as being colourless.

hyualsdfowjasd2• 2 years ago

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.

DarkNova64• 2 years ago

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.

hyualsdfowjasd2• 2 years ago

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.

anonymoushn9• 2 years ago

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

Rapzid6• 2 years ago

C# has a strong runtime.

masklinn7• 2 years ago

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`

In Python gevent can monkeypatch the standard library to do that transparently (mostly). I assume it works the same way except better: have the runtime keep track of the current execution (mostly the stack and ip), when reaching a blocking point register a completion event agains the OS then tell the fiber scheduler to switch off, the fiber scheduler puts away all the running state (stack and instruction pointer) then restores an other one (hopefully one that's ready for execution) and resumes that.

fny• 2 years ago

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.

masklinn7• 2 years ago

Aren't all these calls blocking?

Only locally, which is pretty much the same as when you `await` a call.

Threading vs an event loop are two different concurrency models.

The point is that you can build a "threading" (blocking) model on top of an event loop, such that you get a more natural coding style with most of the gain in concurrency.

It loses some, because you only have concurrency between tasks (~threads) leaving aside builtins which might get special cased, but my observation has been that the vast majority of developers don't grok or want to use generalised sub-task concurrency anyway, and are quite confused when that's being done.

For instance in my Javascript experience the average developer just `awaits` things as they get them, the use of concurrent composition (e.g. Promise.all) is an exception which you might get into as an optimisation, e.g. `await`-ing in the middle of a loop is embarrassingly common even when the iterations have no dependency.

Rapzid6• 2 years ago

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".

mdavidn• 2 years ago

By default, File.read does block, yes. As it crosses into libc, it releases Ruby's interpreter lock, allowing another Ruby thread to execute while it blocks.

Ruby 1.9 added Fibers. These are coroutines with their own call stack that yield and resume explicitly. They're like Goroutines but without Go's scheduler. Fibers are commonly used to build Enumerators, internal iterators support external iteration. File.read in a Fiber still blocks by default.

Ruby 3.0 added support for truly asynchronous File.read. The batteries are not included. A fiber scheduler is required to enable this optional feature:

https://docs.ruby-lang.org/en/3.3/Fiber.html#class-Fiber-lab...

https://brunosutic.com/blog/ruby-fiber-scheduler

jerf6• 2 years ago

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.

janci• 2 years ago

3. You can only call a red function from within a red function

The base of most arguments against async. And it's false. You can call red from blue. And you should, sometimes.

lta2• 2 years ago

Yes... But it's a PITA most of the time, right ? I'm not sure for JS, as I can't remember right now but it's a annoying as f*k in python at least

masklinn7• 2 years ago

In JS it’s not an issue as long as you just fire and forget. Because calls to async functions essentially fork off tasks. No way to synchronise on them though.

Python (and rust) are coroutine based so calling an async function does essentially nothing, you need to acquire a runtime handle in order to run and resolve the coroutine.

stephen• 2 years ago

Maybe its Stockholm syndrome after ~4-5 years of TypeScript, but I like knowing "this method call is going to do I/O somewhere" (that its red).

To the point where I consider "colorless functions" to be a leaky abstraction; i.e. I do a lot of ORM stuff, and "I'll just call author.getBooks().get(0) b/c that is a cheap, in-memory, synchronous collection access ... oh wait its actually a colorless SQL call that blocks (sometimes)" imo led to ~majority of ORM backlash/N+1s/etc.

Maybe my preference for "expressing IO in the type system" means in another ~4-5 years, I'll be a Haskell convert, or using Effect.ts to "fix Promise not being a true monad" but so far I feel like the JS Promise/async/await really is just fine.

goatlover5• 2 years ago

Don't you generally know when you're making an I/O call?

t-writescode• 2 years ago

Not when I'm using some library function that's "helpful"

CuriousSkeptic• 2 years ago

I seem to recall a similar argument being made a while ago: https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf

bilalq• 2 years ago

Other languages may handle it differently, but having to manage threads is not a small compromise for going colorless. You're now forced to deal with thread creation, thread pooling, complexities of nested threads, crashes within child or descendant threads, risks of shared state, more difficult unit testing, etc.

dang• 2 years ago

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)

munificent4• 2 years ago

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".

vips7L6• 2 years ago

Don't sell Crafting Interpreters short!

zanellato19• 2 years ago

Do you still maintain more or less the same opinion from the post?

moralestapia5• 2 years ago

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)

anonymoushn9• 2 years ago

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 of function is entirely missing.

moralestapia5• 2 years ago

Can you give an example?

Rapzid6• 2 years ago

99.9% of these "colored" function articles have an incomplete or even flawed understanding of async/await symantics.

Fibers are not fungible with async/await. This is why structured concurrency is a thing.

pjungwir• 2 years ago

Great article! I'm looking forward to reading the rest of the series.

I noticed a couple details that seem wrong:

- You are passing `context` to `log_then_get` and `get`, but you never use it. Perhaps that is left over from a previous version of the post?

- In the fiber example you do this inside each fiber:

    responses << log_then_get(URI(url), Fiber.current)

and this outside each fiber:

    responses << get_http_fiber(...)

Something is not right there. It raised a few questions for me:

- Doesn't this leave `responses` with 8 elements instead of 4?

- What does `Fiber.schedule` return anyway? At best it can only be something like a promise, right? It can't be the result of the block. I don't see the answer in the docs: https://ruby-doc.org/3.3.4/Fiber.html#method-c-schedule

- When each fiber internally appends to `responses`, it is asynchronous, so are there concurrency problems? Array is not thread-safe I believe. So with fibers is this safe? If so, how/why? (I assume the answer is "because we are using a single-threaded scheduler", but that would be interesting to put in the post.)

hosh2• 2 years ago

So is Erlang/Elixir colorless or do those function calls have color?

juped• 2 years ago

Erlang has a preemptive SMP-using scheduler, so none of this really applies

vlucas2• 2 years ago

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 in a deeper layer. You have to know what the function does on the inside to even know what its performance impacts are.

Also, a nitpick - you can call async functions from sync ones, you just can't access the return value. Sometimes, you don't need to.

mananaysiempre• 2 years ago

It's a big neon sign that says "hey, this function call is expensive".

IMO the more important part is that it can yield control. Half the advantage of cooperative multithreading is knowing where you may yield control makes sharing memory more or less workable.

I also like Trio’s model: if it’s async, it will yield control, even if the result is already available so it doesn’t technically have to. Makes it more difficult to accidentally starve other tasks. (I suppose I also have to mention Curio’s model: if it’s async, it’s a scheduler upcall, whether yielding or not. But for all that Curio deserves credit for freeing Python from asyncio hell, I just don’t find myself caring about things being scheduler upcalls or not.)

newZWhoDis• 2 years ago

Ruby/rails is full of shortsighted crap like this.

I feel stuck, our whole backend is legacy rails and I can’t escape.

goatlover5• 2 years ago

Bit of a strong claim when the Erlang/OTP was designed to handle massive concurrency without colorful methods. Given that both Erlang and Ruby are inspired by the message passing semantics of Smalltalk.

rco8786• 2 years ago

Legacy codebases that are a joy to work with are few and far between, in any language.

segfaltnh• 2 years ago

Rails doesn't scale well in my experience. Or maybe rails devs don't scale well.

The language and framework are both centered around developer happiness, which in my experience drops off around 10,000 lines. That's about when projects start getting difficult.

norman784• 2 years ago

I also work on a legacy Ruby/Rails codebase, what I dislike is Ruby as a dynamic language, I'd prefer typed languages, but overall Rails didn't changed too much in the last 14 years that I know it (I didn't used too much in the past), but the concept is still the same to this day, few changes to the API/syntax, but otherwise if you know Rails, if you know Rails, it is most likely that you find very easy to work on any Rails app.

throw1092011• 2 years ago

Knowing ahead of time which functions are async is a feature.

"Expensive" is subjective and should be up to the programmer to decide.

And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.

This is a good thing for programmers to easily see and know at the call site.

Yes, and the IDE can show you that information, exactly like it does the types of arguments. We don't redundantly write the types of arguments at the call site because it's a good thing for programmers to see (which it is), we let the IDE do that.

mattigames• 2 years ago

Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us, why have underscore at the beginning of private variables? We can let the IDE do that, we even have long named functions instead of single letter ones? Most IDEs can read the jsdocs and give us a long description of what every function does, and I could go on and on. At the end it's a balance and subjective preferences of what you want to be immediately visible or something a bit more obscure (e.g. when you move your mouse over a variable)

CGamesPlay2• 2 years ago

And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.

I'm afraid I don't follow. It's impossible for you to have two identical functions (one sync and one async), since then they would both be sync. What did you mean?

lmm10• 2 years ago

And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.

Oh yes, absolutely. But the solution to that is stop using joke languages that can't do kind polymorphism.

Yes, and the IDE can show you that information, exactly like it does the types of arguments.

How can it, if the language doesn't give it that information? Either you have a language that can reliably distinguish between sync and async calls in a standard way - which is to say, it has a type system that distinguishes between sync and async, whether it calls it that or not - or your IDE has an ad-hoc informally specified bug-ridden slow implementation of half of one.

spankalee4• 2 years ago

And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.

This is very rarely necessary in app code. It's usually only a pattern for higher-level utility functions, and even then if you really wanted to you could unify implementations with generators.

wiseowise5• 2 years ago

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?

lta2• 2 years ago

is a feature

I was quite shocked to read this, as in it never brushed my mind that it could be. I personally doesn't feel like it is and is one of the reasons why I try to avoid working with that stack at all cost.

I don't think the neon sign is a good excuse for the mess colored functions are. You easily can create a synchronous O(n^4) function, and there are probably tons of quick async functions. Moreover, your comment might be read as a free pass for using functions and methods that you're not really understanding the behavior off, it obviously doesn't sound like a good thing

The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o).

slibhb• 2 years ago

Async/await is clearly a feature in JS, though not for the reason the previous poster mentions. Async/await wasn't part of the language until 2017. If you don't like it, you can just use Promises. If you do that, there are no "colored function" (functions of color?).

As far as the article goes, I think the pattern in Ruby is great. I prefer it to JS. But the JS approach works fine and the whole controversy about colored functions is a little silly.

I would be interested in understanding why JS can't enable await from inside non-async functions. I (maybe naively) wonder if the compiler couldn't just figure out which functions to treat as async rather than making the programmer do it.

lmm10• 2 years ago

The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o).

No, source code is where you hide the information, documentation is where you hide misinformation (or accurate information about how the function worked 3 versions ago, which is much the same thing).

unscaled3• 2 years ago

This is not just about performance.

Unlike Go or Ruby, JavaScript is a single-threaded language. Synchronization constructs such as mutexes and semaphores are uncommon and not part of any standard library. When you are calling a synchronous function, you can be completely assured that no race condition can develop while the function is running, but the same guarantee is not true for asynchronous functions.

That's why knowing which function is running asynchronously is even more useful for languages like JavaScript.

Joker_vD• 2 years ago

The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o)

That's exactly the mindset of quite a number of programmers nowadays, sadly. Two anecdotes: First, there was a blog post (probably even featured on HN) about problems in the design of the API of... Python's requests library, I think? It was quite a bizarre reading, complaints made almost no sense to me until I got to about the middle of the article when it clicked: the author was trying to figure out how to use the API by just reading the names of the classes, methods, and parameter names and making guesses as how it all would connect together instead of, you know, reading the docs. Which do exist, by the way.

The second example happened just yesterday at my job. In the essence, some fellow programmer added a call to function foo() which he thought would do some particular thing and return a particular answer while in reality it did not quite do that, and the return value is essentially meaningless (the function basically always returns "yep, I've scheduled do_foo() to run asynchronously some time soon"). Now, this foo() dunction is not documented, and if you read it's source (3 lines of code), it's quite obvious that its return value is useless... so why did they think it works the way they wanted it to work? When asked about it, the answer was "Well, it's named foo(), so I just thought that's what it would do". Sadly, calling strange third-party functions and hoping them to work they way you'd like them to work is no basis for writing the working programs.

akoboldfrying• 2 years ago

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".

resonious2• 2 years ago

This feels very true in Rust but not sure about JS. In JS you can `await` non-promise values without issue.

lolinder4• 2 years ago

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.

zogrodea3• 2 years ago

I had the same opinion with async/await, that it's nice to know a function performs IO and will wait before continuing. Makes it clearer when to use Promise.all to make multiple requests in parallel and wait for all of them to finish before continuing (faster than making calls sequentially).

I kind of wish the languages I use had Haskell's IO monad too, to separate functions in terms of the type system, but that's slightly different.

You might like this article (which is my personal favourite about function colouring). https://www.tedinski.com/2018/11/13/function-coloring.html

grumple• 2 years ago

I hate that async functions are the ones we are forcing to wait and become synchronous. The naming was a failure imo.

selfmodruntime• 2 years ago

Not really. What it really means is that some function in this callstack is expensive. Async Await bubbles to the top of your program. Eventually, you might just read this as this application as a whole might be expensive.

icholy• 2 years ago

Also, a nitpick - you can call async functions from sync ones, you just can't access the return value.

Or wait for them to finish.

dragonwriter3• 2 years ago

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"

Async and expensive aren't the same thing.

Also, a nitpick - you can call async functions from sync ones, you just can't access the return value.

That's a quirk of the particular async/await implementation in JS and not generally true of colored-function implementations. (Actually, since async/await is sugar for promises, you can actually, I’m pretty sure, both call and use syntactically async functions from ones which are syntactically not-async if you really want to, the code is just ugly.

klysm• 2 years ago

nit: I don't think _expensive_ is quite the right way to think about it. I view it as "hey, this function does IO". The actual cost of doing that IO varies immensely.

munificent4• 2 years ago

Knowing ahead of time which functions are async is a feature.

It can be, but this fact doesn't always scale well to larger APIs over time.

If you see that a function is async, any of these could be true:

1. The function does some asynchronous work.

2. The function did some asynchronous work at some point in the past, but does no longer, but changing the signature is a breaking API change, so it still looks async.

3. The function does no asynchronous work, but it's a public API and the library maintainer thinks there is a good chance it may need to do async work in the future so made it async today to reserve the right to make that change without breaking the API.

4. The function may or may not do asynchronous work, but it's part of an interface that others are allowed to implement and the designer of the interface wants to give implementers the freedom to make their implementations async if they want.

5. The function is higher-order and wants to be able to accept callbacks that are themselves async.

There are probably others I'm forgetting.

This all sounds hypothetical but it's really not. If you maintain any widely-used long-lived package, you run into design questions like this all the time.

There is always a tension between an API consumer wanting to know what a function "really" does versus the API author wanting some abstraction so that implementation details can be changed over time without breaking users.

Asynchrony is one kind of effect or observable behavior that a user/maintainer of an API may or may not want to encapsulate, but it's not the only one. The C++ standard library documents and commits to the algorithmic complexity of most functions. Haskell function signatures pin down whether or not a function does IO. Statically typed languages pin down the types parameters must be.

Pinning down more of this stuff gives the API consumer some more information, but it's not always a pure win. It calcifies the behavior of the function in ways that can harm its evolution or interact poorly with higher-order code or polymorphism. There's no silver bullet.

Personally, I've never found "does this function suspend" to be a particularly interesting effect for a function to have to commit to and the fact that it poisons the entire callstack makes it very difficult to work with in practice.

phplovesong• 2 years ago

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.

vlucas2• 2 years ago

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

caditinpiscinam• 2 years ago

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

unscaled3• 2 years ago

What about a language which has both lightweight threads, but in which every I/O operation (including printing and getting a random number) is colored?

https://www.haskell.org/tutorial/io.html

revskill• 2 years ago

I loved Ruby as a total beginner but hate it as an experienced programmer.

Colorless brings no meaning when i look at the signature of a method, which is a warning !

Async at the boundary, sync at the core is my favorite paradigm.

lofaszvanitt• 2 years ago

Ruby is like Japanese candlestick charts, both of them are absolute bullshit, idiotic things.

wiseowise5• 2 years ago

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<ReturnType>. You just mark potentially blocking function with suspend and you’re done.

vips7L6• 2 years ago

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.

wiseowise5• 2 years ago

runBlocking {}

downsplat• 2 years ago

Translated into simple language, Ruby chose to expose the multithreading paradigm (multple threads over shared data), like Java and others.

Multithreading is strictly more powerful than single threaded event loops. For some kinds of software there is just no alternative - a modern browser engine for example needs to be multithreaded.

The trade off is that you need to make sure your code is thread safe, which is not trivial as the collection of articles explains. That's your function color right there, green functions are verified thread safe, gray functions are not or not sure.

Personally in nearly 30 years of programming I've never needed to write multithreaded code. I still haven't found a business need that could not be met with suitable choices between multiprocessing (i.e fork) and event loops.

I'll definitely take wait/async programming over having to worry about concurrent thread safety any day of the week.

dmux• 2 years ago

    def log_then_get(url, context)
      puts "Requesting #{url}..."
      get(url, context)
    end
 
    def get(uri, context)
      response = Net::HTTP.get(uri)
      puts caller(0).join("\n")
      response
    end
 
    def get_http_thread(url)
      Thread.new do
        log_then_get(URI(url), Thread.current)
      end
    end

Good example of the downsides of dynamic typing:

1) get_http_thread takes a url (String) and converts it to a URI object

2) log_then_get defines its parameter as `url`, but really its expecting a URI object

3) get defines its parameter as `uri`, but we're passing it an argument called `url` from within log_then_get.

Lots of traps readily awaiting an unsuspecting programmer or newcomer to a project that contains code like this.

mst• 2 years ago

Even more onerous, if it isn’t built into your language core like JavaScript/node.js, adding it later means modifying your entire runtime, libraries and codebases to understand it.

Interestingly, while this has proven true of async/await for many languages it has not at all been true for perl.

The pluggable keywords feature lets us register 'async' and 'await' with the parser as (block scoped) imported keywords and with a little suspend/resume trickery you get https://p3rl.org/Future::AsyncAwait which I've been using happily pretty much since it was released (generally operating on https://p3rl.org/IO::Async::Future and https://p3rl.org/Mojo::Promise objects, often both in the smae process).

I even wrote https://p3rl.org/PerlX::AsyncAwait as a pure perl proof of concept later on, which injects computed gotos as resume points ala the switch/case trick you can use for resumable functions in C (nobody should really be using that one, mind, I wrote it to prove that I could and as potential fodder for https://p3rl.org/App::FatPacker usage later).

I do very much appreciate there are a lot of reasons one might dislike perl (I've been writing it long enough my list is probably longer than most naysayers') but its sheer malleability as a language remains unusually good.

lowbloodsugar• 2 years ago

Only having blue functions is not the same as being colorless.

Ruby methods are colorless

Related Stories