staticassert

https://slides.com/colinwa/grapl-a#/

​

I gave this talk to a group at Dropbox. The slides have a bit of comments, but to provide a tldr for the general direction...:

• I have been building web services on AWS, in rust, for about a year
• Rust felt like a natural fit - fast, safe, stable
• I worried about the ecosystem
• The ecosystem is awesome, and has grown a ton in the last year
• A year later I am glad I chose rust, and I feel that it's entirely ready for this sort of work

https://github.com/insanitybit/grapl

​

Thought this might be interesting, as it's a rust project.

​

Of note - I developed this on AWS Lambda, which is *not* a supported platform for rust. It was actually not that hard to get working, thanks to this project: r/https://github.com/srijs/rust-aws-lambda and the ability to statically link rust with the `rust-musl-builder` project.

​

The code is *rough*. The project, at one point, was architected very differently, and built for different purposes.

​

Hopefully I can find time to write about my experience writing Rust for web services. I went through a

https://blogs.dropbox.com/tech/2018/06/extending-magic-pocket-innovation-with-the-first-petabyte-scale-smr-drive-deployment/

Moving from Go to Rust also allowed us to handle more disks, and larger disks, without increased CPU and Memory costs by being able to directly control memory allocation and garbage collection. Check our presentation on how we used Rust to optimize storage at Dropbox to learn more.

I have two crates

fundamental-ds exposing-service

fundamental-ds is just some types. exposing-service takes those types and uses them in its grpc interface.

Because these are separate crates I can't have the rpc proto in exposing-service reference the one in fundamental-ds (because import statements are paths, and these things exist separately).

So how do people handle this?

One solution I have started writing is to have a separate 'proto' crate, where all proto definitions go. The problem then is that I can't write my impl code for the proto definitions in other crates... so now I'm writing this ridiculously massive crate where all proto definitions and their impl's g

https://play.rust-lang.org/?gist=4ede91865b16e1993862a99df91607e2&version=stable

I know I'm doing something wrong here. My client creates its own core so that I can just block when I make requests.

I don't see how to just return futures without exposing implementation details - I'm trying to write a high level, encapsulated client.

I think maybe the answer is to impl Future for my client, and then lift the Core out of it. But I don't want 'and_then' and things like that, I want 'get_file' etc.

This code is, I think, functional. But it feels incorrect.

I found mutpy but it appears to be 3.x only.

My service is 2.x only.

Is there a stable, high quality mutation testing library that'll work on 2.x?

https://insanitybit.github.io/2017/10/09/more-rust-actors

I have a lot of free time right now before my new job starts. I've spent a fair amount of it trying to use my derive_actor macro in a 'realish' project, see where it's weak, etc.

I've outlined some of these changes and patterns and I'd be curious to hear what you think.

Google seems to be looking at it for Fuschia, I believe BSD provides it through capsicum, which I read about years ago but never hear about any more.

Are there good conference talks or papers around it that I can use to get a deeper understanding of how it's implemented, enforced, etc?

I've written some very basic interpreter code in rust, but I was handwriting the lexer/ parser. That was valuable as a first pass, but I'd like to actually write the interpreter in a way where it's easier to iterate on features.

I've seen LALRPOP as one option, and I've used nom before as well for other tasks.

Wondering what others think would be a good choice.

I've watched Propositions as Types a few times (https://www.youtube.com/watch?v=IOiZatlZtGU) and I find the beginning, the discussion of Turing, Church, and Geodel to me really interesting (the whole talk is awesome though).

Are there any online courses that would go further into this? I'd love to hear more about the evolution of the field, seminal papers/ research, the 'discovery' of CS.

https://github.com/insanitybit/sqs-service-helper

And an example using it here:

https://github.com/insanitybit/queue-delay-app

This is still a work in progress, I break it daily

The readme has details, the tldr is that this lets you write services that consume from SQS. It will keep the SQS messages invisible on the queue, it will delete the messages for you (or not, if you failed to process them), etc.

It will automatically scale consumer threads up if the system can handle it - right now what that means is that if we can keep more messages in flight before the visibility updaters fall behind, we increase consumers. It does not take the processor into account - there is a hard cap of

I'm looking to get behavior similar to this:

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html

Basically I want to submit tasks like "Run this code in 5 seconds" and "Run this code in 10 seconds" and itll execute the first 5 seconds later, and the second 5 seconds after that.

Every submission would return a 'handle' that can be used to cancel the event.

I think this should be possible with futures. I talked briefly with someone in the tokio gitter and they mentioned something like this:

stream.and_then(move |d| Timeout::new(d, &handle).unwrap()).map(|()| make_message()).forward(sink)

but with a buffered input for parallel processing. T

Hey, I have two separate questions.

• I want to run all of my tests, one after the other, with sanitizers enabled (one test run with each).

• When I run cargo fuzz I get this error:

  error: the linked panic runtime panic_unwind is not compiled with this crate's panic strategy abort

I searched in the issues and didn't find anything.

I'm trying to design a data structure that allows me to do these operations efficiently:

1. Remove the oldest value when inserting a new value
2. Calculate the median value

The data structure will always have 'n' values in it, from an outsider's perspective.

Removals and insertions always happen at the same time, so they are used equally often. After every insertion there is always a recalculation of the median.

So let's say you have 1 insertion, 1 deletion, and 1 calculation of median. There will be 1 additional calculation of median elsewhere in the code. So it ends up being that, for one full "processing" of data there is:

1 insertion

1 deletion

2 calculations of median

Basically

https://insanitybit.github.io/2017/07/10/building-a-microservice-in-rust

This was a fun project I did to rewrite one of our production services in rust. I decided to use an actor based approach for it, which is something I don't hear much about with rust.

There's a lot of code in there, and much more in the service. I only cover message delete actors (they're the simplest and exhibit all of the big patterns) but if you look at the code you'll find many more, including a group dedicated to managing local message state, which was a lot of fun to write.

I also talk a bit about what keeps me from advocating that this service be deployed to production, which is probably of interest to some.

T