AWS Rust Platform Team

@aws-rust-platform

The Rust Platform Team at Amazon Web Services

Public team

Joined on Apr 1, 2021

  •  Like  Bookmark
  • Program chair Competing w/ c Context RubyConf: 800 people in 2014 $286k income $100k sponsorship
     Like  Bookmark
  • T-compiler Ambitions in 2022 (AWS copy) Editor's note (not part of blog post): Previously considered titles include: T-compiler 2022 roadmap, T-compiler astrological chart, T-compiler horoscope, T-compiler fortune cookies, T-compiler crystal ball. Other suggestions welcome! Editor's note (not part of blog post): Our intent is to post this on the Inside Rust blog in the near future, circa February 18th. You can consider it an early preview; we want feedback from the members of T-compiler and T-compiler-contributors before we circulate it more broadly. You can post comments in the HackMD margin, or send us an email, or write in a Zulip thread. Some people have been wondering about what the Rust Compiler Team has planned for 2022. This note is to let you all know what activities the team plans to focus on this year. This document is structured into three parts: our Overall Themes for this year, the Concrete Initiatives we have resources to drive, and Aspirations for what we could do if given more help. [toc]
     Like  Bookmark
  • Step 1: Download the console The tokio-console isn't available via crates.io (yet). So you will need to download its source code. You can find it on github, here: https://github.com/tokio-rs/console % git clone git@github.com:tokio-rs/console.git console % cd console console% We will be tracking a specific "preview" branch of the console where we can make changes and adapt to your needs as we discover them. So after you download the console repository, make sure to check out the preview branch: console% git checkout preview
     Like  Bookmark
  • Hypothesis: Rust is "hard to learn" because experimenting is hard. Getting code to work requires a lot of thinking and "in-head" design. There are also many concepts needed to get started. People ask to "disable the borrow checker". What if we can create an EZ rust mode that is used to introduce users to Rust. It is a slightly different language, but is compatible with Rust itself. EZ mode is enabled / disabled at the crate level but ez-mode crates can call non-ez-mode crates and vice versa. Ez-mode is primarily focused on app-developers (CLI, net services, etc...). Ez-mode will not be zero-cost and will come with some runtime. Ez-mode will not use a GC as GCs are quite intrusive. Infrastructure libraries (e.g. Tokio, Hyper, ...) will still be implemented in Rust for performance. The idea is that the application layer business logic is more "scripting" and can have some level of runtime overhead without a measurable total performance impact.
     Like 1 Bookmark
  • The current Console allows a nice live view of the application that it is monitoring. But sometimes things happen quickly, and a user may not have been able to react to inspect the data they wanted. In such scenarios, the user wants to be able to go back in time: replay the Console those events again, with controls to pause, step forward or backward, and more. We envision a rich temporal feature set, but present it here in stages. Each stage builds new functionality on top of the previous stage. We expect to launch with pausing, recording, and replaying. The post launch features described here are also desired by customers, but are not planned as part of the initial launch. (Want to help add them? Come join us!). Launch Deliverables (2021) Pause Command Sometimes while watching the tasks play live, a user notices something out of the ordinary, and wants to select that task, and investigate its details. But with a live view, the task state will change, which may disrupt a user's attempt to interpret the output. Worse still, a single task's entry in the table of tasks competes with all the other tasks updating and adjusting relative orders in the table.
     Like  Bookmark
  • A sketch of the work needed to actually build the Console. This will break down everything into issues that will eventually get made on the issue tracker. Console App Views State Tests What the best way to even test TUI apps?
     Like  Bookmark
  • TurboWish Development Plan: The Async Monitor and Console TurboWish Overview TurboWish is a suite of tools that give Rust developers insight into performance issues in their code. The first TurboWish deliverable is the Async Monitor and Console, which answers a developer's questions about how their code's async runtime is behaving as their program runs. The Async Console provides a summary of an async runtime's behavior, using concepts shared across the async rust ecosystem (such as tasks and resources), and metrics that are applicable to any async program (such as the average time each task spends waiting in a ready state). When a developer asks: "Why is my task stuck?" or "Why is my app slow?", the Async Console is the first, and in some cases, the only tool they need to reach for. It will allow the developer to quickly see how tasks are scheduled (to learn how much time is spent in the developer's own code versus waiting to run), identify tasks that are starving or blocked and what resources they are waiting on, and identify tasks responsible for replenishing a scarce resource.
     Like 1 Bookmark
  • This tool is intended to be run locally during debugging and/or benchmarks. Shiny future All stories start with the developer enabling tokio-console in their application then opening the tokio-console terminal UI. #[tokio::main] async fn main() { tokio_console::init(); // Rest of the app
     Like  Bookmark
  • Milestone Subtask Owner Deadline Status 3 to 5 User Stories pnkfelix 26 feb 2021
     Like  Bookmark
  • Profile Production Code: Incorporating the TurboWish Framework is low-overhead: it can be incorporated into production code without producing an undue maintenance burden and without incurring significant performance overhead. Domain-specific Feedback: Frameworks and applications can provide data for specialized metrics, specific to their internal architecture. Understand Hidden Costs and Connections: Frameworks like tokio ease writing asynchronous code because they hide a number of details behind abstractions (such as generator code produced by the Rust compiler, or task queues managed by the tokio runtime). TurboWish exposes those hidden details, allowing developers to correlate them with other program events. It also exposes connections that humans usually have to reconstruct by hand (such as future to resource to future chains that can yield deadlock), allowing one to directly see from Rust’s ownership model how resources are being held in the object graph. Framework Agnostic: Many of Rust’s customers use tokio, but not all of them. async-std and fuschia_async are other frameworks for asynchronous programming. TurboWish can provide value to any such framework (though it may also provide framework-specific functionality when warranted). For our initial releases, we can focus on tokio alone, but expect integration with others if use with tokio proves successful. EC2 Instance Type Agnostic: If we make use of any OS specific features (e.g. dtrace probes), they will be available on all EC2 AL2 instances, regardless of instance-type. (Specifically, we cannot require access to CPU performance counters for core functionality. We may offer extra features that utilize them.)
     Like  Bookmark
  • What this covers A description of the TurboWish software architecture, where the pieces have been selected in a way to best take advantage of different skill sets across our team. What this does not currently cover There's no schedule outlined here for when the different components will be delivered. I want to discuss the architecture with the team first, before trying to spell out how we get to a finished product using this architecture. The TurboWish vision TurboWish gives our team's customers (namely, Rust developers) insight into what their programs are doing, in order to identify performance pitfalls. The most immediate insight we seek to provide: Tools to answer the question "Why aren't my asynchronous tasks being scheduled in the manner I expect."
     Like  Bookmark
  • So far, this is collecting the various strategies for including metadata, such as for tracing, when spawning a new task in Tokio. status-quo future.instrument() A user can currently manually create a tracing Span, and instrument any future before calling tokio::spawn. Something like: let span = tracing::debug_span("yolo"); let future = async { yeet().await; };
     Like  Bookmark