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.
Actually chars() is pretty simple - it's just UTF-8 decoding which is elegant and simple.
The complexity is all around unicode, not UTF-8.
This is 14 years old by now - hardly "modern". RAII itself is even older.
That's a fair point. I don't think that's the case here because he talks about all the bad ways he prefers to receive contributions (email, patch files, git bundle etc.).
Config should be pretty flat.
Why? I don't see any reason for that.
TOML rocks precisely because it nudges you into making simpler configs.
This is just "you're holding it wrong".
In most cases you don’t, and when you do, it’s possible and not unreasonable.
Really. Here's the first Gitlab CI example I could find:
lintDebug:
interruptible: true
stage: build
script:
- ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
artifacts:
paths:
- app/lint/reports/lint-results-debug.html
expose_as: "lint-report"
when: always
Let's see the TOML:
[lintDebug]
interruptible = true
stage = "build"
script = [
"./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint"
]
[lintDebug.artifacts]
paths = [ "app/lint/reports/lint-results-debug.html" ]
expose_as = "lint-report"
when = "always"
Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.
IMO JSON5 is the best:
{
lintDebug: {
interruptible: true,
stage: 'build',
script: [
'./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint',
],
artifacts: {
paths: [
'app/lint/reports/lint-results-debug.html',
],
expose_as: 'lint-report',
when: 'always',
},
},
}
This is much clearer than TOML and less ambiguous than YAML. It could do without the outer {}, but overall it's still better.
It's not really messaging that's the differentiator here - it's scale (specifically write scale). If you can't have a single master database then sure you might need NoSQL. But you almost certainly aren't anywhere near that scale. Giant sites like Stackoverflow and Shopify aren't.
D didn't catch on for many good reasons... And it never will. Zig has way more momentum (and it better!) as a "better C", and obviously the main draw of Rust is memory safety without GC which D doesn't have.
How do you expect the system to know what program is important to you and which isn’t?
Hmm
The windows solution is to switch tasks very often and to do a lot of accounting to ensure fair distribution.
Sounds like you have a good idea already!
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?".