Casey also got less aggressive when talking about Stroupstrup lately, especially after his last talk at Better software conference, where he mentioned him multiple times with a lot more historical context.
This is good diagnosis of the problem. I found that often the right solution is to ditch the hierarchy and use flat structure. I wrote about this some time ago: https://yoyo-code.com/embrace-flatness/
That makes sense, because JWT is base64 encoded, and those base64 tokens are bigger and more expensive. JWT has 3 parts, so it's 3x more expensive, obviously.
As far as I understood it, it only talks about electricity, so that doesn't seem like a contradiction to me. I think some electrification of heating is expected in 2030, but not that much bigger than it is now.
If you don't need to switch versions at runtime (ABR), you don't even need to chunk it manully. Your server has to support range requests and then the browser does the reasonable thing automatically.
The simplest option is to use some basic object storage service and it'll usually work well out of the box (I use DO Spaces with built-in CDN, that's basically it).
Yea, honestly you probably just don't understand. FE frameworks solve a specific problem and they don't make sense unless you understand that problem. That TSoding video is a prime example of that - it chooses a trivial instance of that problem and then acts like the whole problem space is trivial.
To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, something like Solid makes a lot more sense.
It's much easier to appreciate that problem if you actually try to build complex interactive UI with vanilla JS (or something like jQuery). Once you have complex state dependency graph and DOM state to preserve between rerenders, it becomes pretty clear.
> Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.
Dangling state is useful for debugging when the test fails, you don't want to clean that up.
This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.
> It feels a little tricky to square these up sometimes.
In my experience, this heavily depends on the task, and there's a massive chasm between tasks where it's a good and bad fit. I can definitely imagine people working only on one side of this chasm and being perplexed by the other side.
> There must be a really good reason for this, such as Rust doesn’t interop well with C++
Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction.
This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it).
If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.