Qwuke

The approach used here for breaking down large documents into summarized chunks that can more easily be reasoned about is how a lot of AI systems deal with large documents that surpass effective context limits in-general, but in my experience this approach will only work up to a certain point and then the summaries will start to hide enough detail that you do need semantic search or another RAG approach like GraphRAG. I think the efficacy of this approach will really fall apart after a certain number of documents.

Would've loved to seen the author run experiments about how they compare to other RAG approaches or what the limitations are to this one.

Yea, as someone building systems with VLMs, this is downright frightening. I'm hoping we can get a good set of OWASP-y guidelines just for VLMs that cover all these possible attacks because it's every month that I hear about a new one.

Worth noting that OWASP themselves put this out recently: https://genai.owasp.org/resource/multi-agentic-system-threat...

Yes, it's pretty disappointing for a seemingly big improvement over SOTA to be commercially licensed compared the previous version.. At least in the press release they're not portraying it as open source just because it's on GitHub/HuggingFace.

With a framework like Axum, yes, but with Rocket, no - you can just declare synchronous functions and pass them as a route handler, e.g.: https://github.com/Qwuke/recurse-ring/blob/main/src/main.rs#...

If you're averse to touching async fn's or tokio APIs _at all_, it's nice devex.

Sorry, so you can use synchronous functions for writing middleware and routes, but the rocket core does use tokio.

Not all async Rust webframeworks let you do away with async and futures entirely in your business logic.

Rust typically beats Go web frameworks on tech empower performance benchmarks, if you're curious where languages typically rank up in terms of web framework performance. https://www.techempower.com/benchmarks/#section=data-r23

What does "pure raw metal" performance mean? Go has a garbage collector, which I usually hear causing GC pauses negatively affecting performance compared to C/C++/Rust.

When you have 20 routes each being terminated with redundant `res.json(success);\n MiddleWare::Next` I think you can imagine why someone might see it as not lightweight in terms of unnecessary boilerplate - which most Rust webframeworks, async or not, don't require you to write out.

You're right, it doesn't really seem necessary and makes the responses of the route end up as side effects rather than part of the return type of the route functions.

Most web frameworks in Rust don't make responses a side effect and keep them as a response return type since that's better devex and much less boilerplate.

Yes, if you want a mature web framework that doesn't force you to use async then Rocket already exists, which is multithreaded and quite performant - and now allows you to use async if you want to.

Feather seems fundamentally single threaded and requires more boilerplate for something pretty simple. So I'm not sure the claim about developer experience holds up to scrutiny here either.

Can you explain how this would work if there weren't optional fields in your struct? Because if you're just suggesting that you use optional fields, that already works with vanilla serde.

Also, defaults for fields are already a vanilla serde feature.

It did get 29 points in 3 minutes, which seems like a lot even for a fan favorite, but is also consistent with previous OpenAI announcements here.

Haha yes, I misphrased a bit but that's what I meant when I said you'll need to use C++ to use the stdlib. It's not quite pure embedded Rust but yes it does work.

Compared to ESP8266, there's generally pretty good ESP32 support for Rust, but you'll likely need to use in your C++ toolchain if you want to use the standard library. no-std in Rust for ESP32 isn't terrible in my experience, though, just not as fleshed out - particularly for hooking into components like wifi/networking and probably a camera as well.

Like the other commenter said, there's plenty of support for SIMD and asm in Rust.

You might ask around on a Rust embedded or Rust ESP32 chatroom before making the dive.

I met Antithesis at Strangeloop this year and got to talk to employees about the state of the art of automated fault injection that I was following when I worked at Amazon, and I cannot overstate how their product is a huge leap forward compared to many of the formal verification systems being used today.

I actually got to follow their bug tracking process on an issue they identified in Apache Spark streaming - going off of the docs, they managed to identify a subtle and insidious correctness error in a common operation that would've caused headaches in low visibility edge case for years at that point. In the end the docs were incorrect, but after that showing I cannot imagine how critical tools like Antithesis will be inside companies building distributed systems.

I hope we get some blog posts that dig into the technical weeds soon, I'd love to hear what brought them to their current approach.

So Rust code may look jarring in-general compared to dynamic languages, and this is because Rust is a strongly typed language, but on top of that its type system also gives guarantees around data races that other typed languages don't prevent. So most Rust frameworks seem "noisy" when doing more than Hello World in my experience.

In my experience Rocket is intentionally less "batteries-included" than newer versions of frameworks like Rails and Django (especially around querying databases), but provides an opinionated approach that has minimal boilerplate in the same spirit as those frameworks. If you just want to write a Rust web service and get to the business logic, Rocket is a great choice especially if you're coming from another language.

>Rocket was created by Sergio Benitez. He is almost exclusively the only contributor to the project. Not because people don't want to contribute to it, but because the author wants to have it as sort of his child's brain.

I've talked to Sergio before in-person and got a completely different take of how he views contributions, but also, apparently he's explicitly trying to democratize Rocket's governance as part of this new stream of updates. I think the 0.5 release is a good sign he's doing his best to maintain his flavor of framework despite time constraints.

