thramp

I did a chunk of the work on the AWS side, and it's not not due to Chrome/Firefox—Google is using Rust for Fuschia, after all.

At least on AWS' side, it was some individuals—me included—who sent emails to the right people internally & pushed on tickets to be prioritized. There was surprisingly little pushback.

Ah, thanks. Just so happened that I don't have the required admin permissions to enable Actions on the organization I was interested in.

Can GitHub Actions be used on open-source repositories maintained by organizations?

> I don't like Rust for this purposes. It doesn't have higher-kinded types and thus no applicatives or monads, which sort of misses the point.

Having used parser combinators in Rust and Haskell (combine and attoparsec, respectively), I've found that even without applicatives, parser combinators are pretty handy—they're a step above regexes, but a step below a parser generator.

> I'd also be curious to see how the efficiency of parser combinators is affected by the absence of laziness in Rust. I seem to recall that laziness makes the analysis more complicated than you'd expect, but I need to find a source...

Same here, but I suspect that aggressive inlining might be pretty helpful.

There's some internal builds tools that I can vouch for. If you're still at Amazon, feel free to ping me at dbarsky@ and we can chat.

> What is going on with futures 0.3? Why is everyone still using 0.1?

Futures 0.3 uses nightly only-features that are landing in Rust within (hopefully) the next two releases of Rust. Namely, Futures 0.3 is a way to experiment with async programming using the async/await syntax.

> Why is everyone still using 0.1?

Futures 0.3 is still in flux—but settling down in recent weeks—and is relying on nightly-only features. Futures 0.1 is used heavily in Hyper and Tokio, but we intend to move to Futures 0.3/std::future::Future when they're available on stable or shortly thereafter.

(The Tokio and Hyper projects take backwards compatibility _extremely_ seriously.) (Disclaimer: I help maintain Tokio/Hyper, but am nowhere near are prolific as the main authors.)

Speaking as the co-author AWS's Rust Lambda Runtime: there's no fundamental impediment for us supporting Rocket (or any other web framework), but I suspect there'd need to be changes made in Rocket to support how Lambda expects input. Namely, Lambda functions don't see raw HTTP requests, but instead, fully parsed JSON. This blog post shows how Lambda expects data to be formatted: https://aws.amazon.com/blogs/networking-and-content-delivery...

It's a solid comparison, but I find it interesting that the author refers to Rust/Java/C++ as coming from the “IT World”. I guess the bit about human subcultures being fractal rings true here.

(Amazon employee here, but I have no idea what the SQS/SNS groups are doing.)

I always wished that SQS/SNS/Kinesis/et. al. could all be grouped under an "AWS Pub/Sub" brand that encompasses those features. I understand how those systems interact, but damn, it can be confusing so someone who's new.

There were public presentations where Fargate would have an EKS deployment option.

(Disclaimer: I work for Amazon, but don't have inside knowledge of the AWS Containers Organization's plans.)

> There’s no reason the Atom team couldn’t optimize their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.

I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.

It's a side effect of labeled arguments. The caller would use the function greet as `greet(greeting: "Hello", personName: "Alice")`.

Customer data is sacrosanct within Amazon. Cannot touch it without the customer’s consent.

source: I work for Amazon Web Services.

Me too, but I’d I realized that I’d rather the Swift team not half-ass such a big feature, especially when they’re working on ABI stability and translation of Foundation API’s.

Plus, I bet one of the things that’s holding proper concurrency back are Apple’s frameworks. I’d rather deal with callbacks for another year or two than use a rushed language feature.

I completely agree with you regarding the simplicity of Scheme! But that’s exactly why I don’t think Scheme should be people’s first introduction to programming. You need to give them friendly abstractions[1] that make them realize what is possible with computing, and only once they get those abstractions, break them down, and show them how the magic is actually implemented.

My opinion isn’t pie-in-the-sky theorizing: I know plenty of intelligent people whose first exposure to programming was Scheme, which scared them off into thinking that “they’re not smart enough for programming” or some bullshit like that. When they later tried a language like Python, they weren’t scared off—they were hooked.

The whole argument in favor of using Scheme as an introduction to programming seems highly ideological, and not at all informed by how people actually learn how to program. The fact that so many online resources successfully (Codecademy, Coursera, etc.) introduce people to programming using high-level languages is evidence that it works.

[1]: I know that all abstractions are leaky, but in the context of an introductory class, they’re not leaky enough.

I love Scheme as much as anybody else, but I’m not convinced that it should be the first introduction to computer science that people have. I think that the goals for an intro class is to get people to enjoy programming, not expose them to the raw beauty of Scheme/FP. I sure as shit didn’t appreciate what Scheme offered the first time I learned it.

That’s true, but the risks are significantly diminished. As they say, your business model is your destiny, and if have a good business model...

> And lord help you if you have to programmatically add or remove views from a layout at runtime.

I disagree with the rest, but yeah... that's a sore point.

Yeah, it is preference. I found that buying entirely into Autolayout + Storyboards makes for a really nice development experience.

And their reasoning makes sense. I totally get why they would avoid constraint-based layout.

I saw that, but using polyfills for layout give me pause.

I'd much rather be writing apps using constraint-based layout, much like AutoLayout. It took me a while to grok it, but it's much simpler once you get it.

The thing you’ve gotten wrong with wrong the “design lovers” you mentioned is that Apple’s customer base are entirely those quote-unquote design lovers who happen to be just normal consumers.

The entire point of the article is that competing on user experience pretty much side-steps the whole theory of low-end disruption.

How does it compare to AsyncDisplayKit?

"Equal opportunity jerk" seems alright at first thought, but when you consider that people of different races/genders have different social standing, it's clear that some people will be disproportionately affected by others being "equal opportunity jerks".

Plus, being an "equal opportunity jerk" is not a good policy at all — it's downright abusive. No one should be verbally berated in public for writing code that's not up to the maintainer's snuff.