zenbowman

"Preserving privacy and anonymity online" is not an inherent good. It depends on how it is being used and what the consequences on society are.

Thus far, privacy and anonymity have been used to get children addicted to garbage, distribute CSAM, create elaborate schemes of financial fraud (cryptocurrency), and develop drug distribution networks.

It's completely reasonable to limit privacy in order to combat these social evils.

Exactly right. Also, better to be overly restrictive here given the well documented harms of social media on young minds. If the law stipulates that you must be 15 to obtain social media access, and most people don't get their IDs until 18, then most people will stay off social media for another three years: no big deal.

100% correct. At this point the harms to children from social media use are very well documented.

Like everything else in society, there are tradeoffs here, I'm much more concerned with the damage done to children's developing brains than I am to violations of data privacy, so I'm okay with age verification, however draconian it may be.

100%. I do this all the time, this will be very useful internally.

This was the norm about a decade ago. When I was at Hulu, we built our own analytics platform on top of Hadoop, we almost certainly wouldn't have done that today with the amount of off-the-shelf stuff available.

Even things like protobuf or Avro weren't as broadly adopted (>80%) at the time, many many companies at the time persisted stuff using JSON or other text formats (which in retrospect was very dumb, but it was very normal for a while).

Beyond that, someone as emotionally brittle and allergic to criticism as he is will inevitably create a yes-men culture, which will destroy engineering discipline & lead to declining quality. No way around it.

The one thing you absolutely need to preserve engineering quality is the ability to take criticism.

I would argue that it made sense for performance-sensitive code until the maturation of Rust, so it made sense even in 2015. But not today.

I understand wanting to defend your baby, and I think C++ was VASTLY better than most other languages for performance sensitive code until maybe 5 years ago - but the combination of memory safety and thread safety that Rust offers means that there are very few situations where C++ is the appropriate choice for a new project now.

I have written professionally in C++ for 20 years now, and I would pick Rust for a _new_ project/fresh codebase in a heartbeat. tokio alone is so vastly superior to anything you can do in async C++ that it makes zero sense to select C++ for a _new_ project (obviously if you have an existing codebase the price of interop may not be worth it).

Bjarne is being deliberately obtuse here.

This is a great writeup, I work on batch/streaming stuff at Google and I'm very excited by some of the stuff I see in the Rust ecosystem, Arroyo included.

I wouldn't say "infinite", its still susceptible to read hotspotting; and while fine-grained locking enables generally higher write throughputs, you can still get in a situation where interconnected updates end up being pretty slow.

That said, its way better than anything else I've used in my career.

Exactly. I used Unity starting from almost the first release, and attended Unite in 2007.

Unity was seen as a hobby engine then, we used it for the web, but for desktop used Unreal. Godot today is way ahead of where Unity was in 2007ish.

Same. Slowing down traffic is an inherent good, whether or not you have any intention of crossing.

> Because I tend to write all my code such that a complete stranger should be able to drop in and understand it

This isn't an achievable goal for most complex systems. Even very well written and documented code bases (for e.g. tcmalloc, bigtable) require a good deal of background reading to develop a baseline understanding of what is going on.

Things like large functions or code duplication are not necessarily bad in the first place. A far bigger problem that I encounter regularly is the invention of extreme layers of abstraction to avoid a small amount of copy-pasting + edit in the name of DRY.

But an even bigger problem is lack of understanding of the problem domain and a lack of documentation on how you plan to fix the problem.