uncle_kostya

I'm curious about motivation - bounds checks for corrupted inputs seems like it would be one, but it also seems that fixing corrupted input handling in a C/C++ code base would not be too hard, and probably less of an effort? So why did you choose the rewrite?

And second, did you use any AI tools for the rewrite?

There a flavor of CUDA runtime libraries that binds at runtime, so you can have a single binary that runs with CUDA and without it. I did this at work.

Obviously you need to check if CUDA is available before trying to execute kernels, or it will error out.

If I recall correctly, the Golang team got bitten by this on MacOS.

They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang.

They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.

For me search has been that way since the first MacOS 26.0 upgrade and apparently never fixed.

But speaking of quality overall (outside of the search glitch) - I use dual 5k LG monitors with my work MacBook and can get the MacOS Display Manager process to crash if I just enable variable rate refresh and put the computer to sleep, then wake it up. Apparently a known issue for a few years, still not fixed.

SOAP 1.2 strikes me as really reasonable - it's a mature format with interop to several languages and has schema validation.

The inconsistencies you describe above are probably due to each org in the government implementing the common spec independently of the others, and introducing differences without even knowing. Documentation is key here, but as with any large system, there can be gaps.

It's really cool that you mapped it all.

And kudos to Brazil for creating a common computerized platform.

Spending time at Burning Man can completely detach you from reality

Is anyone even trying to compete with TSMC?

What is the barrier to entry?

It's what we use at work and I'm sure it passed a security audit. How ironic.

Works already in Visual Studio Code, even seamlessly between C++ and Rust

What we do at work is defined a clear boundary and use extern "C" functions in Rust to make them callable from C++, and the same for callbacks.

Required some effort but we're happy with the result.

An Android developer since 2010 here.

I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.

But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?

I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.