1. The tariffs are too broad, they don't target a single or a few industries.

2. Trump has gone back and forth many times on them, using them as negotiating leverage, not as long term incentives.

3. They are on very shaky legal grounds and will likely end up getting reversed by either the Supreme Court or the next president.

If you want to use tariffs to encourage on-shoring you make them targeted and pass them with bipartisan support through congress. Companies need stability and long term guarantees for the kind of capital expenditure that is needed. Even better if you use a mix of carrot and stick, rather than all stick

Tbf this applies to Rust too. If the author writes

   fn foo(bar: Box)

Had they written

   fn foo(bar: impl BarTrait)

EDIT: I suppose what I'm saying is that "The paid products Adam mentions are the pre-made components and templates, right? It seems like the bigger issue isn't reduced traffic but just that AI largely eliminates the need for such thing." is wrong. My hunch is that AI has the appearance of eliminating the need for such things.

I've always understood the billion dollar mistake to be more about #2 and language like Java in particular. Agree about default values being bad, it's one of my primary reservations with Go.

To me this is the crux of the problem with null. It's not that null itself is a problem, it's that nothing communicates when it can be expected. This leads to to anti-patterns like null-checking every single pointer dereference. What's need is a way to signal when and when not `null` is valid under your domain model. This is precisely what stuff like `Option` does. Without a signal like this, programming feels like a minefield, where every dereference is liable to blow up, personally I'm done with that kind of programming.

The latter part of the post about individual-element vs grouped-element mindset is interesting, but I'm not sure it refutes the need for null or reasoning about it.

EDIT: It's also worth noting that Rust can still zero initialise entire structs despite element-wise initialisation when the valid bit pattern for the struct is 0.

The problems with AI aren't technical they are political and economical. This topic is discussed in Max Tegmark's "Life 3.0", in which he theorises about various outcomes if we do invent AGI. He describes one possibility where we move to a post-scarcity society and people spends their days doing art and whatever else they fancy. Another option looks more like the world described in Elysium. I suspect the latter prediction feels more likely to most people.

Still, I use LLM assisted coding fairly frequently, but this is a nagging feeling I have.

See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

The neat thing about ICE is that you get automatic fallbacks and best path selection. So best case IPv6 UDP, worst case TCP/TLS

One of the nice things about HTTP3 and QUIC will be that UDP port 443 will be more likely to be open in the future.

Rust being memory safe is a way in which it helps the programmer check themselves. Absolute statements like "removes a whole class of error" are dangerous, there are always caveats. Rust seems to be doing a heck of a good job at this particular task, even if it sometimes falls short.

> Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.

The kernel has been under the development for north of 30 years at this point. These ways to improve safety in C don't seem to be materialising.

Unsafe is the one escape hatch where Rust is more like C, but pragmatically it's an important escape hatch.