forrestthewoods

auto-vectorization is not nearly as good as you would hope it to be.

The best SIMD optimizations likely require changing your data format from AoS to SoA.

This is all true.

But it’s still a counter-example to “once cameras go up all trust is lost”. Clearly cameras are not the sole issue that makes trust achievable. As demonstrated by high-trust societies with cameras!

It’s interesting that Bun was a human rewrite from Go to Zig. (I think?). Then rewritten from Zig to Rust.

AI is pretty good at rewrites and ports. Quite good infact.

However, I continue to be amazed that Perforce survived Git.

Virtually 100% of non-indie devs use Perforce.

Is Perforce good? Ehhh not really. It’s been stagnant for 15 years.

Is Git capable of meeting game dev needs? It’s not enough close. No Git LFS does not count.

Personally I think even Git is mediocre at best. But it’s all modern devs know. So there’s been very little progress towards version control that doesn’t suck. Very sad.

Hopefully Epic’s Lore is good. Low odds. But not zero! And hey at least they’re trying.

Nice post. Thanks for sharing.

Ehh. Cargo has build.rs but calling that a polyglot build system is like calling bash scripts a polyglot build system.

Buck and Bazel have the right architecture. Just need a version written fresh without all the baggage.

the problem is that you need a compiler capable of compiling said zig, python, rust

no! No you do not!!

It’s perfectly totally fine to have multiple different compilers. Literally not a problem at all. That’s my point!

Compilers and build systems are separate. It is perfectly fine for one build system to invoke multiple different compilers.

compilers and build systems are and should be different.

A good polyglot build system should support llvm and zig and python and literally any toolchain under the sun.

The world has yet to standardize on a good crossplatform polyglot build system.

The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords.

It’s a shame.

one of

Seems reasonably accurate? Odin is not particularly popular. Zig is much much more popular. As-is Go, although that’s not a straight C competitor.

But other than that?

Odin is a real language being used by real professionals to ship real software products for money. That alone makes it a rare and notable programming language!

Costco is way too damn crowded. There needs to be 2x or 3x the number of stores. It is a great deal. But an utterly miserable shopping experience.

With wider adoption the ratio shall shift in favor of inference

Yes? That’s why more money will be spent on inference than training?

I’m talking absolute cost. As the number of people using AI and burning tokens goes up the amount of spend on inference goes up.

I am fairly confident that Anthropic has way way more GPUs serving Claude Code to users than they have training models. They’ve got a lot of users!!

API price is becoming more important than SOTA capability.

Also yes? This is why custom silicon for efficient inference makes sense!

I think we’re in total agreement here :)

Inference costs are higher than training now. I think.

Nvidia is king of general purpose training chips. But inferences can be specialized.

…but why? JS/TS does not seem like the right tool for the job?

And one I'm more confident about but expect disagreement on: not building on ROS 2 / LeRobot,

Tell me more! I am slightly biased in that direction. But can’t fully justify it at this point.

You do not "lock assets",

Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it".

Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.

there is no "merging into streams" equivalent.

Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.

P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".

And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.

P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.

But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.

Frickin sweet.

Perforce is a necessary evil in games. Git is simply not suitable. So this is already a huge win.

I main that Git is - at absolute best - simply mediocre. It's not a "good" VCS tool. It is merely adequate.

I would love to see Epic go for a full Git killer.

It looks like Epic has a created a virtual file system interface that is cross-platform. FRICKIN SWEET. This is a critical component to making a VCS tool that doesn't suck. And there has not been an existing open source solution to it.

Spectacular write up. Gonna have to re-read this one a few times to fully internalize it.

Thanks for the conversation. But I think I’m done here. Cheers.

Very rude. I have not personally attacked you a single time.

example of exceptions introducing faulty behavior unrelated to resource management that I asked for?

Well there’s a reason that constructors aren’t allowed to throw. Because it would leave objects in a weird hybrid state.

My physics system example would be the canonical one. You have a system that is transforming from one state to the next. An exception is thrown in the middle of the state transition. Whatever invariants you had for either state is (plausibly) not held. I believe your solution to this was to treat it as a transaction and rewind/restore to the previous state if an error is encountered.

It’s difficult because I would simply literally never use exceptions for anything ever. My experience with them is strictly negative with zero positives of any kind. I genuinely can not think of a single thing they make better. Nor have I ever encountered a library or codebase where I felt exceptions made it better. But boy howdy have I been frustrated by exceptions.

boost often has two APIs one with exceptions and one with error code reference arguments. I intend to always use the EC version. And god damn is it fucking frustrating when I accidentally use the exception version and so I get a runtime exception for a vanilla error that I wasn’t expecting. Which is why hidden control flow is evil!

