rusbus

This is exciting because the effect size is so large. But as the author's acknowledged, selection bias is nearly impossible to control for in this non-randomized study:

and lacks randomized controls. Self-selection is the central threat: students who complete more quizzes may be more motivated or higher-performing generally

But this is still a strong result. I'm excited to see more in this space.

Two years ago someone told me "I wish I could understand what Tokio is actually doing."

This really stuck with me and earlier this year I had both an idea and the time to try to make it happen. I think with dial9 that is finally possible. dial9 is a system to pull in a huge amount of events, very efficiently and analyze them later. Tokio is just one source of those events, but its a very important one.

Once we had Tokio, I realized we could also pull in lots of other sources as well; Linux kernel events, application events, tracing etc. etc.

Folks have already had good luck using dial9 to find tricky issues in prod.

Does anyone else find it incredibly ironic that this article summarizing the paper was obviously written with AI?

All the headings and bullets and phrases like "The findings are clear:" stick out like a sore thumb.

perhaps you did not read the post—the author attempted layer-by-layer first but discovered it was impossible to get a smooth final result.

This is apparently a well known issue among people who create resin-cast structures.

Another useful library in this space that allows you to avoid manually writing bindings is https://github.com/duchess-rs/duchess

TLDR: Install a wifi microcontroller _inside_ a TI-84. Make a little app that can talk to ChatGPT.

How crazy is the build chain these days? Well, to build it in FIPS mode you need a Go compiler!

The verbatim responses come as part of "Browse with Bing" not the model actually verbatim repeating articles from training data. This seems pretty different and something actually addressable.

the suit showed that Browse With Bing, a Microsoft search feature powered by ChatGPT, reproduced almost verbatim results from Wirecutter, The Times’s product review site. The text results from Bing, however, did not link to the Wirecutter article, and they stripped away the referral links in the text that Wirecutter uses to generate commissions from sales based on its recommendations.

The Rust SDK does not currently use the CRT under the hood. The CRT is a high performance C-Library for fast HTTP connections (and a lot more).

For S3, there is a meta-layer that interceps requests to S3 and converts them into ranged-gets and multipart uploads for parallelization.

It's quite complex and can also use significantly more memory, but it does allow for *much* faster uploads and downloads in some circumstances.

Probably the biggest one is "batteries included but replaceable." The Rust ecosystem is still maturing, so we did a lot of work to make reasonable default choices but still allow customers to make different ones.

Some of our other design tenets are here: https://smithy-lang.github.io/smithy-rs/design/tenets.html

It's on our radar—one of the biggest issues is that some of the services like EC2 are absolutely massive. We're investigating ways for customers to only compile the operations they need, etc.

if you use other Async runtimes, you need to "wire them up", in this case by providing a "sleep" implementation. I'd strongly recommend using Tokio, especially if you're a beginner. I think the "beefy" statements are not necessarily accurate. You can use it as a single-threaded runtime if you want. Tokio is not going to have a significant impact on your compile times or binary size (given you're already using the SDK!)

The Rust SDK is built on top of the smithy-rs code generator. On the service coverage front, you'll find nearly 100% parity—There are some legacy APIs that aren't supported. It also doesn't have many "high level libraries" (e.g. S3 transfer manager) that can find for other languages.

New services will come out the same day as all other SDKs–All SDKs utilize the same automated system to deploy new releases.

The only exception is services which require extensive custom code. We're still catching up on those for the Rust SDK.

What kind of plans for support of Rust's evolving async ecosystem?

We were hoping async-function-in-trait would land before GA, however, we have a plan to add support in a backwards compatible way when it's released.

Any particular reason why the public roadmap does not show the columns similar to "Researching", "We're Working On It" like the other similar public AWS Roadmaps?

Our roadmap has unfortunately been in a state of disrepair for some time. We're hoping to get it cleaned up and accurate post GA.

Would be nice to have fully working examples on Github, for most common scenarios across most AWS services. This is something that historically AWS SDKs have been inconsistent on. Just a request not really a question :-)

There are lots of examples here [1], some simple, some quite complex. If there's something you have in mind, please file an issue! Having great examples is one of our priorities.

[1] https://github.com/awslabs/aws-sdk-rust/tree/main/examples

Not all languages have a great interop story with Rust. Binding the JNI is especially tricky, for example. Furthermore, when performance isn't important, the need to package and compile Rust code may be an unnecessary hassle.

Although this is true in theory, in practice you need to be very careful when writing code if you want to target WASM. One example: `SystemTime::now` will panic on some WASM platforms!

Yep! There are actually examples that use Web Assembly: https://github.com/awslabs/aws-sdk-rust/tree/main/examples/w...

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

Am I the only one who has never heard of nor seen a git.io shortened URL?

the optimal 5 letter starting work is SERAI (as computed by someone's AI)

Here's a summary, but really you should watch the video, it is great.

Take 1km of wire, a resistor lightbulb, and a power source. Connect oscilliscope around power source. Flip switch.

For 1 light-speed delay, you actually see current going across the lightbulb! After the speed of light delay, current starts flowing normally as expected. (Why? How? Is this spooky action at a distance?)

You're actually seeing cross-talk between the wires where the build-up of electrons on the high side actually moves electrons on the (spatially) adjacent side of the loop!

Then to really complete the puzzle, sever the end of the wire. You still see the exact same behavior up to the speed-of-light time! (Which, how could you not! You need to wait a speed-of-light delay to _discover_ that the wire was severed, so you MUST see the exact same behavior.)

The fundamental premise of this post is that a boring web framework is bad, but making basic websites doesn't need to be an exercise in bleeding edge frustration.

Django, many years later, still presents a straightforward solution to a straightforward problem, (almost) all batteries included.

I think if you are an absolute JQ master, it doesn't get you much more. Streaming aggregates where the data live updates in your terminal is one thing. But also the language is a little easier to grok, IMO. I can never use JQ without googling

Traits are applied to types and because the length of the array is part of the type, different length arrays are different types.

It's only with the very recent launch of const generics (allowing constant values like numbers as generic type parameters) that it became possible to abstract over things like array length.

IIRC there is some stickiness about the default trait that is still blocking a const generic array initializer.

I found running a 6-node Patroni cluster on Kubernetes to be a surprisingly pain-free experience a couple of years ago

The internet has come full circle: https://www.youtube.com/watch?v=J9SK_M_nVWA&ab_channel=infin...

(Hoax video from 2007 about how to get Google TV)

This test relies on RT-LAMP to generate copies of the RNA instead of PCR which the "regular" tests use. It's pretty sensitive, but not as sensitive as state of the art PCR[1]. It's also way faster. No magic, just a slightly different technique with different trade offs.

[1] https://www.frontiersin.org/articles/10.3389/fmicb.2018.0208...

Comby seems more like "parenthesis matching + search" (they don't implement a full parser for the language, just some basic required constructs to make a basic AST. I imagine this limits the resolution of the search?

Semgrep uses an AST that's equivalent to the parser of the language itself so it's much higher resolution in terms of what you can match.

Also, the term "Guy" which is an eponym for Guy Fawkes https://en.m.wiktionary.org/wiki/guy#Etymology_1

Perhaps our setup was different than the sibling comment describing a bad experience, but I found, compared to other complex K8S charts, that patroni was exceptionally reliable, medium easy to setup, and I would generally be grateful if everything worked as well as Patroni did.

But this was a fairly small Patroni installation on a fairly small K8S cluster (6 nodes), so YMMV.