From Sequential Bottlenecks to Reactive Solutions: A Programming Journey
Imagine you're building an application that needs to perform three independent calculations: adding two numbers, squaring a value, and summing an array. Your first instinct is to write straightforward sequential code:
par Mansour Ayouni · dans le dépôt depuis le 2025-08-08 · essai de paradigme · domaine Concurrence et distribution
Cet article est écrit en anglais, comme la bibliothèque.
The Problem Every Programmer Faces
add(5, 3) # Wait for addition square(7) # Wait for squaring sum(1:100) # Wait for summation
illustration
This works, but creates a fundamental bottleneck: each function blocks the next, even though they're completely independent. Your program wastes time waiting when it could be working.
The Reactive Insight
What if instead of waiting for results, you could say: "Here's the work to do, and here's what to do when it's finished"? This is the core insight of reactive programming—transforming blocking operations into non-blocking ones through callbacks.
Building the Solution in Softanza
Let's solve this step by step, transforming our blocking problem into a reactive solution:
# Step 1: Initialize the reactive system
oRs = new stzReactive()
oRs {
Init() # Connect to libuv event loop
# Step 2: Define our functions (same logic, no changes needed)
f1 = func x, y { return x + y }
f2 = func x { return x * x }
f3 = func arr {
sum = 0
for i = 1 to len(arr) sum += arr[i] next
return sum
}
# Step 3: Transform functions into reactive versions
Rf1 = MakeReactive(f1)
Rf2 = MakeReactive(f2)
Rf3 = MakeReactive(f3)
# Step 4: Queue all work with success handlers
Rf1.CallAsync(
[5, 3], # Parameters
func result { ? "Addition result: " + result }, # What to do when done
func error { ? "Addition error: " + error } # What to do if it fails
)
Rf2.CallAsync(
[7],
func result { ? "Square result: " + result },
func error { ? "Square error: " + error }
)
Rf3.CallAsync(
[1:100],
func result { ? "Sum result: " + result },
func error { ? "Sum error: " + error }
)
# Step 5: Execute everything in parallel
Start()
}
# Output (in any order):
# Addition result: 8
# Square result: 49
# Sum result: 5050
# Executed in 0.01 second(s)illustration
What Just Happened?
The Transformation Process
- System Setup:
stzReactive()provides the infrastructure for non-blocking operations - Function Wrapping:
MakeReactive()doesn't change your logic—it adds async capabilities - Callback Pattern: Instead of
result = function(params), you usefunction.CallAsync(params, successHandler, errorHandler) - Parallel Execution:
Start()processes all queued operations simultaneously
The Execution Flow
Traditional: f1 → wait → f2 → wait → f3 → wait Reactive: f1, f2, f3 → all execute together → handlers called as they finish
Behind the scenes, libuv's thread pool picks up your functions and runs them in parallel. As each completes, its result queues back to the main thread where your success handler executes.
The Paradigm Shift
You've moved from imperative waiting ("do this, then this, then this") to declarative handling ("when this is done, do that"). Your program never blocks—it describes what should happen and lets the reactive system coordinate the execution.
Key Benefits Realized
- Concurrency: All three operations run simultaneously
- Responsiveness: Main program never freezes waiting
- Scalability: Adding more operations doesn't slow down completion
- Error Isolation: Each operation has its own error handling
The same logical operations that took sequential time now complete in roughly the time of the slowest individual operation—a dramatic efficiency gain through the power of reactive programming.
Citer
Mansour Ayouni. « From Sequential Bottlenecks to Reactive Solutions: A Programming Journey ». Softanza narrations, 2025. https://mayouni.github.io/stzsite/fr/narrations/stzreactive-from-sequential-bottlenecks-to-reactive-solutions.html
Non exécuté : son code ne se charge pas tel qu'il est écrit. L'article est publié tel qu'il est écrit ; ses blocs sont des illustrations. Le code des articles est du code Haro. Là où un article a été écrit avant que la langue prenne son nom actuel, le nom a été changé et rien d'autre. Genre, domaine et série lus dans le nom du fichier, année tirée du premier commit : dérivés, jusqu'à ce que l'article porte son propre en-tête. Le fichier sur GitHub(s'ouvre dans un nouvel onglet)

