As software engineers, we can’t reinvent the wheel. Using external libraries is inescapable. In fact, not using them would be unprofessional. What team would develop a http service from scratch using “bare” Sockets, rather than using well tested, battle harden frameworks like Vert.x or Akka Http which were designed by experts?
Sadly, this does lead to us developers rarely having the need or opportunity to explore how things work under the hood. Many (most?) developers use libraries as black boxes, and spend their entire careers just wiring things together. That’s ok off course. At the same time, we can’t be a true master in software engineering without mastering the fundamentals as well. Not least because that knowledge gives incredible insights on how and why things are the way they are.
The issue is particularly relevant for concurrency. The hardest topic in software is also where the gap in knowledge is greatest.
On this site, I loathe libraries and frameworks. I have on goal: Explore how concurrency and IO actually work.
Important
Fundamentals are the key to mastery.
We are here to explore the building blocks of concurrency with you.
The diagram above shows what we want to explore. The key thing to note is that the fundamentals contain a relatively small amount of concepts. These change sparingly, if at all. If you invest time understanding them, 40 years from know they will likely still be relevant. Furthermore, they enable you to understand all the past, current, and future high level libraries. There are hundreds of these libraries. They change often. If is an uphill battle to re-learn them every time a new comes up.
Fundamentals
- Relatively few.
- Don’t change with time
- A few fundamentals enable you to understand all libraries
Fancy libraries
- They come and go with trends
- Will go out of date in a few years
- You have to re-learn when you change teams and jobs.
Fundamentals, fundamentals, fundamentals. Here, you are never going to read about the new shiny library or framework. We are not here to learn APIs that other people have designed. We want to explore the intricacies of low-level concurrency.