I'm quite disappointed that he didn't investigate the slow rust code. Exactly 5s smells like a timeout, so potentially nothing to do with abstraction layers. But i guess we'll never know now.
His point wasnt that the implementation is slow but rather that there obviously is a big bug somewhere but locating it is made difficult by the ammount of code/layers of abstraction. That is the argument is not "layers if abstraction => slow" but "the more code you have the more things can go wrong" which seems like a reasonable take.
Performance is just like traffic! The most effective solution to getting to your destination in the least amount of time isn't to increase your maximum speed, but to reduce the amount of time you're moving slower.
One of the more relevant reasons for dylibs today is that the OS maintainer can patch multiple programs at once by updating a single dylib. With a static binary, each application maintainer needs to release a patch, which may take a long time or possibly never happen.
Talks about lovable programs and zed in the same talk. 1) Zed trying to force AI assistants on you. 2) only way to change settings is in settings.json. 3) default theme is unreadable.
why so? The point of it was that there could be many layers of abstractions that can pose a performance ceiling even in lower-level languages and it managed to convey that quite well
The half baked example with rust abandonware webserver was really out of place. Iron is not a well-tested project, last commit was several years ago, it is pre-1.0 and lacks any benchmarking setup or tests. So you take somebody's abandoned hobby project, discover it does not work, and claim "it must be the dependencies!". If you bothered to open the issue tracker you would see that the project has been left unfinished years ago. Maybe the real lesson should be that you can find garbage tier abandonware code in any language if you look hard enough? The fact it even compiles at all is a pleasant surprise :) If I mess with the roc compiler and find horrible perf bugs, at the very least I report them rather than publicly shaming your work. And you decided that reporting the bug is above you, but bashing the project on YT is fine. Have you a shred of decency left?
@@icylace no, do not be silly. He should have done his due diligence and not used that abandoned project in the presentation. And if by some miracle he did not notice lack of commits for 5 years, he'd definitely notice the state of the issue tracker while submitting the bug.
@@_garicas which point did I not understand exactly? Also my argument has nothing to with the language. If he did the same with abandoned project in any other language I'd be equally upset. Rust in particular has plenty of issues with complexity management and dependency hell. And one can take any well-tested and maintained web server and demonstrate the same sort of issues by just browsing the open issues.
I'm quite disappointed that he didn't investigate the slow rust code. Exactly 5s smells like a timeout, so potentially nothing to do with abstraction layers. But i guess we'll never know now.
His point wasnt that the implementation is slow but rather that there obviously is a big bug somewhere but locating it is made difficult by the ammount of code/layers of abstraction. That is the argument is not "layers if abstraction => slow" but "the more code you have the more things can go wrong" which seems like a reasonable take.
The rust project he took has been unmaintained for 5 years. The fact it works at all is a miracle.
Performance is just like traffic! The most effective solution to getting to your destination in the least amount of time isn't to increase your maximum speed, but to reduce the amount of time you're moving slower.
Amazing talk!!! Always a pleasure to listen to Richard
Two 5s response times scream of timeout (a wrong error handling + retry loop I guess) rather than a slow path.
One of the more relevant reasons for dylibs today is that the OS maintainer can patch multiple programs at once by updating a single dylib. With a static binary, each application maintainer needs to release a patch, which may take a long time or possibly never happen.
An amazing thoughtful talk on the principles behind the scene.
all the talks have been great. highest density of quality
Talks about lovable programs and zed in the same talk. 1) Zed trying to force AI assistants on you. 2) only way to change settings is in settings.json. 3) default theme is unreadable.
Great talk. The bit about Rust was very weak.
why so? The point of it was that there could be many layers of abstractions that can pose a performance ceiling even in lower-level languages and it managed to convey that quite well
@@javierflores09because people make rust their identity & get offended easily
The half baked example with rust abandonware webserver was really out of place. Iron is not a well-tested project, last commit was several years ago, it is pre-1.0 and lacks any benchmarking setup or tests. So you take somebody's abandoned hobby project, discover it does not work, and claim "it must be the dependencies!". If you bothered to open the issue tracker you would see that the project has been left unfinished years ago. Maybe the real lesson should be that you can find garbage tier abandonware code in any language if you look hard enough? The fact it even compiles at all is a pleasant surprise :)
If I mess with the roc compiler and find horrible perf bugs, at the very least I report them rather than publicly shaming your work. And you decided that reporting the bug is above you, but bashing the project on YT is fine. Have you a shred of decency left?
Are you saying he should have submitted a bug report to a project that is already abandoned ?
You didn't understand the point and took it personally as if a language were your personality
Totally agree with you Alex. 👍
@@icylace no, do not be silly. He should have done his due diligence and not used that abandoned project in the presentation. And if by some miracle he did not notice lack of commits for 5 years, he'd definitely notice the state of the issue tracker while submitting the bug.
@@_garicas which point did I not understand exactly? Also my argument has nothing to with the language. If he did the same with abandoned project in any other language I'd be equally upset. Rust in particular has plenty of issues with complexity management and dependency hell. And one can take any well-tested and maintained web server and demonstrate the same sort of issues by just browsing the open issues.
Lost me at 60gb of ram. Get a 4 gb lappy like the rest of us and tell us about your resource usage
You talking about 34:23? That's wildly out of context 😂
Imagining the author of that web-server saying "but... but... but... Rust offers ZERO COST abstractions!"