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 benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago and my findings match what this post is talking about.

https://github.com/philippta/postgresql-cockroachdb-benchmar...

I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch.

https://pkg.odin-lang.org/core/text/edit/

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.

See Casey's code snippets here: https://github.com/unclebob/cmuratori-discussion/blob/main/c...

> 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.

To me this looks like a cool demo product. Yet, the problem it's solving could be equally solved by a well integrated all-in-one business suite.

I don't run a small business myself, but I assume the scope of administrative tasks in such company is well defined and understood.

Not my app. Saw it online and found it funny. I'm #27

In the recent Dwarkesh Podcast episode Jensen Huang (Nvidia) said that virtually nobody but Anthropic uses TPUs. How does that add up?

Wookash Podcast

That's completely relatable, and also a major point in my original argument. Using heavily abstracted frameworks will automatically cap you performance wise. The only way out is to not use a framework or one that's known to be lightweight. In backend or tooling like with the JS compiler from OP, one tends to not use heavy frameworks in the first place.

Nobody expects you to know that, but I'm curious to hear how do you know it for backend code but not frontend code. Have any examples?

It's not too diffcut in the browser either. Consider how often you're making copies of your data and try to reduce it. For example:

- for loops over map/filter

- maps over objects

- .sort() over .toSorted()

- mutable over immutable data

- inline over callbacks

- function over const = () => {}

Pretty much, as if you wrote in ES3 (instead of ES5/6)

It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers.

Not to discredit OP's work of course.

> They use Claude to skip the typing, not the thinking. They're 10x faster than two years ago.

I'm not sure a 10x increase in typing speed makes you a 10x developer.

I've raised this exact point to many team leads throughout my career.

Yet, they unanimously said, they are interested or need to know the progress.

I can't say if thats what they have to report to their managers, but I assume it's something you won't be able to fix from bottom-up.

For the handful of regularly visited websites, I wouldn't mind.