This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends.
And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?
Rust's type system gymnastics compared to most languages goes quite a bit beyond preference. I can't see the overlap at all with dynamic scripting languages, two completely different tools for completely different problems.
> any task that has any sort of safety or security critical risks should never be left to a “magic black box”.
> human input/review/verification/validation is always required.
but, are humans not also a magic black box? We don't know what's going on in other people's heads, and while you can communicate with a human and tell them to do something, they are prone to misunderstanding, not listening, or lying. (which is quite similar to how LLMs behave!)
> at the same time, i could totally see myself scanning through a README and going “yep, sounds like what i need” and making the same mistake (i need other people checking my work too).
yes, us humans have similar issues to the magic black box. i’m not arguing humans are perfect.
this is why we have human code review, tests, staging environments etc. in the release cycle. especially so in safety/security critical contexts. plus warnings from things like register articles/CVEs to keep track of.
like i said. don’t blindly trust the untrusted output (code) of these things — always verify it. like making sure your dependencies aren’t actually crypto miners. we should be doing that normally. but some people still seem to believe the hype about these “magic black box oracles”.
the whole “agentic”/mcp/vibe-coding pattern sounds completely fucking nightmare-ish to me as it reeks of “blindly trust everything LLM throws at you despite what we’ve learned in the last 20 years of software development”.
Sounds like we just need to treat LLMs and humans similarly: accept they are fallible, put review processes in place when it matters if they fail, increase stringency of review as stakes increase.
Vibe coding is all about deciding it doesn’t matter if the implementation is perfect. And that’s true for some things!
> Vibe coding is all about deciding it doesn’t matter if the implementation is perfect. And that’s true for some things!
i was going to say, sure yeah i’m currently building a portfolio/personal website for myself in react/ts, purely for interview showing off etc. probably a good candidate for “vibe coding”, right? here’s the problem - which is explicitly discussed in the article - vibe coding this thing can bring in a bunch of horrible dependencies that do nefarious things.
so i’d be sitting in an interview showing off a few bits and pieces and suddenly their CPU usage spikes at 100% util over all cores because my vibe-coded personal site has a crypto miner package installed and i never noticed. maybe it does some data exfiltration as well just for shits and giggles. or maybe it does <insert some really dark thing here>.
“safety and security critical” applies in way more situations than people think it does within software engineering. so many mundane/boring/vibe-it-out-the-way things we do as software engineers have implicit security considerations to bear in mind (do i install package A or package B?). which is why i find the entire concept of “vibe-coding” to be nightmarish - it treats everything as a secondary consideration to convenience and laziness, including basic and boring security practices like “don’t just randomly install shit”.
Lua was designed for configuration, so I'd rather use Lua. Plus, it makes for a more elegant, unified design. TOML, and friends, are better paired with languages that were not designed for configuration.
It seems like every new language community and generation of developers needs to re-learn a set of the same lessons (why declarative instead of imperative config is the way to go, why functional is superior to imperative, why immutable is superior to mutable, why TDD (or just unit testing) is important, why hexagonal design is the best organization of logic, why static typing is important, why Nix is the only valid global package manager, etc. etc. etc.) and I suspect it's because these problems all share the same attributes:
1) the inferior solution seems easier at first (but won't be in the long run)
2) the people blithely picking the inferior solution have not yet encountered enough of the thorny nastiness that the initially-harder option completely prevents
the end result being that all the "greybeards" have settled on the "initially harder" solutions for things because they all learned the hard way that it just causes less headaches in the long run
I know what lua was designed for and have professional experience with it. It's not that great as a config language imo, I can easily understand why a project would use something else.
With the disclaimer that I know nothing about zig, I will say that Nix's flake files follow an interesting pattern where the output section is evaluated under the regular Nix interpreter and can do anything, whereas the input section is evaluated under a far stricter mini-interpreter that prohibits everything other than basic strings and attrsets (dictionaries).
A flake.nix is certainly not packaging metadata, but I do know those input section restrictions do cause occasional confusion with users who think "ah, Nix code" and only realise afterward that it's really json in Nix syntax."
All that to say, if a thing is not evaluate-able, it's probably best to represent it in a different enough form that no one could mistake it for a thing that can be evaluated.
Why not use a function to add dependencies, e.g. `add_dependency "dependency@version"` or `add_dependencies { ...table-here... }`. This is, more or less, how premake works [1]. For `lx add ...` you'd append the function call to the script.
Hi, I'm Kurtis. I've been programming for ~10 years, 3 years professionally. I'm currently looking for a project that has positive real-world impact; working at a company that chugs out AI slop for the betterment of stakeholders isn't really my thing. The listed technologies are in no particular order, nor are they comprehensive. For relocation: I have Canadian and EU citizenship.
Feel free to shoot me an email with any opportunities you have, or just to connect. (I'm always down to expand my network) Have a nice day :)
Hi, I'm Kurtis. I've been programming for ~10 years, 3 years professionally. I'm currently looking for a project that has positive real-world impact; working at a company that chugs out AI slop for the betterment of stakeholders isn't really my thing. The listed technologies are in no particular order, nor are they comprehensive. For relocation: I have Canadian and EU citizenship.
Feel free to shoot me an email with any opportunities you have, or just to connect (I'm always down to expand my network). Have a nice day :)
Zed is amazing, and I definitely recommend it. That said, I will not be using their AI features, and if the editor turns into a slow, bloated monster because of them (like Visual Studio and anything made by JetBrains) I will have to ditch it.
Hi, I'm Kurtis. I recently moved to Sweden from Canada and I'm looking for work. I've been programming for over 11 years now, but only 3 years professionally (I started young). The listed technologies are in no particular order, nor are they comprehensive. I'm most experienced in game development related fields (think Unity, Godot, C#, OpenGL, shaders, etc.), but I've worked in lots of different roles in the past and I'm always looking to learn new things. My ideal role would be something "high-impact", as in "I make things that have real-world results". If you have any questions about me or my background, feel free to shoot me an email. Thanks!
And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?