Synchronous vs Asynchronous Programming

What puzzles me the most about names here is that I must identify synchronous with sequential and asynchronous with synchronous. And I don't have to translate parallel to anything else.

I was going to type one single word in response - erlang - but you slipped it in at the end.

Please tell people not to scatter mutexes and semaphores around their code. That is a way to create a completely untestable system. And if you have to design a concurrent system, check out the Spin model checker (Turing Prize, I believe). I haven’t looked into Leslie Lamport’s (another Turing Prize) TLA+, but I believe it provides similar formal verification as Spin.

This stuff is damned hard, but we have some very smart people who spent decades making it accessible for us more pedestrian types… :D

Built my latest micro service product using web external calls and async messaging for internal / inter service comms. Performance is very good but you need a good package and clear conventions on commands etc.

This is the best explanation of asynchronous programming ever ❤🎉

Having such messaging queues it seems like one could even make an app that is expected to work offline for long periods of time. Just have a sufficiently large ring buffer and it'll continue to function offline as if the server doesn't want it to do anything. For an application that for example mostly takes data input from the user that should work fine. Once it gets any type of network access it'll start outputting its new data and possibly receive queued up requests from the server. All of it without the need for any special offline mode logic.

Love that shirt!

This discussion all touches on why the Actor Model (from the early 70s) is making a renaissance in the context of large scale distributed microservice systems. Message and queue-based single-threaded actors within a bounded context. Event-driven choreography between contexts.

Hi Dave, I've worked in an organization that tried (or thought it tried) to do what you describe at the end of your video, break the system down to such a degree that the call stack was all asynchronous (In that case using MQM for the messaging) it did not go well. The reasons why are too involved to fully state here but one clear one was the state of an entity (say a customer record) being changed at one point in some context and a delayed or replayed message in another context then not finding the entity in the expected state (resulting in an unrecoverable situation). Clears this can be avoided with better design. But IMHO this needs to be thought about and designed for. So I don't think it's a good idea to just try to make a sync program async without thinking carefully about this type of issue (and others). BTW could not agree more on async await, having to use it a lot in my current project, not good.

oh i remember reading about the lmx disruptor many many years ago. before i knew anything about development. i think it was one of the moments you become a little more concious

Great video, it remembers me why I choose Elixir.
Do you have a link to the conference talk that inspired this video?.
Thanks and keep sharing knowledge!

Hey Dave, great content, but can you work on the audio quality? It's really dull sounding at the moment. Maybe a different microphone or some processing can fix this. The acoustics seem good, no excessive reverbs.

The answer is project Loom.

About async await, I do use it

But in my defense, I am very ashamed of it every time

Erlang, Elixir & Pony for the win

Love the Erlang comment Dave made me chuckle 😀 Of course, one could always take the gateway drug that is Akka hahahah 😀

I've been designing and developing asynchronous software since the early 1980s, though that may be because I got my start working on asynchronous serial communications in terminal devices. When I design anything that communicates with users or other programs/systems, I always start with an asynchronous model. Even given the concurrency concerns that go into the design of the data structures, the application code is usually far simpler and less prone to performance problems.

I have several war-stories about this sort of thing that I'd love to describe, but this is not the time or place for that sort of thing.

This really , really important , i in my experience alway was nervous about all that concurrency nonsense, nobody was able to explain me why real time stock exchange works perfectly nobody.

So you're saying I should use Node.js?

¡Gracias!

I love this philosophy-of-technology channel! I learned a lot from your videos!

Hi Dave, I think you're doing a great job by presenting the concepts but you might be jumping maybe, MAYBE, too fast through them. For example asynchronous vs synchronous programming in a single thread which is a discussion on it's own. Then jumping immediately to asynchronous communication between systems, which is another topic and there is a place for async and there is a place for synchronous communication. And then there came the last important topic event sourcing vs event driven architecture which again wasn't explained as a separate important to understand topic. I really do enjoy you're content and I'm not saying this and I hate myself that I realise that I offered a classic feedback sandwich

How do you make the background animations of your videos? They are well made. Are they made by an animator person?

I kept thinking of Hexagonal Architecture and Event Sourcing while watching this video.

This sounds like the asynchronous communications in hardware I learned in the 80's.

What makes you say the async-await abstraction is "crazy"? Because in my mind it's really just syntactic sugar to flatten callback chains und thus reduce syntactic noise. And why isn't that a good thing?

Erlang!

While I agree that we should face the complexity of the real world and computers are inherently non concurrent, the analogies are pretty lazy. CPUs don’t queue, data that needs a CPU to be thought do.

Additionally, everything is taught from basic ideas to more complex. The idea that we should start with asynchronous is ridiculous. However, I do think CS education should move on from synch. programming much earlier than late term, or worse. Certainly a minor in CS should make this reality apparent to the student.

It's really nice approach, but unfortunately not always feasible, working on finance, specially on loans simulations, we had do call 15 services or more, and almost all of them were dependent on the previous service response to work. Maybe a total revamp of the underlying services and business logic would be needed so they would be able to be called asynchronously ... But it is really hard not to say impossible to a huge company to undertake a massive change in their core business ...

