confusion specific to JavaScript

[nikomatsakis]

Brief summary

Alan is accustomed to JavaScript promises. He has design patterns in mind that don't work in Rust; he also gets confused by specific things around Rust futures. What are they?

Optional details

• (Optional) Which character(s) would be the best fit and why?
  • Alan: the experienced "GC'd language" developer, new to Rust
  • Grace: the systems programming expert, new to Rust
  • Niklaus: new programmer from an unconventional background
  • Barbara: the experienced Rust developer

[nikomatsakis]

Possible example: when you call an async function in JS, it begins executing immediately, and executes concurrently, whereas Rust futures are lazy.

[yoshuawuyts]

Some other topics that might be worth covering here:

• The difference between Node.js streams and Rust's streaming interfaces. (Main points to cover I see here are: backpressure, defining "through streams", consuming "readable streams", piping streams together, and error propagation)
• JavaScript comes with a runtime included, while Rust does not. This means even absolute beginners need to learn what a runtime is, learn about the options, and then proceed to pick one before they write their first line of code.
• In Node.js tracing interfaces "just work" for the most part — before this was done by monkey-patching built-ins, but now using the async_hooks API. Rust on the contrary does not provide a stable tracing API out of the box, and does not allow for monkey-patching. This means the experience is different for both tracing providers and consumers.
• Node.js comes with HTTP/HTTPS built-in, Rust does not. There are multiple HTTP stacks defined in userland, with different tradeoffs and interop guarantees.
• Maybe a fun one, but validating JSON in Rust is surprisingly easy and efficient. This is a big part of what web apps do, and maybe a chance to write a story about something that may delight users coming from other languages.

[vladinator1000]

Hi y'all! ❤️ Coming from JS here are some things that made an impression to me as a beginner.

Runtimes

🔁 I didn't know how to imagine what a runtime until someone said it's like a glorified while loop and that the special macro re-writes my code into something else.

Errors

⛔️ Handling errors in Tide was weird, for example if I wanted to upload an audio file, I'd have to do some parsing and writing to the filesystem. Usually I'd slap a question mark at the end of each function that returns a result, but when I wanted to turn those into meaningful errors I got confused. I still don't know how to properly do error handling so I use dyn Error result types everywhere if many errors can happen in a function 😬. Although the compiler catches so many things that I rarely need a debugger so there's that.

References and ownership

These took the longest to figure out. My dad and I have been coding an audio player server for fun every Saturday (🥳) for a while and it tripped us up when we wanted to do ƒancy hot-reloading. It was very rewarding to learn that you can shoo off the borrow-checker by lighting a candle and burning some incence in front of a portrait of Esteban, or just using .clone() everywhere. Oh, and passing closures around is really hard.

Love these

• Serialization and deserialization in Rust is so beautiful, I never wanna deal with parsing strings again.
• The .await at the end is super ergonomic, I love it so much
• Not having to wrap stuff in try/catch is excellent

[broccolihighkicks]

Some things that I would like to be improved in Rust, that I find useful in JS:

• Combinators

  • Promise.all, Promise.join, Promise.allSettled
  • Using use futures::join; join!(a(), b(), c()), my IDE (IntelliJ) has no idea what is inside of the macro brackets so there is no instant type checking.

• Pin'ing promises

  • Why do I need to pin a promise?
  • How can I store an array of promises and move them around?

• Async closures

  • Can I define a closure that is async?

• How do promises interact with threads?

  • In JS, I am used to relying on "when my code is running, it is the only thing mutating state".
    • With Rust, it requires a bit of research to understand if/when promises move to other threads. The compiler ensures a single writer, but I do not want to add extra cross-thread locking mechanisms for things that can be on the same thread.
    • Sometimes I want to move expensive work to a background thread and then return the result to a main event loop.

• Async iterables (for await of)

  • https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of
  • This is very useful for creating iterators over paginated API results.

• A standard runtime that will be supported long into the future.

  • I often get the impression I am building my code on runtime libraries that will change in a few months. I want my code to last forever.

[jlkiri]

There's a subtle difference in JS between returning Promises or awaiting them before returning. Suppose createPromise creates some Promise:

async function returnSomething() {
  return createPromise();
}

async function returnSomething() {
  return await createPromise();
}

The two snippets lead to different results. This article explains the difference in detail. It can be very confusing even for experienced JS devs. Rust works differently, which can bring even more confusion. For example, the code below panics because I don't .await return_number() inside return_call_async function.

use futures::executor::block_on;

async fn return_async_1() -> usize {
    return 1;
}

async fn return_call_async() -> usize {
    // return return_number().await;
    return return_number();
}

fn main() {
    let s = block_on(return_call_async());
    print!("{}", &s);
}

