It sounds like they're talking about HTTP requests/responses, then that sounds mostly like just networking overhead, and it wouldn't matter if it was JS/Go/Rust or C++, network latency would be there anyways. And if that's with network latency excluded, just hitting localhost, then that sounds horrible, should easily be below 1ms unless you're doing something heavy, but sounds like a typical application with no such actions.
The data viz of the benchmarks is really rough. I think you’d get a lot of leverage out of rebuilding it and using colors and/or shapes to extract additional dimensions. Nobody wants to scan through raw file paths as labels to try and figure out what the hell the results are
Neat idea but you could build this with a fraction of the complexity by ditching sqlite and duckdb for your native file system and rg/grep/gawk with equivalent performance
grep with equivalent performance? i highly doubt that. my mailbox has 2.6M emails: running grep through millions of files if you use maildir or a similar format takes forever. likewise running grep on a 7.6GB large mbox file takes more than a minute.
on the other hand in supmua (which inspired notmuch) the same search takes seconds.
Some Rust proponents, but certainly it's obvious not all of them, or not even a meaningful majority.
Which is to say this despicable act has absolutely no bearing on the language and its ecosystem, so bringing it up is irrelevant, and therefore those downplaying it are not necessarily in favor of the act.
Rust + Axum + SQLx has been a total game-changer for me in terms of productivity developing web-based Postgres apps. I like the tooling and the libraries are great.
Looks really cool, will definitely be trying it out. Do you have any screenshares or demo midi you can share? And is there any way to use a text based notation rather than a piano roll?
Rust is not the reason you have sub-100ms response times. If it were the true bottleneck your app would be far faster than this
reply