Interesting!
Would the send() interface return an error (eg. Can't enqueu / won't send) or would that break pure asynchronicity?

Also, how would you manage a distributed data set in which you might want to quickly split or join sets managed by s single thread/ node?

Damn that shirt is awesome!

How do you see the development of implicit async programming style in the nearest future?

I.e. the program code doesn't have ANY async operations at all (no async/await, send/receive, start thread etc).

Yes! Been waitin' for this topic.
Another awsome t-shirt! 😃

Thank you for a super excellent video. I had the incredible luck to learn programming in assembler on mainframes where the complexity is not as hidden as in higher level languages. So my "normal" is probably more comfortable with asynchronous programming than most. Then I went on to write program debuggers which is all about asynchronous event handling. So when I wrote a phone app with an async messaging interface, I was not surprised at how well it performs - what had not occurred to me was how easy it is to debug. Since every interaction is encapsulated into a message, all you need to do is save a copy of the message stream and you have an excellent map to guide your bug hunt. Hours upon hours saved because the need to go back and try to reproduce a problem is eliminated. I have spent dozens of years fixing bugs in other people's code and usually the hardest most time-consuming bit is figuring out how to reproduce the problem and narrowing down the culprit code. I handled the shared data modification complexity by having all updates handled on a single device. Also important to make each message atomic and delivery order agnostic because Firebase messaging does not guarantee ordering. In the few cases where there was too much data for a single message, the incoming queue is used to sort that out. Long story short- I've gone from being tolerant of async interfaces to becoming a full blown fan.

First of all, after 25 or more years of writing parallel/distributed systems code, I can safely say that i'm not afraid of concurrency or asynchronicity of any kind. Second, I don't think that async makes debugging easier, or that it allows for replaying a program, based on the log of the events. The most important reason is that (assuming independent clocks) you cannot order the events in the various machines, can you? next point, you said you wished software engineers were taught to write asynchronous s/w from day 1 of training. Unless one were trained as a hardware engineer, I don't think this programming paradigm would sit well with them. Finally, congratulations on your book "Modern Software Engineering"; but I have to mention, my first degree is in Electrical Engineering. I don't recall any course called "Electrical Engineering" throughout my course of study, and I believe in modern s/w engineering programs, there should be no course titled "Software Engineering". Just my 2c.

That was extremely informative, fantastic stuff

It is little disappointing that your example is basically how TCP is done. It is hard to see past the trivial solution - just use sync operation over TCP.

Hi Dave, great video! I was wondering if you could give your opinion about the Rx family of reactive systems, how do you see them fit into this picture?

Nine times out of ten (at least), when I make a call to a service, the user can't do anything until the response is received, and if the response comes back with an error the user can't do the next step anyway. The exceptions are when the user can go do something else, in which case the call can simply spawn a background task to run a job.

Most developers aren't nearly as clever as they think they are, but that doesn't stop them from making a mess of even trivial things. However, in an async world they are far less brave as the 'complexity budget' is largely spent. I've found that actually makes things easier as you're tackling essential complexity, which is researchable, vs some wannabe 'architect's layer on top of JPA (or whatever).

Asynchronous made me nervous until I got used to it.

I'm currently working with an UI framework that is constantly accessing my objects. This is a problem cuz I get constant threading exceptions that are hard to fix.
Also error messages like: you can't access objects x because a different thread owns it, are not fun.
In the end you have to make sure again that some objects are only accessed from one thread.
Not really easier tbh.

The sound of your recordings has been distorted lately :/

Could you please check your recording levels?

Old Erlanger here. This is exactly why I use Erlang and Elixir.

Thank you for your really excellent explanation (and animated diagram) of ring buffers! This is a concept that was new to me. (Though I realize I'd seen it before in databases.) It's very well explained here, and knowing about it goes a long way to illuminating the magic behind Akka.

Given how lovely the much regretted Mr Armstrong seems in his talks, I really wish I'd encountered Erlang somewhere in my programming journey.

As it stands, I encountered Akka early on and got very excited about it for a while. But my primary interest was desktop client systems, and I could never figure out how to apply the actor model there. Screen painting, it seems, is usually a synchronous concern.

So how on earth could one integrate Akka and, say, JavaFx? Is such a thing even possible? Would the entire UI process have to live inside a single actor? Am I missing some very obvious point?

In the past, when I have asked the wise ones questions like this, I have been scolded and told to go back and study the Command Pattern in my GoF book. The actor model, they say, is no more complicated than that. (And perhaps they're right.)

But the practical explanation of how to achieve idempotence through ring buffers in this video is exactly the kind of design advice that I (and I suspect many other perplexed bit-stitchers) could use more of.

Synchronous - at the same time
Asynchronous - at different times
Concurrent - at the same time
Sequential - execute each instruction in a specified order

SEQ
SEL
ITER
ALT
PAR

have i got that right ?

Hello. Is it possible for you to record the audio in stereo

Well presented episode. I really felt your enthusiasm about this subject.

What is your opinion on actor model of reactive programming?