It's funny that I've seen people both argue that LLMs are exclusively useful only to beginners who know next to nothing and also that they are only useful if you are a 50+ YoE veteran at the top of their craft who started programming with punch cards since they were 5-years-old.
For novices, LLMs are infinitely patient rubber ducks. They unstick the stuck; helping people past the coding and system management hurdles that once required deep dives through Stack Overflow and esoteric blog posts. When an explanation doesn’t land, they’ll reframe until one does. And because they’re confidently wrong often enough, learning to spot their errors becomes part of the curriculum.
For experienced engineers, they’re tireless boilerplate generators, dynamic linters, and a fresh set of eyes at 2am when no one else is around to ask. They handle the mechanical work so you can focus on the interesting problems.
The caveat for both: intentionality matters. They reward users who know what they’re looking for and punish those who outsource judgment entirely.
One of the most iconic lisp saying is literally about how every other languages are supposedly inferior to lisp, so I don't think it's a particularly good example here.
But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).
On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.
But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.
Sadly does not work on fish because the developers does not believe that users are intelligent enough to understand the obvious and intuitive outcome of flipping ">" (a valid operator in fish).
What I meant was transpiling Luau (in memory or cached to disk) -> TypeScript -> typecheck with tsc -> take error outputs and line numbers -> transform back to Luau code via sourcemaps etc. This is potentially way easier than making your own checker for another structurally typed language.
User only sees Luau script in their editor, but it gets checked by TSC in the background.
Roblox might is such a big maker that they can re-invent the whole structural typing themselves, so they don't need to do that.
I really never understood the threat model behind this often repeated argument.
Most of these installation scripts are just simple bootstappers that will eventually download and execute millions lines of code authored and hosted by the same people behind the shell script.
You simply will not be capable of personally auditing those millions lines of code, so this problem boils down to your trust model. If you have so little trust towards the authors behind the project, to the point that you'd suspect them pulling absurdly convoluted ploys like:
> the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code
How can you trust them to not hide even more malicious code in the binary itself?
I believe the reason why this flawed argument have spread like a mind virus throughout the years is because it is something that is easy to do and easy to parrot in every mildly-relevant thread.
It is easy to audit a 5-line shell script. But to personally audit the millions lines of code behind the binary that that script will blindly download and run anyways? Nah, that's real security work and no one wants to actually do hard work here. We're just here to score some easy points and signal that we're a smart and security-conscious person to our peers.
> which are hosted by microsoft, and therefore easily MITM'able by government agencies.
If your threat model includes government agencies maliciously tampering your Deno binaries, you have far more things to worry about than just curl | sh.
I think bflesch's reasoning comes from the idea that the website developers may not hold their website to the same security standards as their software, and not from a trust issue. Nor from thinking the author themselves are malicious.
FWIW, I don't have a strong opinion here, besides that I like Debian's model the most. Just felt that it was worth to point out the above.
> Note that the author used disko to partition the disk declaratively. Disko won't work for a machine with very limited ram, because disko run in the installer, and needs to install tools to the ram to do the partition.
This is only true if you use the disko-install tool, which is a horrible footgun[^1]. The safest approach is to just use the default disko command, then nixos-install.
Thanks for bringing the disko command to my attention.
However, since we are talking about installing NixOS declaratively, and it's done through nixos-anywhere, which will install it[0] to the ram unfortunately.
Comparative benchmarks are a big task on their own, and usually the author's library wins in them. I have internal benchmarks in the repository, but they are not designed for comparison or for evaluation by outsiders. Maybe I'll get to that someday.
I wonder which of these camps are right.