Hacker News: crowdyriver

New comment by crowdyriver in "My thoughts on the Bun Rust rewrite"

crowdyriver — Thu, 09 Jul 2026 14:48:10 +0000

I think people are overfocusing on the wrong thing.

Bun is slop. Let's not pretend it is not. It went from 600k lines of zig to almost a million of rust, for a wrapper around a js engine. It might be useful slop, but it is still slop.

It's understandable to have mixed feelings about bun as the creator of the language.

You spend 10 years of your time making a language, and one of the most prominent projects that uses it does it in a nasty and sloppy way. You try to help, but your advice gets ignored.

You make a whole language about improving software quality, only to be associated with a project that doesn't care about it.

For once I do appreciate that somebody is willing to have the guts to say what they think. The bun rust rewrite article said no words about the tradeoffs of moving to Rust (compilation times?), and I agree with the false dichotomy presented. How do we know that most bun bugs were not created because of slop / AI usage / stubbornness?

New comment by crowdyriver in "Solod – A subset of Go that translates to C"

crowdyriver — Tue, 07 Apr 2026 07:14:09 +0000

tbh I'd rather have this behaviour, defer should've been lexically scoped from the beginning.

Why programmatic tool calling is awesome

crowdyriver — Sun, 28 Dec 2025 19:27:43 +0000

Article URL: https://www.guillemus.com/on-programmatic-tool-calling/

Comments URL: https://news.ycombinator.com/item?id=46413688

Points: 1

# Comments: 0

New comment by crowdyriver in "AI will make formal verification go mainstream"

crowdyriver — Wed, 17 Dec 2025 10:42:45 +0000

You already have this problem whenever you are using a library in any programming language. Unless you are extremely strict, vendor it and read line by line what the library does, you are just trusting that the code that you are using works.

And nothing is stopping the AI from making the unreadable mess more readable in later iterations. It can make it pass the spec first and make it cleaner later. Just like we do!

Ask HN: Wouldn't it be much easier if you compress all env vars into one?

crowdyriver — Wed, 12 Nov 2025 21:02:01 +0000

In most apps I develop, there's at most 3 groups of environments, local - staging - prod.

Wouldn't it be easier to just join all env vars needed for each environment into a base64 encoded env var, and then just pass that into the given app?

I feel like there should be less room for error, and it's easy to add new services. There wouldn't be need for cloud vendors like vercel to namespace env vars, you would be already doing it yourself.

Yeah, maybe a small cli utility to generate those envs would be cool, but it looks like that wouldn't introduce much friction.

I can't be the first one to think about this, has this been tried?

Thanks for your input!

Edit: clarity

Comments URL: https://news.ycombinator.com/item?id=45906618

Points: 2

# Comments: 1

New comment by crowdyriver in "Show HN: templUI – The UI Kit for templ (CLI-based, like shadcn/UI)"

crowdyriver — Fri, 30 May 2025 09:13:42 +0000

While I like the modern feel of shadcn/ui and derivatives, I still think that daisyui is much easier to use.

You really just paste these 2 lines in your html and that's it: