After so wrote the comment below I realized that it really is just ‘um, actually…’ about discussing using concurrency vs implementing it. It’s probably not needed, but I do like my wording so I’m posting it for personal posterity.

In the context of an article about C++’s coroutines for building concurrency I think structured concurrency is out of scope. Structured concurrency is an effective and, reasonably, efficient idiom for handling a substantial percentage of concurrent workloads (which in light of your parent’s comment is probably why you brought up structured concurrency as a solution); however, C++ coroutines are pitched several levels of abstraction below where structured concurrency is implemented.

Additionally, there is the implementation requirements to have Trio style structured concurrency function. I’m almost certain a garbage collector is not required so that probably isn’t an issue, but, the implementation of the nurseries and the associated memory management required are independent implementations that C++ will almost certainly never impose as a base requirement to have concurrency. There are also some pretty effective cancelation strategies presumed in Trio which would also have to be positioned as requirements.

Not really a critique on the idiom, but I think it’s worth mentioning that a higher level solution is not always applicable given a lower level language feature’s expected usage. Particularly where implementing concurrency, as in the C++ coroutines, versus using concurrency, as in Trio.

Is there a reason Rust would not (as it was done in the ‘good ole days’) index the table via pointer arithmetic from .data? Also, I’m assuming that because you are discussing new devs, that they are not making the implementation decision to place the table on the heap and using Rist’s subscript operator, which I would understand Rust not doing as default. I can not think of a reason that the table should ever be put on the stack for reading a single value, so that being the default seems an oddly pessimistic default. I could be missing something regarding how Rust handles literal data ‘written out’ into source though.

The table is on the stack because we conjured into existence a temporary, so it's exactly as if the programmer had conjured the variable as a local by hand. Suppose our table is named SOUP

    const SOUP: [f32; 1000] = [ /* whatever */ ];
    let foo = something(blah_blah, blah) * SOUP[4];
    // The optimiser will see that SOUP[4] is exactly say 1.5_f32 so it'll just do
    // the same as if we'd calculated something(blah_blah, blah) * 1.5_f32

However

    let foo = something(blah_blah, blah) * SOUP[blah];

Now blah is a variable, we might need any value from SOUP, the optimiser doesn't know what values it might have - so a temporary is conjured into existence, equivalent to:

    let tmp = SOUP;
    let foo = something(blah_blah, blah) * tmp[blah];

You do presumably recognise that this now puts SOUP on the stack right? The temporary is equivalent, but without the explicitness.

Now if you know what you're doing you would of course have one single place in your program where you do this:

    static SOUP: [f32; 1000] = [ /* whatever */ ];

And now there's an immutable global named SOUP and like "the good ole days" we don't keep writing this huge data blob to the stack only to subsequently look at a single element. But that's not the thing the noob wrote so that's not what they get.

"Sufficiently smart compilers" are a very gradual miracle. In theory a compiler could realise this is a good idea, in practice today I doubt you will find such a compiler, so just write explicitly that you want a single variable if that's what you want.

Regarding your mention of compiler magic and Swift, I don’t know much about the language, but I have read a handful of discussions/blogs about the compiler and the techniques used for its implementation. One of the purported benefits/points of pride for Swift that stood out to me and I still remember was something to the effect of Swift being fundamentally against features/abstractions/‘things’ being built in. In particular they claimed the example of Swift not having any literal types (ints, sized ints, bools, etc) “built in” to the compiler but were defined in the language.

I don’t doubt your point (I know enough about Swift’s generic resolution crapshow during semantic analysis to be justified in assuming the worst) but can you think of any areas worth looking into for expansion of the compiler magic issues.

I have a near reflexive revulsion for the kinds of non-composability and destruction of principled, theoretically sound language design that tends to come from compiler magic and shortcuts, so always looking for more reading to enrage myself.

> literal types (ints, sized ints, bools, etc) “built in” to the compiler but were defined in the language.

This is actually a good example by itself.

Int is defined in swift with Builtin.int64 IIRC. That is not part of the swift language.

