It's even easier to repeat without async-await, where you don't need to tag the function call with `await`!

> Think about it, you can't `await` on part of the state only once and then know it's available in other parts of code to avoid async pollution. When you solve this problem, you realize `await` was just in the way and is completely useless and code looks exactly like a callback or any other more primitive mechanism.

I don't understand why you can't do this by just bypassing the async/await mechanism when you're sure that the data is already loaded

```

data = null

async function getDataOrWait() { await data_is_non_null(); // however you do this return data }

function getData() { if (data == null) { throw new Error('data not available yet'); } return data; }

```

You aren't forced into using async/await everywhere all the time. this sounds like 'a misuse of the interface, a lesson in interface design', etc

> I think "how to express concurrency" is a question I'm not even trying to answer

You can't criticise async/await, which is explicitly a way to express concurrency, if you don't even care to answer the question - you're just complaining about a solution that solves a problem that you clearly don't have (if you don't need to express concurrency, then you don't need async/await, correct!)

> point to approaches that completely eliminate pollution and force you to write code in that "unrolled" way from start, something like Rx or FRP where time is exactly the unit they're dealing with.

So they don't 'eliminate pollution', they just pollute everything by default all the time (???)

My comment was responding only to the person who equated threads and async. My comment only said that async and threading are completely orthogonal, even though they are often conflated

> `is_something_true` is very simple, if condition is true, and then inside the block, if you were to check again it can be false, something that can't happen in synchronous code

It can happen in synchronous code, but even if it couldn't - why is async/await the problem here? what is your alternative to async/await to express concurrency?

Here are the ways it can happen:

1. it can happen with fibers, coroutines, threads, callbacks, promises, any other expression of concurrency (parallel or not!). I don't understand why async/await specifically is to blame here.

2. Even without concurrency, you can mutate state to make the value of is_something_true() change.

3. is_something_true might be a blocking call to some OS resource, file, etc - e.g. the classic `if (file_exists(f)) open(f)` bug.

I am neutral on async/await, but your example isn't a very good argument against it

Seemingly nobody ever has any good arguments against it

> async-await pollutes the code completely if you're not strict about its usage

This is a good thing, if a function is async then it does something that won't complete after the function call. I don't understand this argument about 'coloured functions' polluting code. if a function at the bottom of your callstack needs to do something and wait on it, then you need to wait on it for all functions above.

If the alternative is just 'spin up an OS thread' or 'spin up a fiber' so that the function at the bottom of the callstack can block - that's exactly the same as before, you're just lying to yourself about your code. Guess what - you can achieve the same thing by putting 'await' before every function call

Perhaps you have convinced me that async/await is great after all!

That being said, I don't understand your `is_something_true` example.

> It's very often used to do 1 thing at a time when N things could be done instead

That's true, but I don't think e.g. fibres fare any better here. I would say that expressing that type of parallel execution is much more convenient with async/await and Promise.all() or whatever alternative, compared to e.g. raw promises or fibres.

This is a bizarre remark

Async/await isn't "for when you can't get your head around threads", it's a completely orthogonal concept

Case in point: javascript has async/await, but everything is singlethreaded, there is no parallelism

Async/await is basically just coroutines/generators underneath.

Phrasing async as 'for people who can't get their heads around threads' makes it sound like you're just insecure that you never learned how async works yet, and instead of just sitting down + learning it you would rather compensate

Async is probably a more complex model than threads/fibers for expressing concurrency. It's fine to say that, it's fine to not have learned it if that works for you, but it's silly to put one above the other as if understanding threads makes async/await irrelevant

> The stdlib isn't too bad but last time I checked a lot of crates.io is filled with async functions for stuff that doesn't actually block

Can you provide an example? I haven't found that to be the case last time I used rust, but I don't use rust a great deal anymore

If you're looking for a cheap practical tool + don't care if it's not local, deepseek's non-reasoning model via openrouter is the most cost efficient by far for the work you describe.

I put 10 dollars in my account about 6 months ago and still haven't gotten through it, after heavy use semi regularly.

With RAII you need to leave everything in an initialized state unless you are being very very careful - which is why MaybeUninit is always surrounded by unsafe

    {
        Foo f;
    }

    std::vector my_vector(10000);

Even if I just want a std::vector to use as a buffer, I can't - I need to manually malloc with `(uint8_t)malloc(sizeof(uint8_t)*10000)` and fill that

So what if the API I'm providing needs a std::vector? well, I guess i'm eating the cost of initializing 10000 objects, pull them into cache + thrash them out just to do it all again when I memcpy into it

This is just one example of many

another one:

