"Briefly stated, the Gell-Mann Amnesia effect is as follows. You open the newspaper to an article on some subject you know well. In Murray's case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward—reversing cause and effect. I call these the "wet streets cause rain" stories. Paper's full of them.
"In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know."
> Just as dashmap is a replacement for std::sync::RwLock<HashMap>, whirlwind aims to be a replacement for tokio::sync::RwLock<HashMap>.
I'm curious about the practical benefits of handling a HashMap with an async interface. My long-standing understanding is that `tokio::sync::RwLock<HashMap>` is only useful when you'd want to hold the lock guard across another `await` operation; but when the lock guard is not held across an await, it is always preferable to use the synchronous version.
This would lead me to assume that same applies for dashmap--it should be sufficient for async use cases and doesn't need an async API unless we expect to be blocked, but the benchmarks indicate that whirlwind outperforms dashmap in various situations. Do you have a sense of where this blocking occurs in dashmap?
While I think civo are doing some pretty novel things to allow kubernetes to run cheaply for small clusters, it’s a mistake to take a vendor’s “report” at face value. It’s a press release.
No person should need an engineering manager, but nearly every single team deserves one.
It's not difficult to be productive as an individual; but teams are much more complex and require constant tweaking. The highest performing teams are continually improving. A good Engineering Managers puts the systems and processes in place that make the team stronger over time.
But if you're not going to get excited about making your team as awesome as possible, then maybe management is just effectively being an agent of HR. Sounds miserable.
> While the EPA reports the cattle industry in the United States accounts for 2.4% of total greenhouse gas emissions, some consumers are convinced that beef production is a major cause of climate change.
This seems to imply that cutting 2.4% of total greenhouse emissions wouldn’t have an impact on climate change. Motivated reasoning.
That's Brian's point. rustls/webpki/ring do not have funding in line with projects like Go's crypto or BoringSSL:
> ... ARM, Amazon Web Services, Google, and Microsoft [...] should support the Rust community by letting their experts help the Rust community create FIPS-validated cryptography libraries written entirely in safe Rust that expose safe and idiomatic Rust APIs.
Rust's large corporate sponsors need to step up to make these crates more broadly suitable for production.
Linkerd's sidecar proxy (https://github.com/linkerd/linkerd2-proxy) is implemented in Rust. It implements transparent mTLS, HTTP load balancing, telemetry, etc. Rust gives us safety and security with a minimal resource footprint.
Dan Duchamp's CS 521 TCP/IP Networking -- he had us implement low-level protocols like DNS and TCP/IP from scratch, in C. Brutal, but exceptionally rewarding.
jschauma's been doing this for a while: I took this course about 15 years ago! It was one of the two most challenging, rewarding courses in my undergrad degree. I still apply things I learned from it daily.
Highly, highly recommended if you want to work in SRE or system-focused programming.
I've written a few production-facing applications with Tokio; and I think the author exactly identifies the stumbling blocks I hit while learning the landscape.
My takeaway from working with Tokio is that it's a fairly low-level abstraction and doesn't do much to address the challenges of building networked _applications_. And this is OK.
We'll need higher-level layers that use Tokio, however, to address more specific use cases. I'll point to the nascent tower-grpc[1] library as something in this direction. I hope to see more things like this fall out of our work on Conduit[2].
The first release doesn't include Ingress support. This is something we plan on folding into our Routing API in an upcoming release. If you have opinions on how you'd like to see Ingress implemented, now is a great time to share your thoughts (in a GitHub issue, is probably best)!
Conduit will probably have quite a bit of feature-overlap with Istio, especially, as it matures.
However, I think you'll find that the projects will be quite different in the way that they prioritize features and operate.
Our goals for Conduit are to provide a minimal, production-ready, commercially-supportable service mesh in the near-term. Time will tell how each projects goals and constraints lead to different user experiences.
"In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know."
– Michael Crichton (1942-2008)