haimez

Generating code at runtime is often an anti-goal because you can’t easily introspect it. “Build-time” generation gives you that, but print often choose to go further and check the generated code to source control to be able to see the change history.

Are we the baddies?

Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).

Delete API calls are free, listing the objects in a bucket to know what to delete is not.

Let’s be a little charitable here- having and raising children has been a much, much more dangerous proposition health wise even at your parents generation to say nothing of your grandparents generation.

10x reduction in latency, higher storage costs with lower access costs (SSD instead of spinning disks). So high I/O, small files situations (with no need for cross AZ access) are where the benefits can be found.

Or like SSD’s vs spinning disks…

Counterfeiting parts, including passing even a small part off as an original OEM one, absolutely enters into it

Yikes. I did have to go down a little rabbit hole to understand the semantics of that builtin (I don’t normally write C if that wasn’t immediately obvious from the question) but that seems like a really questionable interpretation of “this should never happen”. I would expect the equivalent of a fault being triggered and termination of the program, but I guess this is what the legacy of intentionally obtuse undefined behavior handling in compilers gets you.

> This seems like a bad idea, because the whole point of an assert is that something shouldn't happen, but might due to a (future?) bug.

And so it’s a bad idea because…?

The whole idea is to notice a bug before it ships. Asserts are usually enabled in test and debug builds. So having an assert hit the “unreachable” path should be a good way to notice “hey, you’ve achieved the unexpected” in a bad way. You’re going to need to clarify in more detail why you think that’s a bad thing. I’m guessing because you would prefer this to be a real runtime check in non debug builds?

…or the nature of the question and corpus?

LLM’s are spitting out responses based on their inputs. It is (or was) shockingly effective, but there is no generalized math processing going on. That’s not what LLM’s are, that’s not how they work.