Yeah, exactly! Just a tiny fraction of the AI money could make real programming so, so much better

(Also lol, yes I know that ai seems particularly good for making dev tools, but it’s not so good that making advanced new tools as a solo developer becomes tractable)

Like clearly not everything and I know that some of that is in itself powerful and that sometimes having an ai interface is useful, but a lot of the time I just wish I could do some of this more mechanically (and I know how to make a tool which could, but it’s a huge amount of work)

@ncameron.org has written a couple posts about the work he did with Zoo on KCL, their CAD programming language. This one on how it handles units is *super* interesting and gives a good taste of the neat kinds of not-mainstream(-yet!) problems to solve in their space: www.ncameron.org/blog/kcl-par...

I want bigger releases - it is hard to review, but lots of little changes are harder because they are still hard and you end up having to review all the time.

Yeah, it seems like some kind of certification is necessary, but I don’t know how it would work in order to be effective

Yeah, it’s a shame, it would have multiple benefits of which security seems the most pressing right now. But it’s hard and there are trade offs is enough to make a lot of people very negative on the idea

I think hipcheck is cool! (sorry, I should have mentioned it alongside crev and vet), but the space which is still left is terrifying to me!

Also, detection of issues at scale with the help of automation is good. It's why at MITRE we built @hipcheck.mitre.org, though there's more work to do for it and it would need to catch on. At the very least, common detection drives up cost / complexity for attackers.

Yeah, I think we (as an industry) have made great progress on the class of issues around ensuring the code in the dep's repo is the code in the build, but I fear that finding issues with the code 'in the repo' is still too hard

I'm not sure exactly what, but some sort of certification of orgs or crates to make trust in the ecosystem more explicit. This part is a social rather than technical problem and needs a social solution

promote a culture of fewer deps (supported in part by the expanded std), more tightly tying deps to features so that crates can at least be used with minimal deps, and slower releases to make review easier

expand std or otherwise have the core project own and distribute core functionality crates

remove build scripts for dependencies immediately, then work on a limited replacement. Prioritise (as in nothing else ships until it is done) sandboxing and/or permissions for proc macros

As a community there are things we could do, but they're a bit unpalatable. I would do these things as if my house was on fire, but I don't think there is the will or community culture to do so (and maybe that is for the best since they are big changes):

Take a sort-of-strong stance on SCS which makes you feel better but which is mostly security theatre. This is what most orgs are doing, IMO

Decide your users are not a big target and security doesn't matter too much, and run you builds inside a locked-down environment. Great, if this really works for you