[toyg]

Part of the reason your Slack is so slow is that a lot of stuff is built to protect from problems that Rust might eventually solve.

Slack builds the UI on web technology that got widespread in part because it solves awkward problems with deployment (self-contained and consistent graphic libraries, so you don’t have to worry about how your DE compiled this or that other toolkit) and safety (web tech is heavily sandboxed so that crashes and executions won’t open doors to bad actor). In the long run, Rust will definitely make the latter less cumbersome (less worrying about crashes -> simpler, lighter, faster sandboxes) and possibly help with the former a bit (desktop environments and their libraries could shed some complexity when moving to Rust and make it easier for programs to access them safely).

I think it’s a noticeable step forward. Will it solve everything? No, some of the problems with Slack-like situations are due to economic factors (browsers sticking to JS will forever continue to make JS programmers cheaper and more plentiful than basically any other type of programmer) that Rust is unlikely to affect. But perfect is the enemy of good in this sort of thing: incremental progress is better than no progress.

[skohan]

But I think Rust is also quite vulnerable to the layering problem the previous commenter is speaking about. One of the best things about Rust is how easy Cargo makes it to include 3rd party code in a project, but this is also one of Rust's biggest risks. It's already common for Rust projects to have massive lists of dependency, and that's something which generally gets worse as time goes on rather than better.

Rust as a language may have favorable properties with respect to speed and safety, but programs which run on top of a massive tree of third party code which has been written by god-knows-who tend not to be very fast or very secure.

NPM has already shown that dependencies can be used as an attack vector, and unless Rust can solve this problem, I don't think it's going to bring us some brave new world where we don't have to sandbox anymore.

[nindalf]

> programs which run on top of a massive tree of third party code which has been written by god-knows-who tend not to be very fast or very secure.

You have a point about security, but not about the speed. I can probably link 5 "we rewrote in Rust and it was much faster" articles. All of these used third party libraries. ripgrep for example, is faster than grep, despite having more dependencies. In reality, it just promotes better code reuse without impacting run time speed. If anything, separating your code into crates improves incremental compilation times.

It's possible that you might pull in a large dependency with many features. Compiling all of this and removing the unused code will cause a compile time penalty and no run time penalty. In practice, Rust crates that expose multiple features have a way to opt-out/opt-in to exactly what you need. No penalty at all. In any case, most rust crates err towards being small and doing one thing well.

Examples

- https://blog.mozilla.org/nnethercote/2020/04/15/better-stack...

- https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

[skohan]

I agree that Rust has very favorable characteristics when it comes to performance. My argument would be that language choice is not a panacea. It's certainly possible to write performant code which leans on dependencies, but the style of development which relies heavily on piecing together 3rd party libraries and frameworks without knowledge of their implementation details is not a recipe for optimal performance.