I was quite confused when I learned that the spec technically supports metadata about whether the data is already pre-sorted by some column(s); in my eyes seemed like it would allow some non-brainer optimizations. And yet, last I checked, it looked like pretty much nothing actually uses it, and some libraries don't even read this field at all.
Readit Newsadrian17 commented on The two versions of Parquet jeronimo.dev/the-two-vers... · Posted by u/tanelpoder
adrian17 commented on Rethinking DOM from first principles acko.net/blog/html-is-dea... · Posted by u/puzzlingcaptcha
I like the DOM. I think people keep forgetting all the small details, like being responsive (working on mobile and desktop) and many other issues related to privacy and usability. IMEs, dictionaries, spelling correction, etc... All of these happen in text areas. If you implement things yourself, say in canvas on a webpage, you can't provide these. For example if I misspel somethng the browser can lookup that word in the user's dictionary but your page can not as looking through a user's dictionary would be a privacy issue.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
> Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view:
- right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),
- when you click the account switcher, as long as its open, the rest of the site ignores the mouse events; attempting to drag the map screen doesn't close the switcher, hovering over buttons doesn't change the cursor etc.
adrian17 commented on Reflections on 2 years of CPython's JIT Compiler fidget-spinner.github.io/... · Posted by u/bratao
The article also specifically calls out machine code generation as a separate thing. I confess that somewhat surprises me, as I would expect getting machine code generated would be a main source of speed up for a JIT? That and counter based choices on what optimizations to perform?
Still, to directly answer the first question, I would hope even if there wasn't obvious performance improvements immediately, if folks want to work on this, I see no reason not to explore it. If we are lucky, we find improvements we didn't expect.
> I confess that somewhat surprises me, as I would expect getting machine code generated would be a main source of speed up for a JIT?
My understanding is that the basic copy-and-patch approach without any other optimizations doesn’t actually give that much. The difference between an interpreter running opcodes A,B,C and a JIT emitting machine code for opcode sequence A,B,C is very little - the CPU running the code will execute roughly the same instructions for both, the only difference is that the jit avoids doing an op dispatch between each op - but that’s already not that expensive due to jump threading in the interpreter. Meanwhile the JIT adds an extra possible cost of more work if you ever need to jump from JIT back to fallback interpreter.
But what the JIT allows is to codegen machine code corresponding to more specialized ops that wouldn’t be that beneficial in the interpreter (as more and smaller ops make it much worse for icaches and branch predictors). For example standard CPython interpreter ops do very frequent refcount updates, while the JIT can relatively easily remove some sequences of refcount increments followed by immediate decrements in the next op.
Or maybe I misunderstood the question, then in other words: in principle copy-and-patch’s code generation is quite simple, and the true benefits come from the optimized opcode stream that you feed it that wouldn’t have been as good for the interpreter.
adrian17 commented on Discover C++26's compile-time reflection lemire.me/blog/2025/06/22... · Posted by u/jandeboevrie
Wow. That is... certainly some syntax. It reminds me of Perl.
This syntax is pretty weird even by C++ standards, and it's certainly the worst way to do reflection I've personally seen. But I guess it's good that C++ is finally getting some kind of reflection. Only a few decades late to the party but hey they got there in the end.
Really as C++ grows and evolves, I feel more and more that I'd rather use plain C than wrangle with all of the bizzarro choices C++ has made. C++ is more and more often just the wrong choice of language for anything I want to do. If I need compile-time reflection, I'll use a C# program to generate C code.
> If I need compile-time reflection, I'll use a C# program to generate C code.
This isn't reflection though, it's just textual code generation. In a way, it has the same problem's Rust's macros have (and indeed I'd love to have this kind of reflection in Rust). As an example, if you're implementing some kind of automated serialization, given an input struct with several fields, how can you even just find out its size? Or at what offset each field lives? Or if the field can be naively memcpy'd? You can hardcode the values if you do lots of assumptions and restrictions, or you can re-implement the logic the compilers already also do - but IMO it does feel the cleanest to just ask the compiler at compile time, which is exactly what C++ reflection proposal does.
adrian17 commented on Discover C++26's compile-time reflection lemire.me/blog/2025/06/22... · Posted by u/jandeboevrie
Oh noes, the binding of internal compiler state to STL will become even more severe with this. It started slowly. You needed exact magic std::initializer_list definition in your headers to match the code generated by the compiler, or the program would crash. RTTI (that was of little use to programs that tried to avoid standard library)
Now there are coroutines and this thing. I feel like it is bye-bye to the completely non-standard compliant practice of using C++ without all the standard library.
Where should embedded c++ projects go now that they are not welcome anymore?
The std::meta stuff are only ever running at compile time, so I don't think this would actually interfere much?
adrian17 commented on Discover C++26's compile-time reflection lemire.me/blog/2025/06/22... · Posted by u/jandeboevrie
Wow. That is... certainly some syntax. It reminds me of Perl.
This syntax is pretty weird even by C++ standards, and it's certainly the worst way to do reflection I've personally seen. But I guess it's good that C++ is finally getting some kind of reflection. Only a few decades late to the party but hey they got there in the end.
Really as C++ grows and evolves, I feel more and more that I'd rather use plain C than wrangle with all of the bizzarro choices C++ has made. C++ is more and more often just the wrong choice of language for anything I want to do. If I need compile-time reflection, I'll use a C# program to generate C code.
As for syntax, note that as the author says:
> I do not have access yet to a true C++26 compiler. When C++26 arrive, we will have features such as ‘template for’ which are like ‘for’ loops, but for template metaprogramming. Meanwhile, I use a somewhat obscure ‘expand’ syntax.
In particular, regarding the most cryptic line:
[:expand(nonstatic_data_members_of(^^T, ctx)):] >> [&]<auto member>{
In fact, at least from what I know, `expand()` and this fancy use of `>>` aren't actually part of the standard (the standard proposal uses them as an temporary example in case other features didn't get in). The equivalent (I think) line with the C++26 approved features would be a bit more friendly:
template for (constexpr auto member : nonstatic_data_members_of(^^T, ctx)) {
So while it's still not the prettiest thing in the world and knowing C++, it surely will produce some eldritch metaprogramming abominations, the author's examples made it look slightly uglier than it actually is.
adrian17 commented on Rust compiler performance kobzol.github.io/rust/rus... · Posted by u/mellosouls
> Macros themselves are a terrible hack to work around support for proper reflection.
No, I'm not sure where you got this idea. Macros are a disjoint feature from reflection. Macros exist to let you implement DSLs and abstract over syntax.
They are disjoint, but the things you can use them for overlap a lot. In particular, I'd dare say a majority of existing `#[derive]`-style macros might be easier to implement in a hypothetical reflection layer instead.
Instead of taking a raw token stream of a struct, parsing it with `syn` (duplicating the work the compiler does later), generating the proper methods and carefully generating trait checks for the compiler to check in a later phase (for example, `#[derive(Eq)] struct S(u16)` creates an invisible never-called method just to do `let _: ::core::cmp::AssertParamIsEq<u16>;` so the compiler can show an error 20s after an incorrectly used macro finished), just directly iterate fields and check `field.type.implements_trait(Eq)` inside the derive macro itself.
That said, that's just wishful thinking - with how complex trait solving is, supporting injecting custom code in the middle of it (checking existing traits and adding new trait impls) might make compile time even worse, assuming it's even possible at all. It’s also not a clear perf win if a reflection function were to run on each instantiation of a generic type.
adrian17 commented on Rust compiler performance kobzol.github.io/rust/rus... · Posted by u/mellosouls
> On this benchmark, the compiler is almost twice as fast than it was three years ago.
I think the cause of the public perception issue could be the variant of Wirth's law: the size of an average codebase (and its dependencies) might be growing faster than the compiler's improvements in compiling it?
adrian17 commented on The last six months in LLMs, illustrated by pelicans on bicycles simonwillison.net/2025/Ju... · Posted by u/swyx
Have you missed how everyone was Ghiblifying everything?
I saw that, I just didn't connect it with newly added multimodal image generation. I knew variations of style transfer (or LoRA for SD) were possible for years, so I assumed it exploded in popularity purely as a meme, not due to OpenAI making it much more accessible.
Again, I was aware that they added image generation, just not how much of a deal it turned out to be. Think of it like me occasionally noticing merchandise and TV trailers for a new movie without realizing it became the new worldwide box office #1.
adrian17 commented on The last six months in LLMs, illustrated by pelicans on bicycles simonwillison.net/2025/Ju... · Posted by u/swyx
> This was one of the most successful product launches of all time. They signed up 100 million new user accounts in a week! They had a single hour where they signed up a million new accounts, as this thing kept on going viral again and again and again.
Awkwardly, I never heard of it until now. I was aware that at some point they added ability to generate images to the app, but I never realized it was a major thing (plus I already had an offline stable diffusion app on my phone, so it felt less of an upgrade to me personally). With so much AI news each week, feels like unless you're really invested in the space, it's almost impossible to not accidentally miss or dismiss some big release.