> Python lets library authors write __enter__ and __exit__ dunder methods to ensure that memory deallocation is handled correctly via Python context managers, which is a much more elegant abstraction

Whats stopping you from writing a WrapperPtr and the drop trait for it in Rust? This would achieve the same as the dunder methods in python

> nfs mounted fs

Anything doing locks on nfs, including trying to use sqlite, is a mistake. This is not a cargo problem this is a nsf problem.

Is this backed by real evidence?

My experience is 10%-15% slower than GCC. That was 10 years ago though.

What was the rationale to not use cargo? By the way, I really enjoy when you are a guest on the fallthrough podcast.

Thanks!

So, one reason is "I just want to learn more about buck2."

But, for the first iteration of Rue, I maintained both. However, for a language project, there's one reason Cargo isn't sufficient now, and one reason why it may not later: the first one is https://github.com/rue-language/rue/blob/trunk/crates/rue-co... : I need to make sure that, no matter what configuration I build the compiler in, I build a staticlib for the runtime. With Cargo, I couldn't figure out how to do this. In test mode, it would still try to build it as a dylib.

Later, well, the reason that rustc has to layer a build system on top of Cargo: bootstrapping. I'm not sure if Rue will ever be bootstrapped, but rustc uses x.py for this. Buck does it a lot nicer, IMHO https://github.com/dtolnay/buck2-rustc-bootstrap

Unless someone is vetting code, nothing.

> and similar package ecosystems altogether

Realistically, this is impossible.

It's really, really not. Just write the libraries yourself. Have a team or two who does that stuff.

And, if you do need a lib because it's too much work, like maybe you have to parse some obscure language, just vendor the package. Read it, test it, make sure it works, and then pin the version. Realistically, you should only have a few dozens packages like this.

at some point having LLMs spit out libraries for you might be safer than actually downloading them.

This does help. Even before, I was pretty careful about what I used, not just for security but also simplicity. Nowadays it's even easier to LLM-generate utils that one might've installed a dep for in the past.

LLMs will happily copy-paste malware or add them as dependencies

this kicks the can down the road until we get supply chain attacks through LLM poisoning, like we already do with propaganda

Well, he didn’t say vibe code. Presumably, you’d still be reviewing the AI code before committing it.

I ran a little experiment recently, and it does take longer than just pulling in npm dependencies, but not that much longer for my particular project: logging, routing, rpc layer with end-to-end static types, database migrations, and so on. It took me a week to build a realistic, albeit simple app with only a few dependencies (Preact and Zod) running on Bun.

Heh, that's if the reviewer actually is a human doing their job and not another AI just waiting for the right keyword to act like a manchurian candidate.

or just vendor your deps like we have been doing for decades.

still need to read them to make sure you don't vendor a trojan in the first place.

auditing is the first step in vendoring a dep by my definition of the practice

I truly despise the damage those books did to the SWE as a whole.

It’s this simple in .NET

   ArrayPool<T>

will elements of arraypool still be tracked by GC with overhead?

Depends on the T.

.NET has value types, explicit stack allocation, low level unsafe programming C style, and manual memory management as well.

> many devs keep ignoring

And thats why Zig don’t offer much. Devs will just ignore it.

What are you trying to imply?