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!)
Is Deno not convenient and fast? I am also interested in knowing why I would want to use Bun over Deno.
This is 14 years old by now - hardly "modern". RAII itself is even older.
Hmm I think just using SQLite or DuckDB with normalised data would probably get you 99% of the way there...
What do you mean?
That's not entirely true, e.g. you can do fuzz testing or constrained random testing. Maybe you aren't including those in "testing"?
I think those jobs are a myth. You probably get like a 20% premium for using COBOL, so if you look up the salary of a Cobol consultant in America it's going to seem like an enormous salary on an absolute scale.
But so is a C++ consultant in America or whatever. Probably not worth learning COBOL for.
Feel free to correct me if I'm wrong, but I have looked once or twice and the COBOL salaries seemed entirely normal.
I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.
And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.
Yeah I think RISC-V is probably still about 10 years away from being a sensible choice for a laptop. There's a load of platform stuff around things like ACPI and Device Tree that's still being decided. Also some ISA extensions that are standard on x86/ARM are either unratified or very recently ratified (e.g. Vector).
For microcontrollers it's ready now, and for server applications it's probably doable now and will be solid in a few years. Laptops & phones will be last though.
Should've known better than to what? Use Cloudflare?
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?".