olix0r

"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."

– Michael Crichton (1942-2008)

> 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.

Dan Price is a grifter who posts things like this in bad faith. Don’t engage.

Betteridge’s law applies https://en.m.wikipedia.org/wiki/Betteridge%27s_law_of_headli...

Ah hah! Indeed I’m most familiar with musl in a static linking context.

Thanks for the clarification

> Which feels safer to you?

“Feels” being the operative word… alpine is statically linking all of the same libraries, you’re just not able to see them via LDD.

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.

… in Poland.

> 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.

> To my knowledge Google and the other big tech companies aren't building application directly for offence/defence.

Actually there was a big uproar about exactly this several years ago https://www.theguardian.com/technology/2018/mar/07/google-ai...

That's Brian's point. rustls/webpki/ring do not have funding in line with project's 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].

[1] https://github.com/tower-rs/tower-grpc

[2] https://github.com/runconduit/conduit

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)!

If you think Conduit is bad, you should see the list of names we _didn't_ use! ;)

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.

Like Linkerd, Envoy is a proxy that can be used used to build a service mesh. Conduit is a service mesh that includes a proxy.

So, yes, Conduit uses something that competes with Envoy ;) But I would not say that Conduit and Envoy are equivalent things.

> Why not DNS round-robin?

Round-robin may be sufficient for your needs. However, the load balancing techniques that linkerd employs solved real production issues for us. These techniques allowed us to be paged less frequently for minor errors and we could more reliably make changes to the system without causing user-facing issues.

See https://blog.buoyant.io/2016/03/16/beyond-round-robin-load-b...

Yep! That is exactly what I meant by that ;)

linkerd is a router and not a "web server", so there may be features web-servery features that you still want from nginx that don't belong in linkerd. However, linkerd should be useful as an ingress server. To this end, we've just recently added support for the kubernetes Ingress API, which is available in 1.0-RC1.

That's basically right. linkerd is a proxy that deals with a bunch of operational things like service discovery, metrics/observability, tracing, load balancing, etc. It's a proxy so that you can deploy one solution across all languages/frameworks without having to modify your code to deal with these things.

Luckily GRPC can downgrade to HTTP/1.1, so if you want some of linkerd's features it isn't a total non-starter; but this is obviously less-than-desirable. We're working with the finagle team to complete finagle's netty4 integration, which will enable us to transparently introduce netty's http/2 codec into linkerd. This is a high-priority feature.