saynsedit

It's not obvious what he was talking about. In context he was responding to this comment:

"While I know that C compilers are really conservative about this, doesn’t it matter as to how x and y are declared? After all if they are dclared as: int x[1000], y[1000];"

Those array declarations aren't function argument declarations (except in pre-C89), so not sure why he would talk about semantic equivalence in response to that if it only applies to function arguments.

Reeks of an anti-C bias. This comment by the author is flat out wrong, and I quote:

""" `int x[1000]` in C or C++ doesn’t have much meaning. It’s semantically equivalent to declaring “x” as `int *x`. You can reassign X any time you want, to make it point to a different location. """

C is also a pretty different language style-wise than C++. Aside from that, they're both good languages for building runtimes since their memory model resembles physical memory and they can run in an unhosted (runtime-less) environment.

Just a childish rant really.

    [headerB64, payloadB64, signatureB64] = jwt.split('.');

    if (atob(signatureB64) === signatureCreatingFunction(headerB64 + '.' + payloadB64) {  
        // good
    } else
        // no good
    }

You really need a constant time compare for the signature, else you leak information about the correct signature in the timing of the response.

The "shader" would take in the current application-specific description of the scene.

This description in theory would be much much much smaller than the corresponding assets required to render the scene. It would be trivial to eagerly bind to the shader.

The asset shader API could provide information on the current GPU's texture rendering parameters/quirks.

It doesn't have to be this complicated. It only seems complicated because your solutions are stuck in the context of memory mapping.

A very simple solution is to add another logic layer to GPU processing, like a shader. It could be the "asset shader," it would run on each frame and tells the GPU what assets to start preloading, etc. That would give the programmer tight control over asset loading latencies without having to load everything at once.

Mmap() is not the only obvious solution for unused assets. There are other ways with more explicit operational specs. If you design the solution for this problem from first principles, you'll come up with something more appropriate than mmap()

Rust is better than C++

I was facepalming too while reading this. I'd expect Carmack to understand the ugly truth behind mmap: it's not free. It's more than not free, demand-paging actually adds significant cost: TLB flushes aren't performance friendly.

Linux ppl realized this and implemented MAP_POPULATE but once you're doing that you might as well just eagerly populate the normal way.

Mmap() can be a convenient interface when you aren't latency sensitive but otherwise it's not appropriate.

War is terrible. Average citizen doesn't realize it until there's a draft or until after they're a veteran.

I hope one day we'll reach critical mass of war awareness and stand up against it. For now, we're building "modern" smaller target nuclear weapons.

I don't think UB is bad. It's a reasonable thing to do when someone invokes an operation with bad input.

For instance, what should `sqrt(-1)` be? Or `head([])`?

You can define all behavior and say "bad input will throw an exception" or "bad input will abort the entire program" but who really cares what it does since it's a malformed program in the first place? Just say it's undefined and it's up to the programmer to make sure it never happens. Otherwise you're littering your code with countless checks for things that should never happen in a properly coded program.

Programmer error is distinct from operational error. There is no sane thing to do in a program error. Constantly checking for programmer error at runtime is wasteful.