8 comments

[ 3.3 ms ] story [ 28.2 ms ] thread
A fantastic library. We switched Onyx Platform www.onyxplatform.org over to it from Netty, and it was a lot easier to write than the netty messaging layer that we had, which required a lot of tuning and thought to get right.

I learned a lot by reading the code, and it generally forces you to use good patterns that changed how I thought how to build a messaging layer.

The author Martin Thompson is one of those rare breed of developers who understands the sheer inner workings and the effects of his programs from the source to processor.

http://mechanical-sympathy.blogspot.com/

This breed so not exactly rare as it includes every system programmer at its bare minimum.
I'm sure this is a logical fallacy but if that were true, wouldn't the quality of software on consumer routers be much better?
I imagine a systems programmer would not consider user-facing applications as their program especially if they had no hand in writing these user-facing applications. In my imagination, a systems programmer abstracts out application programming and just blocks it out.

Personally, I think in abstractions as well. I don't spend a lot of time thinking about fetch, execute, decode, ... when I write my line of business applications. I probably should but as I pound out lines after lines of garbage, I could be a lot more conscientious but I tell myself my code runs on top of other people's code (and really I am not that great of a programmer anyway so I should focus on my part of the code rather than the platform which I can't change anyways).

https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/CompOrg/f...

written in Java? not effected by heap-growth and GC latency?
The driver does not allocate in the main message flow so GC does not factor in. Also the driver can run out of process and not be impacted by client processes.