It must be tough running a Euro company, your own taxes end up funding your competitors!

> European cultural hostility to business

Is that the real issue? I thought it was that trying to compete in such a stacked market, against the incumbent Usual Suspects who are gorged on "R&D investment" packages makes SF VC look a cakewalk so you just move to the US instead.

You shouldn't skip the tutorial

The root issue is that the committe has no incentive to improve the language when the current situation enriches its key members, C++ is just the vehicle they co-opted to sell books, or consulting, on solving problems that they perpetuate.

I wish you were a writer too, I'd love to read that book!

There is a similar book about Hubspot, a "sister company" of the place I used to work. It was published around the time I was there:

https://en.wikipedia.org/wiki/Disrupted:_My_Misadventure_in_...

I can say that the people we hired from HubSpot were 100% frat-house-boys so I 100% believe it.

But back to the company I worked, there were very stupid shit going on:

Around #MeToo, there was a group meeting with all men in the company because of fears of sexual harassment issues. Nobody close to me had any idea about the root cause, and there were some very strangely sexist comments in the meeting. Some people (including one later fired for non-sexual harassment) made it a personal soapbox and went into rants. The CEO completely mishandled it.

Also there was once an anonymous blog about the practices of the company that was totally blown out of proportion by management, and all employees had to attend a meeting to talk about it. Once again the CEO mishandled it, first by paying any attention and second for being incredibly awkward and super-defensive.

This was the main reason the CEO was ousted.

After I left the company there was a string of CEOs that acqui-hired all the competitors and basically drained the company's coffers. And of course the over-hiring, getting to 900 people on a pyramid scheme.

I forgot to tell the main product the company made: SEO blogspam. Yep.

Last year it collapsed because of our mutual friend, ChatGPT.

Same, it still feels like too much of a grift for VC monies to me.

Not a hater, though it's fun to run Doom in a browser tab... just can't see any business value in 99% of its ecosystem, especially with the drift away from web (the only niche where it made sense).

There’re fundamental libraries that can be used on the web because of wasm: imagemagick, ffmpeg, opencv, duckdb, sqlite, figma’s render engine...

Just because 95% of web apps are crud DOMs doesn’t mean such technology is not important.

Software 'engineering' is too abstract, yet imagine the outrage if every new highway had a 20km/h limit...

The final piece (writing code) eating more than 10% of your dev time "for decades" is a good indicator to find a new career imo.

Writing code is design, not mere assembly. I can only imagine the kind of solutions created by someone who whiteboards for 7 hours a day and codes for one.

No PMs is the real growth hack.

Awesome, thanks.

Does C++ have a good async ('coroutine') story for io_uring yet?

Great question! This has been top of mind for me for the last 2–3 years.

Short answer: sadly, no. I love the "usability" promise of coroutines—and even have 2–3 FOSS projects that could be rewritten entirely around C++ or Rust coroutines for better debuggability and extensibility—but my experiments show that the runtime cost of most coroutine‑like abstractions is simply too high. Frankly, I’m not even sure if a better design is possible on modern hardware.

This leads me to conclude that, despite my passion for SIMD and superscalar execution, the highest‑impact new assembly instructions that x86 and Arm could standardize would center on async execution and lightweight context switching... yet I haven’t seen any movement in that direction.

⸻

I also wrote toy examples for various range/async/stream models in C++, Rust, and Python, with measured latencies in inline comments:

  - Python: <https://github.com/ashvardanian/less_slow.py/blob/2c80c9dda6ef9aec18264871cfb51a13ac34685d/less_slow.py#L711-L722>
  - C++: <https://github.com/ashvardanian/less_slow.cpp/blob/8f32d65cc8976ad20c8cdf645caa5b39a1cf488b/less_slow.cpp#L3718-L3759>
  - Rust: <https://github.com/ashvardanian/less_slow.rs/blob/5add609533854bb6a5ddbf358cc15f06f68c82d2/less_slow.rs#L522-L533>

Aside from coroutines (toy hand-rolled implementations and commonly used libraries), I've also played around C++ executors, senders & receivers, but didn't have much success with them either. May be a skill issue.

> my experiments show that the runtime cost of most coroutine‑like abstractions is simply too high

Which runtime cost do you mean?

The main one I am aware of is a heap allocation per coroutine, though this can in some cases be elided if the coroutine is being called from another coroutine.

The other cost I am aware of is the initializing of the coroutine handle, but I think this is just a couple of pointers.

In both cases I would expect these overheads to be relatively modest compared to the cost of the I/O itself, though it's definitely better to elide the heap allocation when possible.

I don't know much about coroutine libraries like unifex (which I think your test is using), but a hand-coded prototype I was playing with doesn't seem to add much overhead: https://godbolt.org/z/8Kc1oKf15

If we can compile with -fno-exceptions, the code is even tighter: https://godbolt.org/z/5Yo8Pqvd5

My exploration into coroutines and I/O is only in the earliest stages, so I won't claim any of this to be definitive. But I am very interested in this question of whether the overhead is low enough to be a good match for io_uring or not.

> lightweight context switching

the cost of context switch consists of two parts, one of which can be subdivided:

1. register save/restore

       1a. user-space only registers
       1b. full register save/restore, required in kernel space

2. the cost of the TLB flush, which is in turn proportional to the working set size of the switched-to process (i.e. if you don't touch much memory after the context switch, the cost is lower than if you do)

I am not sure that any assembler instructions could address either of these.

What do you have in mind?