Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.

▲

groundzeros2015 15 hours ago | parent [-]

Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful?

Are people making user facing apps in rust with GUIs?

▲

sebtron 14 hours ago | parent | next [-]

> Are people making user facing apps in rust with uis?

We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser!

At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely appreciate a 16x speedup if possible.

[1] https://github.com/astral-sh/uv

[2]https://github.com/astral-sh/ruff

▲

allreduce 14 hours ago | parent | prev | next [-]

Usually it does not reduce latency but increases throughput.

Multithreading is an invaluable tool when actually using your computer to crunch numbers (scientific computing, rendering, ...).

▲

tcfhgj 15 hours ago | parent | prev [-]

> Are people making user facing apps in rust with GUIs?

yes

▲

groundzeros2015 15 hours ago | parent [-]

got any to share? Should I assume native gui in these these rust performance debates?

▲

tcfhgj 14 hours ago | parent | next [-]

https://system76.com/cosmic

https://helix-editor.com/

https://zed.dev/

▲

groundzeros2015 12 hours ago | parent [-]

What do you think are good use cases for multi threading in these editors?

	▲	steveklabnik 11 hours ago \| parent \| next [-]
		"don't block the ui thread" is a pretty classic aphorism in any language.
	▲	tcfhgj 12 hours ago \| parent \| prev [-]
		search, linting

▲

gf000 14 hours ago | parent | prev | next [-]

Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?

▲

groundzeros2015 12 hours ago | parent [-]

Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are.

To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law).

Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful.

The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.

▲

gf000 12 hours ago | parent [-]

> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.

This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.

	▲	groundzeros2015 12 hours ago \| parent [-]
		And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.

▲

xpe 14 hours ago | parent | prev [-]

You might start with https://github.com/zed-industries/awesome-gpui and https://blog.logrocket.com/state-rust-gui-libraries/