Re: What is this "Beman Project Development"?

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2024-05-10 15:53:02

Fwiw, I think C++ as a language has never been at a better place.
There's so many great things in the language now like coroutines,
concepts, placeholder NTTPs, CNTTPs, designated initializers.

The list goes on and on. I think it's hard to argue against the direction
that
C++ is evolving as a core language.

I would say that LEWG's output is less than optimal and this is because
LEWG can't thrive without a Boost and Boost can't thrive without LEWG's
participation.

They need each other and Project Beman is an attempt to return to that form.
If it actually brings LEWG members back to a Boost-like place, that's only
really a positive for C++.

re: coroutines vs fibers

Stackless coroutines are a better fit for standardization. The exemplar of
the
success of stackful coroutines is Go. Many other GC'd languages have fiber
implementations as well like Kotlin/Java.

The thing to note here is that these languages also have incredibly
sophisticated
runtimes that enable them to make efficient usage of these constructs.
Systems
languages have to use system APIs to create fibers which is something hard
to
retrofit against the C++ abstract machine.

Stackless coroutines are a simple front-end transformation so they're easy
to fit
against C++'s abstract machine which is why they were kind of a slam dunk to
standardize.

And I think they're actually quite good as well. I've written async
networking implementations
in both Rust and C++ and personally, I think C++'s are better solely for
how they handle
resuming an awaiting task.

I don't think the function coloring thing is an issue in practice or at
least it's never something I've
run up against even when I worked full time in Node. I've seen a lot of
Rustaceans complain
equally about this but I think it's because they're trying to shoehorn a
design that just isn't workable
with the tools available and they're refusing to compromise.

One thing I've seen that surprised me was the contortions a Gopher will go
through to guarantee
a suspension point. It's interesting that in practice, the implicit
suspension of a routine becomes undesirable
because at a point in time, a user wants to *guarantee* a suspension and an
explicit `co_await` or `.await`
gives the developer a sense of psychological security.

In short, it's a good thing Asio wasn't standardized as it was because it
included async. It should've just been
blocking I/O only. The other problem is, its interfaces are heavily coded
against *existing* networking system APIs
and now that we have io_uring, we see that the evolution of operating
systems introduces backwards-incompatible
API breaks.

It's also a good thing fibers weren't standardized because it's hard to get
right in the context of an IS and an
abstract machine. If fibers are really such a good idea, then they'll
emerge as the successor in the free market
of libraries.

- Christian