mzimbres's comments

> In my experience simple blocking code is incredibly misunderstood.

I don't think so. You can't even implement a full-duplex protocol properly with sync IO since reading and writing can't happen at the same time on the same thread. Splitting them to different threads also won't help since accessing shared state requires synchronization with e.g. mutex that kills again simultaneous reading and writing.

> In actual real applications it is not always possible

This depends on what are your expectation. IO operations must suspend to wait for data read and writes, therefore it is not possible to avoid Async/Await. In other cases you might have multiple tasks depending on a specific IO operation, for example, one connection to a database that is used by multiple HTTP sessions, here it is also not possible to avoid Async/Await because those sessions are bound to an IO operation.

The real problem however comes when tasks that can complete synchrously are implemented with an asynchronous interface, for example

  message = Await websocket.read(socket, buffer, ...)

This is a poor design because a socket read can pull multiple messages from the kernel buffers into user space and there should be a way to consumed them without Await. Many libraries however don't for watch this problem and that results in the everything is async madness.

Only in poorly designed code you have problems like this where Async Await goes viral. It can be avoided by spiting libraries into an IO part that uses Async/Await and a protocol part that is sans-io. Using async code to access data that is already in the application memory is inefficient and should be implemented synchronously with regular functions instead of asynchronously.

Here is a low hanging fruit for governments around the world fighting low birth rates. Allow your people to work from home and they will start having more babies, simplle as that. I am my wife had to switch jobs just so we could work more from home, an unnecessary annoyance.

I wonder how did they shared the meat with the rest of the group after chasing down the prey for an hour in random directions.

Implementing full-duplex protocols asynchronously is much simpler.

So why rotten meat smells terrible and a steak delicious? Why would we evolve that perception of something that nutritious and which could prevent me from starving. Why my nose keeps telling me to keep away from rotten meant?

I haven't created Redis itself but a Redis client library. It all started with a chat server I wanted to write on top of Boost.Beast (and by consequence Boost.Asio) and at the time none of the clients available would fill my needs and wishes

- Be asynchronous and based on Boost.Asio.

- Perform automatic command pipelining [1]. All C++ libraries I looked at the time would open new connections for that, which results in unacceptable performance losses.

- Parse Redis responses directly in their final data structures avoiding extra copies. This is useful for example to store json strings in Redis and read them back efficiently.

With time I built more performance features

- Full duplex communication.

- Support for RESP3 and server pushes on the same connection that is being used for request/response.

- Event demultiplexing: It can server thousands of requests (e.g. websocket sessions) on a single connection to Redis with back pressure. This is important to keep the number of connections to Redis low and avoid latency introduced by countermeasures like [3].

This client was proposed and accepted in Boost (but not yet integrated), interested readers can find links to the review here [2].

[1] https://redis.io/docs/manual/pipelining/

[2] https://github.com/boostorg/redis/issues/53

[3] https://github.com/twitter/twemproxy

> But as more and more engineers joined us, some shortcomings > of C++ came to bite us: unreadable coding style, memory leak, > segmentation fault, and more.

* unreadable coding style: This is not a C++ problem. * memory leak: Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers.

The only point that could be attributed to C++ is the segfaults perhaps, due to its lack of safety. But your other two points made me skeptical about Rust bringing you much benefit. I am specially concerned about throwing away months worth of code. Rewriting everything from scratch is what newbies love to do and will most likely get you in the same mess you were in. Try to learn with the error of others [1]. And btw, the problem is usually who writes the code and not which language is used.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Senders and Receivers is the next big thing Eric is delivering to C++, stay tuned.

Human beings have been living in europe for over 100,000 years. White skin doesn't seem to be older than a 10,000 years (see the skin analysis of the first briton). I don't think it would have taken so much time to evolve white skin had it really had the importance that is being attributed to it nowadays. I am very skeptical about its importance on preventing not only covid but also many other deseases.

For the purpose of climate change I believe it would be enough to breed elephants that adapt well to could climates and populate the area with them.

Nobody postulated that the speed of light is constant because it was obvious: light just like every other wave has a constant speed in the medium though which it propagates. The fact that nothing can go faster is a consequence of the Lorentz transformation, so nothing had to be postulated. The important thing that Einstein recognized is that the Lorentz transformations apply for all physical phenomena and not only the Maxwell equations and that started a revolution on physics.