6 ms·

"The top three challenging areas of Rust for current Google developers were: * Macros * Ownership and borrowing * Async programming " Async programming

"The top three challenging areas of Rust for current Google developers were: * Macros * Ownership and borrowing * Async programming " Async programming is the area I would like to see the most improvement, especially in the standard library. So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developers prefer. It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has: https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...

VWWHFSfQ 3y ago
rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now
- steveklabnik 3y ago
  That is never going to happen, for both good reasons and bad reasons.
  - VWWHFSfQ 3y ago
    Yeah I figured. Fragmentation by design.
    - steveklabnik 3y ago
      One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."
- estebank 3y ago
  The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
- Animats 3y ago
  I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.
  - arijun 3y ago
    Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
    - Animats 3y ago
      "Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable. It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
      - flylikeabanana 3y ago
        Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?
        Animats 3y ago
        Correct. I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model. This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
- sanxiyn 3y ago
  Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.
  - jenadine 3y ago
    There can be both a "blessed" executor, while staying optional for such cases. For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.
mjhay 3y ago
> Async programming is the area I would like to see the most improvement, especially in the standard library. > So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developers prefer. This seems to be an repeated antipattern with a lot of languages/ecosystems, resulting in fragmented and half-baked solutions. A fully-featured async standard library involves making a lot of opinion-based decisions, and not everyone will be happy. But it's better for 80% of people who probably don't care that much, and nothing stops the other 20% from implementing libraries for their use-cases.
- pie_flavor 3y ago
  As news of Rust's decisions several years ago reaches people only now, it is fun to watch people make predictions about 'the future' that have not been borne out in reality one smidgen. Just using the library everyone else uses has also worked for 80% of people that don't care that much.
jimbob45 3y ago
Is there any Rust outfit out there that doesn't discourage macro use? For that matter, is there any team with a language out there that encourages macro use when working as a team?
- rockemsockem 3y ago
  So far I've only written rust on solo projects, why is macro use often discouraged? Does that discouragement extend to little things like derive?