with raii you need copy construction, operator=, move construction, move operator=. If you have a generic T, then using `=` on T might allocate a huge amount of memory, free a huge amount of memory, or none of the above. in c++ it could execute arbitrary code

If you haven't actually used a language without RAII for an extended period of time then you just shouldn't bother commenting. RAII very clearly has its downsides, you should be able to at least reason about the tradeoffs without assuming your terrible strawman argument represents the other side of the coin accurately

I think this is very clear, I don't know why you're saying that tigerbeetle is trying to make a generic claim about general workloads

The comment you're replying to explicitly states that this isn't true for general workloads

For local inputs, the fixed timestep is always a frame or smaller, this is not an issue unless you're over a network

Edit: Oh i see, this is a problem with the commenters suggestion of predicting the future though

Sorry; my point was that adding this function as a public API 'onion layer' in your code means you're less able to adapt to change. The fact this function returns a `User` entity isn't particularly important - it's the fact when you make a function public, other teams will reuse your function and add invariants you didn't realise existed, so that changing your function in the future will break other teams' code.

Less public 'onion layers' means less of this

So let's say you have some 'User' ORM entity for a food app. Each user has a favourite food and food preferences. You have a function `List getListOfUsersWithFoodPreferences(FoodPreference preference)` which queries another service for users with a given food preference.

The `User` entity has a `String getName()` and `String getFavouriteFood()` methods, cool

Some other team builds some UI on top of that, which takes a list of users and displays their names and their favourite food.

Another team in your org uses the same API call to get a list of users with the same food prefs as you, so they loop over all your food prefs + call the function multiple times.

Amazing, we've layered the system and reused it twice!

Now, the database needs to change, because users can have multiple favourite foods, so the database gets restructured and favourite foods are now more expensive to query - they're not just in the same table row anymore.

As a result, `getListOfUsersWithFoodPreferences` runs a bit slower, because the favourite food query is more expensive.

This is fine for the UI, but the other team using this function to loop over all your food prefs now have their system running 4x slower! They didn't even need the user's favourite food!

If we're lucky that team gets time to investigate the performance regression, and we end up with another function `getListOfUsersWithFoodPreferencesWithoutFavouriteFoods`. Nice.

The onion layer limited the 'blast radius' of the DB change, but only in the API - the performance of the layer changed, and that broke another team.

Layers of generic APIs required to be 1000x more complex than would be required if they were just coupled to the layer above

Changing requirements means tunneling data through many layers

Layers are generic, which means either you tightly couple your APIs for the above-layer's use case, or your API will limit the performance of your system

Everyone who thinks they can design systems does it this way, then they end up managing a system that runs 10x slower than it should + complaining about managers changing requirements 'at the last minute'

It would be interesting to see the performance of a `Vec<&str>` where you reuse the vector, but also a `Vec` where you copy the path bytes directly into the vector and don't bother doing any pointer traversals. The example path sections are all very small - 'inner', 'another', 5 bytes, 7 bytes - less than the length of a pointer! storing a whole `&str` is 16 bytes per element and then you have to rebuild it again anyway in the invalid case.

---

This whole article is kinda bad, it's titled 'blazingly fast linked lists' which gives it some authority but the approach is all wrong. Man, be responsible if you're choosing titles like this. Someone's going to read this and assume it's a reasonable approach, but the entire section with Vec is bonkers.

Why are we designing 'blazingly fast' algorithms with rust primitives rather than thinking about where the data needs to go first? Why are we even considering vector clones or other crazy stuff? The thought process behind the naive approach and step 1 is insane to me:

1. i need to track some data that will grow and shrink like a stack, so my solution is to copy around an immutable Vec (???)

2. this is really slow for obvious reasons, how about we: pull in a whole new dependency ('imbl') that attempts to optimize for the general case using complex trees (???????????????)

You also mention:

> In some scenarios, where modifications occur way less often than clones, you can consider using Arc as explained in this video

I understand you're trying to be complete, but 'some scenarios' is doing a lot of work here. An Arc<[T]> approach is literally just the same as the naive approach but with extra atomic refcounts! Why mention it in this context?

You finally get around to mutating the vector + using it like a stack, but then comment:

> However, this approach requires more bookkeeping and somewhat more lifetime annotations, which can increase code complexity.

I have no idea why you mention 'code complexity' here (complexity introduced by rust and its lifetimes), but fail to mention how adding a dependency on 'imbl' is a negative.

That is, unless you explicitly handle OOM conditions inside your construct, e.g. 'crash if you're OOM', which isn't typical in zig code. All code I interact with will return an allocator error if allocation fails.

Hmm this seems like something super specific to their async setup, rather than 'common lisp leaks memory'