Skip to main content

 

Your systems architect will thank you
 
@silverwizard Nothing wrong with abstractions, but sure, knowing what they abstract certainly helps.

You don't replace Vert.x with just thread pools. It's a JS-like async model, for good and for bad, with explicit parallelism ("verticles"). The selling points of Vert.x are its support for several languages, that it does JS-like async, and its component model.

Its drawback is that it's weird and nobody uses it, not that futures model operations in other threads. It came out of a specific historical context when everybody seemed to be going to node.

I'm still curious to try it some day, just for fun.

But saying that Vert.x wouldn't exist if people knew threads is like saying actors or CSP or FBP wouldn't exist if people just knew about threads and functions and shared memory. We can disagree on what models and abstractions are suitable when, but generally they exist because they solved or aimed to solve someone's problem.
This entry was edited (1 year ago)
 
actors or CSP or FBP wouldn't*
 
in my experience, people don't pay attention to their kernel though. Nor their hardware. Abstraction is only fine if you know what you're abstracting. You can't become an expert without learning WHY things happen.

Kicking off threads without knowing how to bind threads is a problem, and architecture should be about learning the system and using it for what it's good at.