- giraffe_lady 3y ago
  I've never seen a team that encouraged writing new macros to solve routine problems. But I've certainly been on teams that made heavy use of a few carefully deployed macros to solve recurring problems specific to that codebase. I think elixir's sigils are probably the closest thing I've seen to "routine, encouraged macro use." Since almost every application will end up with a bit of template lite almost-dsl pseudo language for something or other. They're simpler than defining a grammar & writing a parser and more maintainable than regex.
  - 59nadir 3y ago
    I think Elixir is a bad example here because it's one of the eco systems that, while they preach "Use a function if you can!" very loudly, use macros much more heavily than other eco systems, often in places where they don't have to. Phoenix, the (unfortunate) flagship library, abuses macros all over the place where even relative beginners can see that they didn't need to (see [0] for example). It's incredibly badly designed overall and these things have set the tone (especially since a lot of Elixir programmers are in reality just Phoenix programmers). So, while macros are "discouraged" in Elixir, in practice they are very much encouraged by several prominent libraries. Picking on Phoenix is very easy because it's so blatantly bad in this regard (and others) but it's almost impossible to do useful things with Ecto if you go outside the macro bubble, etc., as well. Example that shows how an eco system that definitely could have done stuff with macros (Clojure) has correctly decided that writing functions that take data is better than using macros: Elixir and `Plug.Router`: defmodule MyRouter do use Plug.Router plug :match plug :dispatch get "/hello" do send_resp(conn, 200, "world") end forward "/users", to: UsersRouter match _ do send_resp(conn, 404, "oops") end end Clojure and `reitit` (https://github.com/metosin/reitit https://github.com/metosin/reitit): (def router (r/routes [["/hello" {:get (fn [r] {:status 200 :body "world"})}] ["/users" {:name :users :router users-router}] ["*" {:get (fn [r] {:status 404 :body "oops"})}]])) P.S. I've used Elixir since 2015, this is not an opinion I've developed at a glance.
no_wizard 3y ago
Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines. The path Rust is going means async becomes viral, and is something I dislike a lot about JavaScript[0] and other languages I’ve worked in[1]. I’d love to see Rust avoid this trap. [0]: I work in TypeScript in actuality not sure which to use here. It’s certainly by far the language I’ve used the most in my career now. [1]: I remember it infected Python too and it was a pain as well when I did Python development years ago.
- steveklabnik 3y ago
  Do you have a way to accomplish this while still staying within the other various constraints that Rust's async is under? I don't believe it is reconcilable. For those not aware of the history and looking for background, I laid it out here: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/ and here https://www.infoq.com/presentations/rust-async-await/ https://www.infoq.com/presentations/rust-async-await/ Those style systems are useful and have advantages, but they also have disadvantages. Not every tradeoff is a good call for every system, and that goes both ways in this scenario.
  - no_wizard 3y ago
    Make it an optional crate like `no-std` is, where you specify it in your cargo.toml
- shadowgovt 3y ago
  At this time, I believe Rust's approach is complicated but that's because correctly using "bare" threads is complicated. Goroutines simplify the problem but introduce runtime performance overhead that may not be suitable for applications Rust is used for. (Generally, I avoid this problem these days by avoiding threads in favor of other abstractions or multiple processes communicating over an RPC channel).
- shellac 3y ago
  For many languages I absolutely agree: stackful coroutines are the way to go since the programmer experience is much smoother, with fewer hiccups like having different kinds of functions, or being unable to yield in loops. Lua, Go, and now Java got this right; python, javascript, and c# have to live with a bit of a mess. But Rust is not a language which can dictate its execution environment. It needs to be able to exist in a C-ish world, and that's not something that supports yielding. It's a shame, but at least you can write kernel modules in Rust.

VWWHFSfQ 3y ago

rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now

steveklabnik 3y ago
That is never going to happen, for both good reasons and bad reasons.
- VWWHFSfQ 3y ago
  Yeah I figured. Fragmentation by design.
  - steveklabnik 3y ago
    One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."
estebank 3y ago
The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
Animats 3y ago
I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.
- arijun 3y ago
  Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
  - Animats 3y ago
    "Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable. It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
    - flylikeabanana 3y ago
      Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?
      - Animats 3y ago
        Correct. I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model. This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
sanxiyn 3y ago
Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.
- jenadine 3y ago
  There can be both a "blessed" executor, while staying optional for such cases. For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.

mjhay 3y ago

> Async programming is the area I would like to see the most improvement, especially in the standard library. > So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developers prefer. This seems to be an repeated antipattern with a lot of languages/ecosystems, resulting in fragmented and half-baked solutions. A fully-featured async standard library involves making a lot of opinion-based decisions, and not everyone will be happy. But it's better for 80% of people who probably don't care that much, and nothing stops the other 20% from implementing libraries for their use-cases.

pie_flavor 3y ago
As news of Rust's decisions several years ago reaches people only now, it is fun to watch people make predictions about 'the future' that have not been borne out in reality one smidgen. Just using the library everyone else uses has also worked for 80% of people that don't care that much.

jimbob45 3y ago

Is there any Rust outfit out there that doesn't discourage macro use? For that matter, is there any team with a language out there that encourages macro use when working as a team?

rockemsockem 3y ago
So far I've only written rust on solo projects, why is macro use often discouraged? Does that discouragement extend to little things like derive?
giraffe_lady 3y ago
I've never seen a team that encouraged writing new macros to solve routine problems. But I've certainly been on teams that made heavy use of a few carefully deployed macros to solve recurring problems specific to that codebase. I think elixir's sigils are probably the closest thing I've seen to "routine, encouraged macro use." Since almost every application will end up with a bit of template lite almost-dsl pseudo language for something or other. They're simpler than defining a grammar & writing a parser and more maintainable than regex.
- 59nadir 3y ago
  I think Elixir is a bad example here because it's one of the eco systems that, while they preach "Use a function if you can!" very loudly, use macros much more heavily than other eco systems, often in places where they don't have to. Phoenix, the (unfortunate) flagship library, abuses macros all over the place where even relative beginners can see that they didn't need to (see [0] for example). It's incredibly badly designed overall and these things have set the tone (especially since a lot of Elixir programmers are in reality just Phoenix programmers). So, while macros are "discouraged" in Elixir, in practice they are very much encouraged by several prominent libraries. Picking on Phoenix is very easy because it's so blatantly bad in this regard (and others) but it's almost impossible to do useful things with Ecto if you go outside the macro bubble, etc., as well. Example that shows how an eco system that definitely could have done stuff with macros (Clojure) has correctly decided that writing functions that take data is better than using macros: Elixir and `Plug.Router`: defmodule MyRouter do use Plug.Router plug :match plug :dispatch get "/hello" do send_resp(conn, 200, "world") end forward "/users", to: UsersRouter match _ do send_resp(conn, 404, "oops") end end Clojure and `reitit` (https://github.com/metosin/reitit https://github.com/metosin/reitit): (def router (r/routes [["/hello" {:get (fn [r] {:status 200 :body "world"})}] ["/users" {:name :users :router users-router}] ["*" {:get (fn [r] {:status 404 :body "oops"})}]])) P.S. I've used Elixir since 2015, this is not an opinion I've developed at a glance.

no_wizard 3y ago

Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines. The path Rust is going means async becomes viral, and is something I dislike a lot about JavaScript[0] and other languages I’ve worked in[1]. I’d love to see Rust avoid this trap. [0]: I work in TypeScript in actuality not sure which to use here. It’s certainly by far the language I’ve used the most in my career now. [1]: I remember it infected Python too and it was a pain as well when I did Python development years ago.

steveklabnik 3y ago
Do you have a way to accomplish this while still staying within the other various constraints that Rust's async is under? I don't believe it is reconcilable. For those not aware of the history and looking for background, I laid it out here: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/ and here https://www.infoq.com/presentations/rust-async-await/ https://www.infoq.com/presentations/rust-async-await/ Those style systems are useful and have advantages, but they also have disadvantages. Not every tradeoff is a good call for every system, and that goes both ways in this scenario.
- no_wizard 3y ago
  Make it an optional crate like `no-std` is, where you specify it in your cargo.toml
shadowgovt 3y ago
At this time, I believe Rust's approach is complicated but that's because correctly using "bare" threads is complicated. Goroutines simplify the problem but introduce runtime performance overhead that may not be suitable for applications Rust is used for. (Generally, I avoid this problem these days by avoiding threads in favor of other abstractions or multiple processes communicating over an RPC channel).
shellac 3y ago
For many languages I absolutely agree: stackful coroutines are the way to go since the programmer experience is much smoother, with fewer hiccups like having different kinds of functions, or being unable to yield in loops. Lua, Go, and now Java got this right; python, javascript, and c# have to live with a bit of a mess. But Rust is not a language which can dictate its execution environment. It needs to be able to exist in a C-ish world, and that's not something that supports yielding. It's a shame, but at least you can write kernel modules in Rust.