>I think that a website or API backend is the first project for many newcomers to Rust. It would be better for them to have first experience with other frameworks such that they are not let down by Rocket as it might cast a bad light at the whole ecosystem.

I guess your experience with it being a let down is contrasted with mine of how the 0.5 release candidates have been great to make web apps with - especially for new comers who want to experience a very ergonomic "secure by default" web framework in a language that makes major promises about safety, but also where encountering new behaviors with the Rust compiler can be an impediment from writing anything in the language.

>Rocket looks tempting because a/ it has a nice website b/ it looks feature complete c/ it is similar to Django/Flask which might make it more familiar d/ other web frameworks don't have particularly appealing documentation.

Perhaps we should spend some time as a community to make a website showing some examples and pros and cons of the various web frameworks. A good example to show newcomers that might help them choose a framework is demonstrating error messaging that some macros in Rocket emit vs a similar error in Axum that wouldn't ever have an error. Or showing them tower middleware crate ecosystem vs the middleware ecosystem in Rocket (or which parts of rocket that don't even need middleware or setup vs Axum) - not by hoping that the developer puts less effort in the project or kills it, which takes the options away from the community.

If I started on a website that does that, would you be willing to provide me some feedback? I'd be happy to take on that burden if there's a lack of a single, good resource for it.

I'd say it's more of an opinionated approach to a web framework, which reduces boilerplate on a lot of simpler applications. In order to facilitate this, it ends up creating more of a Domain Specific Language (DSL) using macros and types for Rocket, which can be harder to manipulate in ways you might expect as a Rust developer.

Axum on the other hand tends to avoid macros and uses the type system in "more composable" way with other Rust crates, and while still providing a concise way to create web apps, has resulted in more boilerplate to hit the ground running in my experience.

I'm not sure I understand this - I think having different options for web frameworks is great for Rust! Actually, it's probably more useful for Rust than other languages because Rust ends up being used by such a different range of developers and applications, and each framework ends up having such different opinions and providing different levels of abstractions.

So glad to see 0.5 out of release candidacy! I really appreciated how async functions and event streams were handled in 0.5, and just seeing this version land will make it so much easier to justify using Rocket in production.

I still think Rocket is the most concise web framework for Rust after 5 years now of using it in projects and even newer frameworks, and also is one of the best examples of how ergonomic you can make frameworks and DSLs in-general using Rust's type system.

For those wondering what makes it so different, the "batteries included" approach really differentiates it from other web frameworks in Rust, and it reduces the total amount of boilerplate you need to setup for simple middleware, streams, and security just about everything you need to do for simple web services.

This is a fantastic reading, kudos to you! I'll be sharing this with my reading group, I'll let you know if they've any feedback.

I love the design of the site and it's really a dream for reading translated poetry! I enjoy reading a handful of Italian poets (and translated poetry in general), and a website like this for German, Polish, etc poetry would be lovely. Would you ever think of open sourcing this for others to attempt this for their own languages?

I'd really love to see a couple poems from the notoriously hard to translate Giacomo Leopardi - they are quite beautiful, and hearing them in Italian is a treat!

I've not had much pain with semver violations in the Rust ecosystem (compared to say people abusing the yank functionality of crates.io), but semver is easy enough to get wrong where I might have just been lucky.

This is such a cool project that I hope it goes further, since verifying dependency distribution for correctness on top of all of Rust's other guarantees makes the ecosystem that much easier to justify investing in.

Kicks, fraidycat is great. Is there text anywhere of the current thoughts on what fraidycat 2: the desktop service may look like?

As someone who was on the fence about it, I feel exactly the same. The way the Rust maintainers and proponents of post-fix await helped create broader community consensus was impressive in itself too.

I think there are good improvements to be had in the async side of the ecosystem, but I do agree that Rust error handling is the most delightful of any language I've regularly used.

If hibp started using something that guarantees k-anonymity when checking for an email, like their password service does[1], then I think it'd be possible to keep the email unique.

1: https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

My South African cousins have desperately wanted an African Fortnite server. When playing on EU servers their latency was around 200ms on a good day iirc.

The differential dataflow codebase was really polished and optimized last I saw - when they say "demand milliseconds" I think they put the effort into delivering that.

Additionally, given it will be Apache licensed in 4 years, I think it'd be good to ask "Can I wait?" before going all in

I absolutely agree - there's a lot of explaining when you have to choose the less traveled path, and it hurts there's a perception that both languages are intended for 'academic' or 'niche' purposes.

Why Rust is considered over Haskell in one of the organizations I've been with is because it has the performance/memory usage characteristics of C/C++, which is a requirement for certain services. Though for many projects I'd imagine they'd meet similar levels of resistance.

I don't think the 'Rust is not as far along as backend web Haskell' is true in my (minimal) experience.

I've worked at one very small company and one very large company, and at both Rust was a much more serious/common consideration for web services than Haskell.