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!
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.
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.
> 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.
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.
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.
Buck and Bazel have the right architecture. Just need a version written fresh without all the baggage.