nicebyte

doesn't c++ just handwave them away as undefined behavior 😁

Yeah, that's why I mentioned value_or_error<T>. you can't not check it (well, you can but the result will be much the same as neglecting to write a catch block).

yeah, from the runtime perspective well-implemented exception machinery should be almost indistinguishable from the "return the error code" pattern. I just question the whole "let's make error checking a part of the language" approach as adding unnecessary burden (see my comment in another thread)

as from user's perspective I don't think they're that ergonomic anyway, value_or_error<T> is a lot more understandable, predictable and easy to follow.

I'm not worried about their runtime cost or anything like that. But they hurt the language in two ways: 1. high-quality implementation is very nontrivial 2. the interplay between exceptions and current (and future) lang features is also nontrivial. they're a net maintenance burden on the language.

no sorry, I'm assign-if-ok gang.
maybe google3 standards broke my brain but not having the potential failure modes be part of the func signature feels criminal.
plus, exceptions are so much harder from the implementers pov - I just really don't see the wins from them.

one of my huge disappointments in swift. Its like the language authors expect the language users to be conditioned to this error handling approach and incapable of getting used to anything else.

so, is there by now an agreement in the c++ community that exceptions were, by and large, a costly design mistake?

this point came up in a discussion some months ago which made me realize that supporting proper lambdas in hlsl would mean this "anyhit shader" logic could be passed in as lambda and inlined with the "hidden" code that does bvh traversal. maybe that'll happen some day..

YouTube video by Hugh Chew Texel Density Explained

www.youtube.com/watch?v=vehI...

"100% of claude code is written by ai" yeah i can tell by the bugs.

It's easy to stay on 10 and never upgrade. That's my plan until it becomes untenable, then it's Linux time.

YouTube video by Sheafification of G Lauding a Language is Very Mid

programming in llvm IR
youtu.be/dAMXxxOtJUc?...

lucky, the huge torii gate was closed for repairs when i went.

finally, sunset in kyoto.
no filters here. it was about 10 times more pretty in person. i haven't seen another sunset like that since.
might be one of my most treasured non-portrait photos.

tokyo imperial palace garden

sunset in tokyo

view from mt misen

mt misen ropeway in miyajima

deer of miyajima

snoozing sea lion at osaka aquarium

yasaka pagoda

inari's messenger

to break up the cycle of doom scrolling for you, here's a thread of some japan travel pics from various years.

torii gate of hakone shrine at lake ashi:

by enabling lto I shaved off a quite hefty chunk.

can i do this with just compiler flags?

i am guessing the baseline c binary is comparatively small due to being dynamically linked with libc. rust probably links the rust std bits statically, but it _also_ depends on libc.

freestanding c executable also 16K but if we look at byte size it's just a tiny bit shorter than the equivalent rust one (about 170 bytes)

quick binary size check for a program that immediately exits:

c compiled with clang, with stdlib: 20K
rust compiled with rustc, no stdlib: 16K
rust compiled with rustc, stdlib included: 432K

all 3 have highest optimization level enabled

Small indies are hurting for capital so bad right now and the way for them to make money is freakin anything but a niche market like vr. I don't know which investor would even look that way as of today.