robinei

I assume they dismantled and sold what they could? Like the roller coaster

No, in reality 3.1 was actually very fast.

I'm not convinced that redrawing on input events is especially inefficient. No need to redraw continuously.

There is no reason an IMGUI cannot efficiently construct a hierarchy in the background and do a fast Flutter-like linear layout pass on it before processing input and rendering it. Then throw this away and do it all over again for the next frame (or the next time input arrives, if not used in a game-like context). I've experimented with this, and speed is no impediment if implemented correctly.

IMGUI is about the immediate mode interface, not about layout/rendering/input handling happening at the same time as view functions are called. And don't do "if (Button()) { ... }", but use lambdas for event handling, so the handlers can be invoked at the proper time when everything is laid out.

The most important reason for "do" is avoiding excessive indentation, when starting with the first expression on the same line. And "fn" is good for something that you will want to avoid taking too much space, since you want to sprinkle them everywhere.

I also think that engineering concerns can dictate or at least strongly influence language design. It can still lead to innovation though, like in the way Zig handles async/await, and how it will try to handle recursion.

It is just innovation mostly guided by practical engineering concerns. In this case: How to avoid requiring expensive heap allocation for async tasks, and how to be sure you don't crash from a stack overflow due to unexpected input for example.

I suspect that the excellent Zig comptime support is made possible by intentionally going for a pretty unambitious type system. Otherwise how could you soundly let arbitrary code generate a type? A fancy type system that wants to reason about that will fail, or at least cause the whole language to revolve around making that work.

I think you are right that it would be very hard for a language to innovate both here, and in the traditional PL-teoretical way.

I have the feeling that what will push Zig ahead is the uncanny sense of technical aesthetics shown by the creator. Unsexy details like language simplicity, what-you-read-is-what-runs, orders of magnitude faster compile times, effortless cross compilation and C interoperability.

I have never seen anyone focusing so ruthlessly, so early, on nitty-gritty details of how to go about engineering a compiler and language that is and will let you be as close to optimal as possible in terms of compile-time and run-time performance. "Perfect software" as Andrew talks about.

In short, engineering choices taken early will let Zig be something that Rust maybe could approach too (in theory), but in practice never will. Of course Rust is something that Zig will never be, too.

If the banks were going to default without taxpayer help, why didn't we just nationalize them and let the share holders take the loss they themselves have set themselves up for? Then we could shoulder the cost of getting the banks afloat again, and then subsequently regain some of the cost at least by selling them (instead of just giving taxpayer money to the risk-taking share holders like we do now)

I meant to say homogenous array, which I assume you were talking about.

Since you are talking about a heterogeneous [edit: homogeneous] array, you would store the concrete structs continously in Rust as well. Rust would also not waste space in the vector for storing a vtable-pointer, and would instead construct fat pointers dynamically when needed (since it knows the type, it knows which vtable to inject in the fat pointer).