The provided error message is very uninformative and could be improved (e.g. explain why I can't do it this way? Is it possible by returning some other type? Should I return impl Future or something like that? Is returning usize from return_call_async correct? ).

error[E0308]: mismatched types
 --> src/main.rs:8:12
  |
3 | async fn return_number() -> usize {
  |                             ----- the `Output` of this `async fn`'s found opaque type
...
8 |     return return_number();
  |            ^^^^^^^^^^^^^^^ expected `usize`, found opaque type
  |
  = note:     expected type `usize`
          found opaque type `impl futures::Future`
help: consider `await`ing on the `Future`
  |
8 |     return return_number().await;
  |                           ^^^^^^

error: aborting due to previous error

[laurieontech]

When learning Rust a lot of emphasis is, rightly, placed on ownership/references and mutability. However, there are some marked differences in data types that are easily missed.

The various integer types/sizes is one.

The other is vectors versus arrays. It's all too easy to assume arrays are what you want because of the JS name similarity.

[evan-brass]

Cancellation:

In JavaScript, cancellation is handled with AbortControllers + AbortSignals. In Rust it is handled by not calling poll and the Drop trait. In JavaScript some APIs don't take an abort signal and you end up needing to wrap them: https://gist.github.com/jakearchibald/070c108c65e6db14db43d90d1c3a0305 In Rust, all Futures can be cancelled. In JavaScript cancellation is propagated via exception from bottom to top (by bubbling exception) instead of being propagated from top to bottom (by futures dropping their children) as it is in Rust.

Maybe it would help JavaScript users to have examples that show converting cancellation patterns in JS into Rust.

async function do_the_thing(data, signal) {
    const thing = create_a_thing(data);
    try {
        const res = await use_thing(thing, signal);
        return res + 2;
    } finally {
        thing.cleanup_the_thing();
    }
}

[jbr]

I think a lot of people coming from js look for Promise.all/Promise.allSettled/Bluebird.map(…, { concurrency: …}). It took me quite a while to realize that I needed to make a Vec<Future> into a stream, and even longer to find FuturesUnordered/BufferUnordered, and even then they're more awkward than I expected. The join/select macros are a confusing distraction for a lot of people, myself included.

Here was my thrashing attempt at understanding how to make outbound http requests with bounded concurrency: https://twitter.com/jacobrothstein/status/1212892911546683394, and critically for this wg, I ended up giving up on async and instead used rayon for this project: https://twitter.com/jacobrothstein/status/1213248527079313414

A little analysis: The futures crate has a lot of good ideas, but also some less-than-useful ones, and very few of them are documented in a didactic/tutorial manner, and the naming could stand to be improved for discoverability. There's no "so you want to iterate over this Vec<Future>/IntoIter<Item=Future>> in the order they resolve? Try FuturesUnordered. Want to bound the concurrency of that task? Try BufferUnordered. Want to do some stuff with streams? You'll need to pull in StreamExt. You don't need to do this with Iterator because it's in the std prelude."

Async-std and tokio have different approaches than those in futures, and it's not obvious why/when you need to reach for the futures crate (or, even more confusingly, futures-util / futures-lite, which also have differences). It's especially not obvious that a vec of futures needs to be turned into a stream in order to do async stuff with it, since in javascript there are lots of apis that operate on an array of promises without making it into a special thing. I'm much more familiar with async-std than tokio, but I don't believe async-std currently has any equivalent for FuturesUnordered or BufferUnordered, which leads people to try other solutions that don't work as well, like trying to fold a vec of futures into one giant join-ed or race-ed future

[y21]

Some things that I was struggling to understand after working with JavaScript for a long time:

• Sharing values: in JS, it's all a single thread, so sharing values just works. There's this smart event loop that makes it possible to have multiple "tasks" run concurrently on a single thread. No Mutex, RwLock, Arc etc. required like in async Rust. No need to worry about something not being Send or Sync.
• Laziness: Polling futures is required for something to happen. Calling an async function and not handling the returned future properly doesn't drive the future to completion. Nothing happens. async code in JavaScript just runs.
• Syntax: what's the difference between || async {} and async || {}? Why are async closures unstable, but moving the async keyword to the right side magically works?
• Pinning: Box<dyn Fn() -> Pin<Box<dyn Future<Output = ()>>>>?! Why is Pin needed when working with futures? What problem does it solve? Why do I need it, and sometimes I don't?
• Async traits: why can't my trait function be async?
• Blocking: Why is it fine and often preferred to use std::sync::Mutex over, say tokio::sync::Mutex? Blocking code should be avoided at all costs, so why is it fine to use std's Mutex?

[rhmoller]

This sums it up for me: https://github.com/rhmoller/blobs-and-bullets/blob/master/src/engine/image_future.rs

I just wanted to do the equivalent to this.

const loadImage = src => new Promise((resolve, reject) => {
  const img = new Image();
  img.onload = resolve;
  img.onerror = reject;
 img.src = src;
})

It took me forever to figure out. And now that I look at it a year later I can't remember how it works. (I haven't been writing Rust since)

[rhmoller]

BTW the above is not to dunk on Rust. I overall like the language and would like to pick it up again sometime.