philippta

If the array list has enough capacity, you don't know if it allocated or not.

FWIW you can make procedures contextless:

    proc "contextless" ()

On the Odin vs Zig allocator bit:

In Zig you pass an allocator to every function that allocates, even if it doesn't make a lot of sense.

    const arr = std.ArrayList(i64).empty;
    arr.append(allocator, 1);
    arr.append(allocator, 2);
    arr.append(allocator, 3);

This rarely makes sense, as it's not really useful to append using a different allocator than you used previously.

In Odin, allocators are passed in the init, stored as part of the struct and reused in the append.

    arr := make([dynamic]i64, 0, 10, context.allocator)
    append(&arr, 1)
    append(&arr, 2)
    append(&arr, 3)

React to some degree made immediate mode UI possible in the browser, which is part of why it is this successful. If the browser gave the option to do ui = f(state) natively, you wouldn't need React.

> For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically

You can generalize this far beyond per-frame semantics. Think per-http-request, per-pubsub-message.

Per each, you can create a new virtual.Arena, set it as your context.temp_allocator and use it for the entirety of the request or message. Afterwards, throw it away.

I think TVs are just used as a residential proxies. No remote controlled chrome is running there.

Having watched both, they cover completey different topics.

I recently heard a great analogy for this exact problem under the premise of "Make it work, make it right, make it fast".

Assume a sorting algorithm as a metaphor for your whole program.

You make it work by implementing the simplest thing you know how to write: bubble sort. Works.

At the end you notice it's way too slow and replace with something much better: quicksort.

Now, how much of your program is surviving? Almost nothing, perhaps except for the "greater than" comparison.

If you apply that idea to a real world program, we're pretty much talking about a full rewrite.

That might apply to personal users. But to businesses the switching cost is just too high. We had a discussion about it on our team. It was decided to keep using GitHub unfortunately.

The most shocking thing to me about the entire GitHub fiasco is: No matter how bad the uptime is, no matter how bad the UI is. We will keep using the software / service we depend on.

Why do we as software engineers have set fault tolerance and high availability as the primary goal of any software / infrastructure architecture? This shows it's completely irrelevant.

> There are surely cases where having an interface as an abstraction and multiple implementations makes sense.

I think most people aren't aware of the alternative, which is: A function that can call different implementations based on some other variable.

E.g. instead of having RealDB and MockDB type have a createUser() (method), you have a createUser() (function) that switches part of it's logic based on what DB is selected.

That's the prodecural way of achieving the same thing without needing a concept for virtual functions.

Casey explains this in the long discussion with Uncle Bob.

Even in memory safe Rust, out-of-bounds array access also results in crashes.

The whole point of memory safety is that bugs can not be exploited. A memory safe program does not mean a crash safe program.