Just run the code that provisions the infrastructure? Sandboxing is the least of your problems. You would need to fully mock out all function executions and their results to have a hope to properly execute the code let alone govern what's happening without affecting a live environment. And even still, there would be ways to fool this kind of introspection, as I mentioned. In an enterprise environment where this kind of governance is mandatory, that's not acceptable.
In any case, regardless whatever clever method you try to use, even if you're successful, it's not as straightforward and easily understood and extensible as OPA policy. Let's say you succeed in governing Rust code. OK, but now I have developers who are writing in Python and Java and TypeScript. What now? Develop a new, customized solution for each one? No thanks
This. I really wish I could be workikg in hardware, but the salary incentive is just there. Now I am stuck doing backend job to afford life and my low level and hardware hobby (reverse engineering games and firmwares, emulator, fpga stuffs), things that are magnitudes harder than making an api that put stuffs in DB and kafka
Not sure myself. Commit messages look pretty human. But the emojis in readme and comments like "// Re-export key structs for easier access", "# Add any test-specific dependencies here if needed" are sus indeed.
I think pretty clearly the source is also at least partially generated. None the less, just a README like that already sends a strong signal to stop looking and not trust anything written there.
It is very procedural/object oriented. This is not considered good Rust practice. Iterators make it more functional, which is better, more succinct that is, and enums more algebraic. But it's totally fine for a thought experiment.
Never knew Rust could be that readable. Makes me think other Rust engineers are stuck in a masochistic ego driven contest, which would explain everything else I've encountered about the Rust community and recruiting on that side.
Most Rust code looks like this - only generic library code goes crazy with all the generics and lifetimes, due to the need to avoid unnecessary mallocs and also provide a flexible API to users.
Don't underestimate what some programmers trying to prove their cleverness (or just trying to have fun) can do if left unchecked. I think most Rust code does indeed look like this but I've seen plenty of projects that go crazy with lifetimes and generics juggling where they don't have to.
Not short sighted if _that_ is the goal. Maybe it's just to cut off people they have overhired during the pandemic. Maybe they just need fresh faces without costly layoffs