121–130 of 136 posts
Earlier quoted context omitted.
It's not better in every way at all - it is more flexible. I regularly bounce between Go and Rust in different contexts.
Interesting. When would you use Go instead of Rust?
> The problem is that threads just don’t work in practice for massive concurrency. That's an assumption that is repeated very often recently, and measured very rarely. Truth is that they amount of applications for which they don't work is surprisingly low. I'm working at a well known cloud provider, and lots of people would really be suprised which applications at largest scale are working fine with a thread-per-requ…
I agree and this article seems pretty misinformed. Creating and managing threads on Linux is extremely cheap, especially when a lot of them are idle, and a lot of big companies (Google, Facebook, Amazon) have tons of huge C++ applications that have thousands of threads and it's fine. I also think a lot of people who don't work on these problems at these kinds of companies assume that it must be incredibly difficult t…
$ ps -eLf | grep firefox | wc -l
569
$Earlier quoted context omitted.
Async has really taken over anything networking-related because, well, it offers much better scaling and performance. If you're a package author you're going to get more people asking for async than people that don't want it. There is no sane way to make async optional in a library and reuse code.
> There is no sane way to make async optional in a library and reuse code. FWIW, there's an effort to do exactly that, but because it will require language level changes and it is just on the drawing board phase, it will likely be a while before it can be widely used. The "optionality" of `async` while sharing code also applies for `const` and mutability (why do we need `Deref` and `DerefMut`?). Finding a solution th…
Could you link where?
Earlier quoted context omitted.
Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.
Embedded is much less likely to need async in the first place at all.
Earlier quoted context omitted.
Why would you assume that all software is written for servers in datacenters? Rust tends to be used in embedded devices, WASM, and other weird contexts where there might not be as many resources available. If you're writing a CRUD app, sure, do it in PHP and spin up a thread per request.
Embedded is much less likely to need async in the first place at all.
Earlier quoted context omitted.
I'm aware of the history there. I think the decision not to ship a builtin async runtime was probably correct. I also think shipping async syntax sugar and allowing people to build their own custom runtimes is just fine. I just think that the cultural decision in the wider ecosystem to make, practically speaking, everything io related, async is possibly a mistake.
Well I think it happened because a large number of Rust committers, core-devs doubled down on multi-year Rust async effort. What larger ecosystem would take away from this? IMO the message was Async is the future so everyone better hop on this train.
Earlier quoted context omitted.
I'll use an embedded analogy. I'm not as familiar with concurrency on GPOS, but consider this: I have an I/O task that might take long, compared to CPU operations: - Start the task, but don't wait for its result. - Your program continues as normal - When the IO task is complete, its hardware sends an interrupt (at a specific priority) to the CPU. The CPU stops what it's doing (assuming there isn't a higher priority t…
I have no idea what GPOS stands for, but the analogy isn't really necessary. The high level algorithm you describe is basically how async programs work. Glossing over the low level details, you usually implement things in terms of polling. Interrupts and their analogs are far too slow at scale (switching async tasks is in the nanoseconds, these days). The problem is when there is logic downstream of the task that nee…
> you usually implement things in terms of polling
Like a busy loop? If so, this approach is the worst, IMO. When done in an OS you keep your application thread always alive. In an embedded system it drains your battery.
The most common model is that in which an application should be sleeping all the time, and processing external stimulus when required.
> Interrupts and their analogs are far too slow at scale (switching async tasks is in the nanoseconds, these days).
Are you saying that whatever async system (like async Rust) is faster than a HW interrupt?
HW interrupts is what makes your system responsive as it is now. Stopping and jumping to an interrupt handler is hardwired in the silicon. What is faster than that?
I've done some beginner Rust and Go programming (read "the books" on both, written small programs) and I'm wondering which one to spend more time on or try to get a job with in the future. When I see discussions like this one about Rust, I start to worry that it's unnecessarily complicated and difficult to work with and that this will only get worse in the future to the point that it won't be a good fit for many of t…
Async is hard again, taking more months to feel proficient. I've again a suspicion that much of the resistance to async is due to people who have done the first effort to feel comfortable in rust and expect async to fit right in, but it doesn't, because it's hard too.
Threads are also hard, but under rust they better map to existing thread models, so pre-existing skills are useful and so someone skilled in threads and rust will be skilled in threads with rust.
For sure, there are missing pieces of the async world like async traits, but they will come.
Earlier quoted context omitted.
Embedded is much less likely to need async in the first place at all.
cooperative multitasking sounds way more embedded than preemptive...
There's obviously also some projects which just use a bare-metal loop to do everything - that probably counts as cooperative.
Does anyone else get the feeling that we (as a field) are missing something basic about concurrency? Like there's a really elegant solution just around the corner, that has the low overhead of async/await without the complexity. Or otherwise put, the ease of goroutines but without GC. I know it sounds crazy. I recently dove into the area, and was pretty surprised at how many interesting building blocks there are out…
I just want to say there are mountains of research on this, and recent development is exciting, but some of the techniques (like stack switching and moving) are very old. Project Loom is very intriguing because of how it solves the practical problems of introducing old concurrency techniques into existing language implementations that were not designed around them. A lot of this stuff is intriguing from the implement…
Safepoints for garbage collection are somewhat similar, but for preemption one wants to interrupt threads on a timer, rather than before the collector takes over. Despite occurring very frequently (at around 100 _million_ checks per second), the time overhead is only about 2.5% or so, according to a study by Blackburn et al [0]. It appears, I think, that as long as the fast not-interrupting path is fast enough, eliminating safepoints isn't too important.
[0] Stop and Go: Understanding Yieldpoint Behaviour https://users.cecs.anu.edu.au/~steveb/pubs/papers/yieldpoint...>