All else being equal, exceptions make this kind of code better by making it more readable.

I just fundamentally disagree that hidden secret control flow makes code more readable. Well, it may be more readable but it is, imho, significantly less understandable.

There’s a reason that literally no modern systems language has adopted C++ exceptions.

We’re just about at the point of discussing syntactic sugar. So one question is “given current C++ capabilities should you use exceptions or not?”. Another is “should C++ add different sugar for error handling?”. And a third is “should a different language adopt exceptions-like design?”.

Imho a zig or rust like error system with a ? operator to return is vastly superior. Fallibility and control flow is super explicit, obvious, and easy to read.

Current C++ is a little jankier. Designs vary. All have tradeoffs. But imho they are all preferable to secret hidden control flow. So exceptions are, in my lived experience, a strictly inferior choice.

You're being rather vague.

Completely forget about memory allocation and memory allocation like things.

Let’s say I have a physics system that runs an update. Assume we catch outside the update. If anything throws the system is now in an intermediate state and is effectively irrecoverable.

If you want to argue that exceptions should only be used for irrecoverable errors such that the subsystem is not expected to resume then I would list. This is akin to Rust panics which unwind like C++ exceptions but are not intended to resume. I have not read any comments in this large subthread arguing for using exceptions in this narrow style.

it’s impossible to know what “may throw”

Yeah you’re just saying you should basically assume that any code can throw at any point. I think that’s a really really bad design pattern that makes code significantly harder to reason about. Control flow should be clear and obvious. “Any line of code could immediately unwind to unclear catch” is the objectively not clear and obvious.

But let me turn it around. You tell me an example of a system that doesn’t use exceptions where adding exceptions makes it better.

^^^ truth speaker

Program state is significantly more complex than just needing some RAII resources to cleanup via destructors.

during sections that may throw

Yeah one of the problems with exceptions is it’s impossible to know what “may throw” other than “well I guess literally anything so everything”. It is very irritating.

At the end of the day exceptions are just a little syntactic sugar. Or perhaps syntactic bitters.

It is notable that systems languages designed after C++ all chose to not include exceptions. Go, Zig, Swift, Odin, Jai.

Rust panics are kinda sorta exceptions in that they unwind. But their intended use case is for irrecoverable errors. And of course you can set panic=abort.

C++ exceptions are very rarely treated as so serious module level irrecoverability.

You really don't. Like I said, it's kind of the whole point of exceptions.

No, this is actually just wrong. With exceptions you “don’t have to think about” the exception getting caught by some higher level catch.

But you do have to think about it in the sense that every single line in your code could unwind. Which makes ensuring you remain in a valid state more difficult.

One of the issues with exceptions isn’t the throw. It’s what do you do after you catch.

That a tool can be misused doesn't delegitimize the tool.

I’m always open to the possibility that if something I’ve seen has been bad 100 times then on the 101st it might be good. But at some point you really just have to call a spade a spade.

Throwing lets you handle the new situation without changing the API at all.

I do not disagree. https://xkcd.com/1172/

If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code. The fact that it compiles and runs but will behave in undesirable ways makes it even worse, not better!

or if you really must not throw from the function,

I’m aware.

But if your library that offers foo adds exceptions now I need to think about it at every single callsite, and probably wrap the function. It’s extremely irritating.

learn how to use them properly.

In my 20+ years of professional C++ development I have a great experience not using exceptions and a strictly negative experience using them.

Perhaps sometimes I’ll stumble upon a library or codebase where exceptions make the code simpler, easier to understand, and easier to write. But my experience is exceptions make everything strictly worse and that not using exception is a strict win with zero downsides.

That’s a No True Scotsman argument. It is not a good or useful one imho.

What if you don't control those call sites?

If I am choosing to change the API contract then someone who wants to use the new API has to update. This is not a big deal.

If the function doesn't use exceptions for normal error conditions, then no, it's not a new contract

I disrespectfully and emphatically disagree. I do not accept your definition of contract.

You could do something like (try-catch wrapper)

Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design.

If you think a function should return a value or some unspecified exception whose details are irrelevant then that function could return an option with no information loss, or a result with an Error that is ignored.

You wouldn't iterate a vector like this, I imagine?

I wouldn’t use at(i) for iteration. The only reason for a function like at(i) to exist is because you want it to be fallible.

The only two ways to resolve this contradiction is to throw, or to terminate.

Or they’re bad APIs that should be redesigned to be not bad.

They’re fallible functions. Don’t write fallible APIs that require exceptions to report errors! That’s bad API design!