Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

Commit

Permalink
docs(*): Remove mention of performance benefits
Browse files Browse the repository at this point in the history 
Fixes #26.
  • Loading branch information
@LegNeato
LegNeato committed Sep 12, 2018
1 parent f310bce commit 2203422
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 28 deletions.
16 changes: 2 additions & 14 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,18 +25,6 @@ fn main() {

AWS Lambda does not officially support Rust. To enable using Rust with lambda, great projects such as [`rust-crowbar`](https://github.com/ilianaw/rust-crowbar) and [`serverless-rust`](https://github.com/dobrite/serverless-rust) were created. They leverage Rust's C interoperability to "embed" Rust code into lambda supported language runtimes (in this case Python and Node.js respectively).

While this works, there are some distinct downsides:
This project forgoes embedding and instead leverages lambda's official Go support. With Go, lambda runs a standard Linux binary containing a server and then sends it [`gob`-encoded messages](https://golang.org/pkg/encoding/gob/) via [rpc](https://golang.org/pkg/net/rpc/). This project reimplements all that machinery in Rust, using [`rust-gob`](https://github.com/srijs/rust-gob) for `gob` support and a custom [`tokio`](https://github.com/tokio-rs/tokio) server runtime. Lambda does not care that the Linux binary it runs is written in Rust rather than Go as long as they behave the same.

1. Higher footprint with regards to memory consumption, bundle size, and start-up speed due to the host runtime overhead.
2. Increased monetary cost due to #1.
3. More build complexity.

This project aims to remove all those downsides without adding new ones. It forgoes embedding and instead leverages lambda's official Go support. With Go, lambda runs a standard Linux binary containing a server and then sends it [`gob`-encoded messages](https://golang.org/pkg/encoding/gob/) via [rpc](https://golang.org/pkg/net/rpc/). This project reimplements all that machinery in Rust, using [`rust-gob`](https://github.com/srijs/rust-gob) for `gob` support and a custom [`tokio`](https://github.com/tokio-rs/tokio) server runtime. Lambda does not care that the Linux binary it runs is written in Rust rather than Go as long as they behave the same.

This enables:

1. Lower footprint with regards to memory consumption, bundle size, and start-up speed due to no runtime overhead.
2. Lower monetary cost due to #1.
3. No additional build complexity. Building a binary for lambda is as simple as building a Rust binary locally.

Due to the no-overhead method of adding Rust support, projects deployed to lambda using this runtime should match (and might possibly exceed) the performance of a similar project written in Go.
Due to the no-overhead method of adding Rust support, a project deployed to lambda using this runtime should match (and might possibly exceed) the performance of a similar project written in Go.
16 changes: 2 additions & 14 deletions docs/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,18 +11,6 @@ The Rust on AWS Lambda project consists of multiple crates that make it possible

AWS Lambda does not officially support Rust. To enable using Rust with lambda, great projects such as [`rust-crowbar`](https://github.com/ilianaw/rust-crowbar) and [`serverless-rust`](https://github.com/dobrite/serverless-rust) were created. They leverage Rust's C interoperability to "embed" Rust code into lambda supported language runtimes (in this case Python and Node.js respectively).

While this works, there are some distinct downsides:
This project forgoes embedding and instead leverages lambda's official Go support. With Go, lambda runs a standard Linux binary containing a server and then sends it [`gob`-encoded messages](https://golang.org/pkg/encoding/gob/) via [rpc](https://golang.org/pkg/net/rpc/). This project reimplements all that machinery in Rust, using [`rust-gob`](https://github.com/srijs/rust-gob) for `gob` support and a custom [`tokio`](https://github.com/tokio-rs/tokio) server runtime. Lambda does not care that the Linux binary it runs is written in Rust rather than Go as long as they behave the same.

1. Higher footprint with regards to memory consumption, bundle size, and start-up speed due to the host runtime overhead.
2. Increased monetary cost due to #1.
3. More build complexity.

This project aims to remove all those downsides without adding new ones. It forgoes embedding and instead leverages lambda's official Go support. With Go, lambda runs a standard Linux binary containing a server and then sends it [`gob`-encoded messages](https://golang.org/pkg/encoding/gob/) via [rpc](https://golang.org/pkg/net/rpc/). This project reimplements all that machinery in Rust, using [`rust-gob`](https://github.com/srijs/rust-gob) for `gob` support and a custom [`tokio`](https://github.com/tokio-rs/tokio) server runtime. Lambda does not care that the Linux binary it runs is written in Rust rather than Go as long as they behave the same.

This enables:

1. Lower footprint with regards to memory consumption, bundle size, and start-up speed due to no runtime overhead.
2. Lower monetary cost due to #1.
3. No additional build complexity. Building a binary for lambda is as simple as building a Rust binary locally.

Due to the no-overhead method of adding Rust support, projects deployed to lambda using this runtime should match (and might possibly exceed) the performance of a similar project written in Go.
Due to the no-overhead method of adding Rust support, a project deployed to lambda using this runtime should match (and might possibly exceed) the performance of a similar project written in Go.

0 comments on commit 2203422

Please sign in to comment.