I don’t know if the language is yours, but I think the wording and its intended meaning (the sentence starting with ‘The core implementation…’) may be one of the most concise statements of my personal programming language design ethos. I’m jealous that I didn’t come up with it. I will certainly credit you when I steal it for my WIP language.

I will be adding the following to my “Primary Design Criteria” list: The core design and implementation of any language feature is explicitly targeted at the efficient creation of opinionated, composable abstractions rather than providing those abstractions at the language level.

I think your comment leads to discussing a distinct third ‘cause’ for open source development: where a developer realizes their ambition is greater than their abilities, either in the technical sense or (more likely) in the sense that a single developer stands no realistic chance of ever completing an implementation of the idea alone.

For this class of open source development the authors essentially require the contributions and gifts of others for the project to even be realizable. I think this is the underlying basis for open source’s move toward a more “community” development model. It has led to open source being viewed by many as requiring a community and a “managed” community at that, to be open source. I think this class of open source is going to be impacted the most by LLM ‘assisted’ development (no matter how much distaste it generates for me and many others), where the hurdles of large scale development are more in reach (seemingly) for solo or very small groups of developers.

The really interesting thing is going to be to see how many of these projects move toward the Carmack ‘gift’ model and look to leave the community-centric model behind as an unnecessary externality.

I think your idealized list of attributes of “open source” is admirable. However, the apprenticeship, comradery, and support are a specific and often sought out feature of some development ‘communities’ for specific software. I’d also say that the ‘loss’ when fixes, updates, optimizations of open source software is not up-streamed is real, but this has very little to do with adopting or promoting the externalities (no matter how laudable) you want to see in certain software’s development.

I personally don’t care about the community, its composition, or its internal structure for a lot of software I use. Even when I’m compiling from source and customizing smaller applications for personal efficiency, I’m not usually interested in being a part of some distributed community centered on that software. Some times I am engaged in the community and appreciate it and the work required to maintain that community. But in either case, the software is “open source”.

I always think about this section when I consider making my personal programming language public. I think if language development was, in 2026, happing the way ESR describes Linux here I might be more persuaded to release. But as it stands now, almost all modern language development is done in the rigid, semi-planned, hierarchical, and “cathedral”-esque development style.

The expectations for language developers is currently huge burden and a massive undertaking, even for small languages that look to publicize at nearly any level. The amount of users that seem to insist on participation in the language’s progress, semantics, or implementation is the vast majority of any online/vocal user base and those same voices seem to view languages with different development models as inherently toys.

I’m sure this is where I am expected to reference Rich Hickey’s comments/post about Clojure development, but I don’t have the link on mobile. But the discussions are legion and legendary at this point.

I think you have confused RMS (Richard Stallman) and ESR (Eric S. Raymond). It was ESR that coined and popularized the cathedral and bazaar development analogy and terminology. It was also ESR who was at the conference your comment is discussing. RMS is “free software”, copyleft, and GNU. ESR is “open source” and the author of ‘The Cathedral and the Bazaar”.

Of course, I could have misunderstood your comment, if so, mea culpa and feel free to ignore.

I agree that from the perspective of the implementation of async code, it is in many ways an application doing its own threading and context switching. However, your Parent comment is written from the perspective of the dev writing and reasoning about the code. In that case, from the devs perspective, async is there to make concurrent code ‘look like’ (since it certainly is not actually) sequential code.

I think this type of confusion (or more likely people talking past one another in most cases) is a fairly common problem in discussing programming languages and specific implementations of concepts in a language. In this case the perceived purpose of an abstraction based on a particular “view point”, leads to awkward discussions about those abstractions, their usefulness, and their semantics. I don’t know if there is way to fix these sorts of things (even when someone is just reading a comment thread), but maybe pointing it out can serve to highlight when it happens.

To be specific, and it is a lot of the reason why this 5 month delay happened, but she was not dragged then held, she was arrested, then held, then dragged. She was released 5 days after finally getting to Dakota, if they had actually gone and gotten her the hold would have been ~30 days plus the 5 prior to interview and charges dropped.

It isn’t much of a salve, but the particulars do matter when trying to assess fault to the proper parties (who are still clearly the Fargo cops in this particular tragedy).