We’re a close-knit, remote-first team of engineers building next-generation, interactive rendering technology that powers a growing portfolio of high-profile creative tools, including the Substance suite of products.
We’re looking for a software engineer with a passion for computer graphics —real-time or offline— to lead and evolve our quality engineering efforts. This role combines strong software engineering skills with a deep focus on rendering quality and infrastructure. As part of the core rendering team, you’ll contribute C++ code, build tools and tests, and play a key role in ensuring the renderer stays fast, stable, and visually correct across diverse hardware.
Fee free to reach out if you have any questions, my email is in my profile.
https://careers.adobe.com/us/en/job/R154963/Rendering-Softwa...
The author doesn't claim to be implementing the C++ standard library. They clearly say they are implementing a C++ standard library.
It's obvious from the context that they mean a hobby-scale set of basic datatype and algorithm libraries. It would take an uncharatible reading to not realize that they mean a lowercase "standard library", not "conforming implementation of the ISO C++ Standard Library".
The article literally says "It's my time, and I'll waste it if I want to!" and uses "pystd" as the namespace.
IMO they should do a better job of referencing existing papers and techniques. The way they wrote about "adaptors" can make it seem like it's something novel, but it's actually just re-iterating vanilla LoRA. It was enough to convince one of the top-voted HackerNews comments that this was a "huge development".
Benchmarks are nice though.
What gets executed is a direct mapping of Python semantics to hardware. In that sense, this is more “direct” than most systems running Python.
This phrasing is about conveying the architectural distinction: Python logic executed natively in hardware, not interpreted in software.