Sounds like observability, proper load testing, etc. beat a system without that. Saying that spaghetti code beat clean code makes it sound like it won because it was spaghetti code.
I haven't watched the video, nor am I going to with a clickbaity and apparently misleading title like that.
Right, I'm not saying it isn't simpler in terms of syntax. The point I was making is that the syntax is simpler but in a way that makes it worse because while it's easier for computers to read, it's harder for humans.
it was only later discovered that they can be compiled down to native code.
That sounds extremely unlikely. I think you're misinterpreting this quote (which is fair enough; it's not very clear):
Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today ...
As far as I can tell Lisp was always intended to be compiled and executed. That quote is about compiling the eval() function (which was just meant to explain how Lisp is executed) into a binary and using that as an interpreter.
Also I skimmed the paper that is from, and in fact Lisp was intended to be targeted by AI (in the same way that we get AI to write and execute Python to solve problems), which explains a lot. It wasn't designed for humans to write, so why bother with nice syntax; just have the machine write the AST directly!
(I expect that was only part of the motivation tbf, but still!)
It's definitely a growing problem with Rust. I have noticed my dependency trees growing from 20-50 a few years ago to usually 200-500 now.
It's not quite as bad as NPM yet, where it can easily get into the low thousands. Also the Rust projects I have tend to have justifiably large dependencies, e.g. wasmtime or Slint. I don't think it's unreasonable to expect a whole GUI toolkit to have quite a few dependencies. I have yet to find any dependencies that I thought were ridiculous like leftpad.
We could definitely do with better tooling to handle supply chain attacks. Maybe even a way of (voluntarily) tying crate authors to verified real identities.
But I also wouldn't worry about it too much. If you a really worried, develop in a docker container, use a dependency cooldown, and whatever you do don't use cryptocurrencies on your dev machine.
Is Deno not convenient and fast? I am also interested in knowing why I would want to use Bun over Deno.
AI is good at more than just generating stubs, filling in enum fields, etc. I wouldn't say it's good at stuff beyond just "boilerplate" - it's good at stuff that is not difficult but also isn't so regular that it's possible to automate using traditional tools like IDEs.
Writing tests is a good example. It's not great at writing tests, but it is definitely better than the average developer when you take the probability of them writing tests in the first place into account.
Another example would be writing good error context messages (e.g. .with_context() in Rust). Again, I could write better ones than it does. But like most developers there's a pretty high chance that I won't bother at all. You also can't automate this with an IDE.
I'm not saying you have to use AI, but if you don't you're pointlessly slowing yourself down. That probably won't matter to lots of people - I mean I still see people wasting time searching for symbols instead of just using a proper IDE with go-to-definition.
Hmm I think just using SQLite or DuckDB with normalised data would probably get you 99% of the way there...
Nonsense. There are way more programmers now than there were in the Windows 3.1/9x era when you couldn't avoid files and folders. Ok more people are exposed to computers in general, but still... Anyone who has the interest to learn isn't going to be stopped by not knowing what file and folders are.
It's like saying people don't become car mechanics because you don't have to hand crank your engine any more.
Yeah I didn't mean to imply systemd wasn't suitable for professional use, rather that shepherd is only going to be used by people who want to set this up themselves programmatically.
Like how the average computer user is never going to use Nix to install Firefox or whatever.
ARM is very very obviously superior to x86. You won't be able to find anyone informed that will say otherwise.
Probably the biggest way it is better is that instructions are always 2 or 4 bytes which makes wide decoders a lot easier.
A phonetic spelling would also only be more digestible to readers who know the language the phonetic spelling is tailored at
Indeed, it would be digestible to 1.5 billion people instead of 100k.
Functional programming doesn't just mean higher order functions. There's a range of other features that it implies.
Using a function is strictly worse than figuring out the formatting at compile time (something Zig also does).
The derives are just shortcuts. You can write everything out long-hand like you would in C++ or Python too if you really want.
Honestly both of these complaints are essentially "why does Rust use macros to make writing code better/easier?".