Set up your team for success. This FREE GUIDE is a great resource for team leads or business leaders managing technical teams and are looking for advice from me in a convenient, short-form handbook. Available to download NOW ➡ www.subscribepage.com/organise-teams-guide
So at work, before I was involved in the project, a team decided they would use SignalR and Service Bus as a async mechanism to do simple CRUD operations between the UI and the back end services. This was designed, they claim, to provide async functionality. Under stress testing it failed miserably and the implementation forced a synchronous wait anyway via the means of waiting for a SignalR hub response before sending the resoponse back to the UI. It was in my opinion nonsense, as it negated many of the benefits of asynchronous systems and also overkill for the situation. The intent was scalability. But to be honest, it was a symptom of pre-optimisation and YAGNI when a simple synchronous REST API would have worked and scaled just as well, especially if it was containerised. Async is an attractive proposition, but so many misunderstand it and come up with crazy implementations. When starting simple, it can be easier to spot where issues lie and where a different approach is required. Thanks for the video. It was interesting.
🤣 I've been doing async programming since I started working over 20 years ago. It takes learning and practice. What many people don't know or do is non-blocking event handler.
I thought event driven architecture could only be applied for server to server communication, I didn't realise that ui to server could be event driven sounds weird really, because in a usual human computer interface, we make our user wait for the response and give confirmation after the action is resolved
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.
Anyone working in the telecommunication domain is likely aware of the concept via the Erlang/OTP platform, based on the actor model. Same concept Dave describes: message-oriented communication between single-threaded actors. Great for high concurrent, high contention scenarios.
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
Do you think async will be useless now that we have project Loom in JVM? We will be able to have the cake and eat it too. Creating multithreaded applications in a imperative style, that is easy to debug and think and also the async qualitities that make it mandatory for current systems. Async for me is just a way we figure out how to solve a hard problem of platform threads. But if this is not a problem anymore, there is no point in making your code harder to reason about and to debug. There is also this awesome article explaining why Go programmers don't have to use this shit trick (async code) to workaround platform threads being heavy weight called "What color is your function". I can't post the like here because UA-cam will delete my comment.
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
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.
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?
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.
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.
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).
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.
You can always design it a different way, and if you use async the vast majority of the time, all the time when the system is actually working, the user will get a faster response.
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.
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!
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?
I think it is yet another attempt at trying to hide the reality that the comms is async, and as usual when we try to do that, it starts to leak problems. If I make an async call that looks sync, because it is handled as an "await" callback, I have hidden the failure case. What happens if I never get a response or if the response is delayed? If I write the simple async case, it seems more obvious now to think about the problem. I send an "OrderItem" message, and I am done. So now I have some things, who's state I am, presumably tracking, I have an item that has been "Ordered", but not yet dispatched. In normal circumstances I have another message "ItemDispatched" and when I receive that message, I move my "Item" from being "Ordered" to being "Dispatched". This seems pretty natural to me, but what if I don't receive a reply in a sensible amount of time? If I did all this with async-await I almost certainly won't think of that case, but if I did the equally simple coding that I described, I might, and even if I only thought of it later, what to do is pretty obvious, look at all the "Ordered Items" and any that was ordered more that a day, an hour, or a week ago, I decided what to do - connect the customer and appologise, try and find an alternative source for the item and so on. My point is that this extra stuff seems simpler, and less technical, because it is. Because we are not trying to hide this async series of events as a sync call, the realities of the situation seem clearer and easier to spot to me.
@@ContinuousDelivery Mechanically, async-await is absolutely the same thing as continuations on Promises/Futures/Monos or whatever your API calls them. Error handling callbacks become try-catch blocks, that's about it. The only real difference is the shape of the code, if you will. So if I understand you correctly, your criticism should apply to the Promise / Continuation style of asynchronous programming as well?
@@cod3r1337 I agree. It seems much more intuitive to me to have an await call with a try-catch block for any needed error handling / timeouts. It places the "What do we do about it" stuff in direct proximity to the call that was made. And there is no thread-locking, other operations can continue un-impeded. With the traditional async approach I have to create call backs, and then remember to write additional code elsewhere to track the calls and then even more code to check to see if the call back never arrived.
Yes, comms is comms, HW or SW or even people, it doesn't really change the fundamentals. Async is closer to reality than sync, and so the abstractions around it leak less severely.
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.
Yes, that is certainly how we built the LMAX system. Implemented infrastructure to hide nearly all of the accidental complexity, and it was the async model, and the lossless transmission of data, through async events, that allowed for this. It was the nicest complex system to work on that I have seen so far.
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 ...
sequentially making asynchronous calls, could still have the advantage being able to do other things while waiting. but i recognize not being able to take full advantage of asynchronous calls, because of design decision out of my control
why has no one invented a language that looks normal but does everything asynchronously? it should be possible to transform "next line of code" into a callback parameter. the problem here isn't that my code is "syncronously written" but that it is executed that way. why doesn't the OS/JVM/whatever say that "int x = calculate()" does NOT block? the semaphore could be hidden, automatic
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.
I don't know what you're using but generally the answer is to marshall back to the UI thread at the point where you need to interact with the UI. Use the UI thread to read anything you need from the UI, use another thread to do work, and then use the UI thread again to write back to the UI for display. This might sound a bit complicated but UI frameworks tend to make it pretty simple, and it tends to be mostly hidden from you.
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.
For the reasons explained in the video, this is not about the transport, it is about how the apps interact with it, do they care about the failure cases or not. It you attempt to hide the async nature of the comms, the abstraction leaks in all these complex failure scenarios.
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).
Are there any real-world examples of this concurrency style? Because it's hard to imagine. The closest thing to that in my mind are Go goroutines, which Java now kind of tries to emulate with Project Loom. But even this style requires at least *some* explicit concurrency.
@@cod3r1337 Here are some: 1. Java parallel streams. There's nothing in a code about dealing with threads, gathering thread results and synchronization. Just the word "parallel". 2. Data processing of sharded relational data, e.g. Citus. The code is just plain old SQL. But it starts multiple simultaneous processes that work with data on multiple cluster nodes. 3. Similar example - map/reduce Hadoop data processing. 4. Apache Nifi - a dataflow parallelism model with a simple visual programming language.
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.
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 ?
Synchronous - one thing at a time, in a specific order, and nothing in between. Asynchronous - allowing other things to happen while waiting, and possibly, getting results in the different order, than requested. Concurrent and Sequential, I would agree, there are nuances (like concurrent is not necessarily parallel, and sequential might not refer to execution, but gathering results), but generally you've got those right.
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?
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.
Exactly! I'm not aware of any commercial general purpose operating system that is not concurrent at its core. Async programming languages take advantage of some sort of a concurrent engine under the hood to create an illusion of asynchronous execution. Async programming model is a very useful paradigm but, for the love of all that is holy, it is not the only useful model that exists.
I mean, electrical engineering and software engineering are completely different because one of them is physical and the other is digital and thus more malleable, so I don't understand why you're trying to conflate the two with each other...
@@thatoneuser8600 I have a degree in Electronics Engineering - so I guess it would be a hybrid of the two. I would say there are a lot more parallels then differences. You can flowchart out an electrical system very much like you can a software application.
@@thatoneuser8600 For one thing, his point doesn't depend on _any_ similarity in detail between different kinds of engineering; he could have made exactly the same point if he'd instead studied history: when you major in history at any respectable institution, there's no single course or self-contained text titled "History." More importantly, the idea that a difference between two things renders them "completely different" is ridiculous. That kind of "thinking" takes me back to somewhere around the 3rd grade, when we had no developed notion of what comparison even meant. Analogy and comparison as concepts that leverage discourse and insight are well on their way to extinction... just another part of The Great Dumbing Down. SAD!
@@lucasgroves137 There's more differences than similarities that I didn't mention. Comparisons will NEVER be perfect, or at least hardly EVER, because of the fact that you are using two different things to compare that aren't the same. If a comparison was perfect, then it wouldn't be a comparison because you would just be comparing the same two things with each other for seemingly no reason. That's why using an analogy as a crux for your argument will never work; the opponent will use the differences in comparison against you to show you why your argument doesn't make sense, as using only a comparison to make your point often has too many holes that don't make sense. If getting rid of "The Great Dumbing Down" involves getting rid of nuanced takes that account for the differences in comparisons, then that is literally a dumbing down in of itself, and you should be ashamed for even suggesting such a backwards line of thinking.
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.
CPUs *do* queue data. Modern intel processors coordinate their work via something called a QPI bus en.wikipedia.org/wiki/Intel_QuickPath_Interconnect. That assumes that the async model *is* more complex, but it is not obvious that it is. Erlang is based on this concept, and while it is not thought of as a beginners language, I think it would be an interesting experiment to try teaching someone programming from scratch with Erlang or more likely Elixir, which is based on the same ideas.
Set up your team for success. This FREE GUIDE is a great resource for team leads or business leaders managing technical teams and are looking for advice from me in a convenient, short-form handbook. Available to download NOW ➡ www.subscribepage.com/organise-teams-guide
So at work, before I was involved in the project, a team decided they would use SignalR and Service Bus as a async mechanism to do simple CRUD operations between the UI and the back end services. This was designed, they claim, to provide async functionality. Under stress testing it failed miserably and the implementation forced a synchronous wait anyway via the means of waiting for a SignalR hub response before sending the resoponse back to the UI. It was in my opinion nonsense, as it negated many of the benefits of asynchronous systems and also overkill for the situation. The intent was scalability. But to be honest, it was a symptom of pre-optimisation and YAGNI when a simple synchronous REST API would have worked and scaled just as well, especially if it was containerised. Async is an attractive proposition, but so many misunderstand it and come up with crazy implementations. When starting simple, it can be easier to spot where issues lie and where a different approach is required. Thanks for the video. It was interesting.
🤣 I've been doing async programming since I started working over 20 years ago. It takes learning and practice. What many people don't know or do is non-blocking event handler.
I thought event driven architecture could only be applied for server to server communication, I didn't realise that ui to server could be event driven
sounds weird really, because in a usual human computer interface, we make our user wait for the response and give confirmation after the action is resolved
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.
Anyone working in the telecommunication domain is likely aware of the concept via the Erlang/OTP platform, based on the actor model. Same concept Dave describes: message-oriented communication between single-threaded actors.
Great for high concurrent, high contention scenarios.
Well presented episode. I really felt your enthusiasm about this subject.
This is the best explanation of asynchronous programming ever ❤🎉
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
Thanks for pointing this out, i was quite confused by the video but there are some great points in it!
Do you think async will be useless now that we have project Loom in JVM? We will be able to have the cake and eat it too. Creating multithreaded applications in a imperative style, that is easy to debug and think and also the async qualitities that make it mandatory for current systems.
Async for me is just a way we figure out how to solve a hard problem of platform threads. But if this is not a problem anymore, there is no point in making your code harder to reason about and to debug.
There is also this awesome article explaining why Go programmers don't have to use this shit trick (async code) to workaround platform threads being heavy weight called "What color is your function". I can't post the like here because UA-cam will delete my comment.
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
Yes! Been waitin' for this topic.
Another awsome t-shirt! 😃
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.
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?
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.
Platforms such as Erlang, Akka, VLINGO Xoom are exploiting the advantages of this model.
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.
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).
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.
You can always design it a different way, and if you use async the vast majority of the time, all the time when the system is actually working, the user will get a faster response.
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.
I love this philosophy-of-technology channel! I learned a lot from your videos!
The sound of your recordings has been distorted lately :/
Could you please check your recording levels?
What is your opinion on actor model of reactive programming?
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!
Reactive systems: ua-cam.com/video/r1qcVMkYrgE/v-deo.html
Actor based systems: ua-cam.com/video/-IZlOPciSl0/v-deo.html
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?
I think it is yet another attempt at trying to hide the reality that the comms is async, and as usual when we try to do that, it starts to leak problems. If I make an async call that looks sync, because it is handled as an "await" callback, I have hidden the failure case. What happens if I never get a response or if the response is delayed?
If I write the simple async case, it seems more obvious now to think about the problem. I send an "OrderItem" message, and I am done. So now I have some things, who's state I am, presumably tracking, I have an item that has been "Ordered", but not yet dispatched. In normal circumstances I have another message "ItemDispatched" and when I receive that message, I move my "Item" from being "Ordered" to being "Dispatched". This seems pretty natural to me, but what if I don't receive a reply in a sensible amount of time? If I did all this with async-await I almost certainly won't think of that case, but if I did the equally simple coding that I described, I might, and even if I only thought of it later, what to do is pretty obvious, look at all the "Ordered Items" and any that was ordered more that a day, an hour, or a week ago, I decided what to do - connect the customer and appologise, try and find an alternative source for the item and so on.
My point is that this extra stuff seems simpler, and less technical, because it is. Because we are not trying to hide this async series of events as a sync call, the realities of the situation seem clearer and easier to spot to me.
@@ContinuousDelivery Mechanically, async-await is absolutely the same thing as continuations on Promises/Futures/Monos or whatever your API calls them. Error handling callbacks become try-catch blocks, that's about it. The only real difference is the shape of the code, if you will. So if I understand you correctly, your criticism should apply to the Promise / Continuation style of asynchronous programming as well?
@@cod3r1337 I agree. It seems much more intuitive to me to have an await call with a try-catch block for any needed error handling / timeouts. It places the "What do we do about it" stuff in direct proximity to the call that was made. And there is no thread-locking, other operations can continue un-impeded. With the traditional async approach I have to create call backs, and then remember to write additional code elsewhere to track the calls and then even more code to check to see if the call back never arrived.
@@ContinuousDelivery Now I am curious about what you think about stream/CSP like concurrency like with Go's channels or Kafkas streams
This sounds like the asynchronous communications in hardware I learned in the 80's.
Yes, comms is comms, HW or SW or even people, it doesn't really change the fundamentals. Async is closer to reality than sync, and so the abstractions around it leak less severely.
Love the Erlang comment Dave made me chuckle 😀 Of course, one could always take the gateway drug that is Akka hahahah 😀
That was extremely informative, fantastic stuff
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.
You make great content, once everyone finds your way of presenting you will grow so unbelievably fast 🎉🎉
Thank you for your support!
Old Erlanger here. This is exactly why I use Erlang and Elixir.
I kept thinking of Hexagonal Architecture and Event Sourcing while watching this video.
Yes, that is certainly how we built the LMAX system. Implemented infrastructure to hide nearly all of the accidental complexity, and it was the async model, and the lossless transmission of data, through async events, that allowed for this. It was the nicest complex system to work on that I have seen so far.
The answer is project Loom.
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 ...
sequentially making asynchronous calls, could still have the advantage being able to do other things while waiting. but i recognize not being able to take full advantage of asynchronous calls, because of design decision out of my control
Erlang, Elixir & Pony for the win
ua-cam.com/video/bo5WL5IQAd0/v-deo.html
why has no one invented a language that looks normal but does everything asynchronously? it should be possible to transform "next line of code" into a callback parameter. the problem here isn't that my code is "syncronously written" but that it is executed that way. why doesn't the OS/JVM/whatever say that
"int x = calculate()" does NOT block? the semaphore could be hidden, automatic
The implementation of Python's PEP 492 did that.
Isn't that simply javascript?
Isn't that language Elixir?
async/await syntax is just that. Introduced first to C#, now available to most modern, popular languages.
Kotlin's coroutines are similar to what you describe.
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.
You can try out semaphores and/or monitors , search for it’s implementation in your framework and good luck 🍀
Sounds weird. Which UI framework is that? Every UI framework I've ever seen, and I've seen a few in nearly 20 years, is single threaded.
I don't know what you're using but generally the answer is to marshall back to the UI thread at the point where you need to interact with the UI.
Use the UI thread to read anything you need from the UI, use another thread to do work, and then use the UI thread again to write back to the UI for display.
This might sound a bit complicated but UI frameworks tend to make it pretty simple, and it tends to be mostly hidden from you.
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.
For the reasons explained in the video, this is not about the transport, it is about how the apps interact with it, do they care about the failure cases or not. It you attempt to hide the async nature of the comms, the abstraction leaks in all these complex failure scenarios.
Hello. Is it possible for you to record the audio in stereo
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).
Are there any real-world examples of this concurrency style? Because it's hard to imagine. The closest thing to that in my mind are Go goroutines, which Java now kind of tries to emulate with Project Loom. But even this style requires at least *some* explicit concurrency.
@@cod3r1337 Here are some:
1. Java parallel streams. There's nothing in a code about dealing with threads, gathering thread results and synchronization. Just the word "parallel".
2. Data processing of sharded relational data, e.g. Citus. The code is just plain old SQL. But it starts multiple simultaneous processes that work with data on multiple cluster nodes.
3. Similar example - map/reduce Hadoop data processing.
4. Apache Nifi - a dataflow parallelism model with a simple visual programming language.
About async await, I do use it
But in my defense, I am very ashamed of it every time
🤣🤣👍
Damn that shirt is awesome!
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.
How do you make the background animations of your videos? They are well made. Are they made by an animator person?
We have an editor who does most of the animations, and I do the more technical ones, so quite a lot of those in this episode.
Love that shirt!
So you're saying I should use Node.js?
Actors! Actors! more Actors!
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 ?
Synchronous - one thing at a time, in a specific order, and nothing in between.
Asynchronous - allowing other things to happen while waiting, and possibly, getting results in the different order, than requested.
Concurrent and Sequential, I would agree, there are nuances (like concurrent is not necessarily parallel, and sequential might not refer to execution, but gathering results), but generally you've got those right.
¡Gracias!
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?
Thank you sir!
Asynchronous made me nervous until I got used to it.
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.
Exactly! I'm not aware of any commercial general purpose operating system that is not concurrent at its core. Async programming languages take advantage of some sort of a concurrent engine under the hood to create an illusion of asynchronous execution. Async programming model is a very useful paradigm but, for the love of all that is holy, it is not the only useful model that exists.
I mean, electrical engineering and software engineering are completely different because one of them is physical and the other is digital and thus more malleable, so I don't understand why you're trying to conflate the two with each other...
@@thatoneuser8600 I have a degree in Electronics Engineering - so I guess it would be a hybrid of the two. I would say there are a lot more parallels then differences. You can flowchart out an electrical system very much like you can a software application.
@@thatoneuser8600 For one thing, his point doesn't depend on _any_ similarity in detail between different kinds of engineering; he could have made exactly the same point if he'd instead studied history: when you major in history at any respectable institution, there's no single course or self-contained text titled "History." More importantly, the idea that a difference between two things renders them "completely different" is ridiculous. That kind of "thinking" takes me back to somewhere around the 3rd grade, when we had no developed notion of what comparison even meant. Analogy and comparison as concepts that leverage discourse and insight are well on their way to extinction... just another part of The Great Dumbing Down. SAD!
@@lucasgroves137 There's more differences than similarities that I didn't mention. Comparisons will NEVER be perfect, or at least hardly EVER, because of the fact that you are using two different things to compare that aren't the same. If a comparison was perfect, then it wouldn't be a comparison because you would just be comparing the same two things with each other for seemingly no reason.
That's why using an analogy as a crux for your argument will never work; the opponent will use the differences in comparison against you to show you why your argument doesn't make sense, as using only a comparison to make your point often has too many holes that don't make sense. If getting rid of "The Great Dumbing Down" involves getting rid of nuanced takes that account for the differences in comparisons, then that is literally a dumbing down in of itself, and you should be ashamed for even suggesting such a backwards line of thinking.
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.
CPUs *do* queue data. Modern intel processors coordinate their work via something called a QPI bus en.wikipedia.org/wiki/Intel_QuickPath_Interconnect.
That assumes that the async model *is* more complex, but it is not obvious that it is. Erlang is based on this concept, and while it is not thought of as a beginners language, I think it would be an interesting experiment to try teaching someone programming from scratch with Erlang or more likely Elixir, which is based on the same ideas.
imo, async is much better as long as you are able to model it all easily with callbacks, forks and merge points. if you can't, better use sync code
STOP WRITING LONDON STYLE UNIT TESTS because they are terrible for projects!
That's circular reasoning.
@@thatoneuser8600 I am trying to save Europe from London style unit test. We are losing billions because of bad tests.
What are London style unit tests? I understood the london testing approach to be 'outside - in', starting with the requirements and uats.
I thought I'd mention that I did a video on this 😉 ua-cam.com/video/_S5iUf0ANyQ/v-deo.html
@@PavelHenkin London style unit tests are actually class tests. Every call outside the class under tests is mocked.