cat-whisperer

Reminds me of the talk on Rust's LLVM IR optimization issues. Constrained languages like Rust can be optimized way better than C/C++. Seen similar points made before.

I've been using this technique in Rust for years, really helps catch bugs early and makes code more readable. Wish more languages had similar type systems.

I this this was there in claude's system card too? right?

What about doing something just-in-time? I'm just speculating, but what if cline leverages the LSP (for instance, rust-analyzer) to track the function chain and build a tree-like context of the codebase—not the entire codebase, but just specific blobs of code?

Would that work?

Can the highlights provide insights into have the temprature affected the sentence construction?

I was looking at Claimify by Microsoft, that could be a brilliant extension to this. What do you think?

This is going to different, as resources end up getting intertwined? or is there a way to standardize it?

I once added a massive codebase, GPT told me today’s weather.

giving credit where credit is due.

ascii art for the win

I was thinking of making it a opt-in feature, but I saw most of the usecases that I might have, might need concurrency and a runtime.

it definitely would be, that was my intention. By passing in a runtime you can either block or schedule. Giving you control on what you want to be concurrent and what you don’t.

asccinema is a killer idea! but I am still chasing my perfect shell . If you end up implementing an insane looking shell with this, contributions are always open.

Wow! rustyline has intensive support for a lot of the actions and things the user can do. Though I wanted to provide a more restrictive yet powerful abstraction that’s my I chose a trait based approach. It provides the exact control needed on certain aspects of the shell while providing ample control because of the shared state. Initially, I was planning to make the functions async, but I rather choose to pass the async runtime instead. It solves for 2 cool use-cases; 1 we can call block_on and manage an async task in the flow, or 2 queue in the action and consider pooling it when needed.

Yup, I am planning to use thiserror and error-stack for this in the future updates. But, anyhow provides an insanely easy interface for the person using this library, and keeps their mind off the error handling and rather in managing the domain stuff.

I built a Rust allocator that uses files instead of RAM for memory storage. Because who said memory allocation needs to be fast? Want to make it even more "interesting"? Mount your allocation file over NFS/SSHFS and watch your program's memory requests casually traverse the internet!

Now your RAM can have packet loss and network latency. Distributed systems enthusiasts, your dreams of globally distributed RAM are here (sort of)!

We've all used builder patterns. And though they're elegant, debugging them can be frustrating. I discovered this while working with a large struct – missing a field only surfaced during runtime, which wasn't ideal. That got me thinking: since we're using Rust, why not leverage the compiler to catch these issues for us?

That's why I created buco. It's a simple yet powerful crate that gives you all the benefits of the builder pattern, but moves all the checks to compile time. If you miss a field, the compiler won't even let you call the build method.

I built this CLI tool to instantly preview hex colors in my terminal using Kitty's graphics protocol. It's written in Zig and lets you visualize multiple colors side-by-side without leaving your workflow.

The tool focuses on one thing: showing you exactly what a hex color looks like, right where you're working. No need to switch to a color picker or browser. Tested on: kitty, wezterm, ghostty.

A great read, fascinating stuff

Great stuff, interesting concept and good design, but I would be more fun if:

- There was a bit more freedom in the selection menu

- I agree with @arvindnatarajs on making the output editable and adapting the story-line accordingly

- And the instruction popups could be a bit less annoying ;)

Great stuff though!

Nice game, I only went till 10.45 Billion.

Apart from the initial efforts that go into the setup, how do you manage day-to-day ops with multiple dashboards?

For web apps using wasm for development could be a game changer

This reminds me of the time I functional programmed the shit out of `async` (featuring closures).

https://github.com/juspay/hyperswitch/blob/16cd32513bc6528e0...

I don't fully understand the context or the overview of the problem, but for a large codebase, if you are using `tokio` runtime, which most rust based application go with. `tokio-console` is good for profiling and debugging, have you folks looked into that during the whole debugging process? I personally trust debuggers and debugging tools in such circumstances, as they can easily help zeroing down on such issues.

> With exclusively static dispatch I feel like it should be possible to unconditionally detect at least the presence of recursion at compile-time,

That's true, and Rust as a language does do so, but in case of recursion for `async` function rust itself suggests to go the `dyn` route. Adding more to the post, it seems that the use of `async-trait` was the reason that they didn't have any choice in the matter to choose static dispatch, as the language as a whole doesn't support async traits, (just yet! ^-^)

This is a good overview but its high level, are there any other resources to understand payment flows for individual payment methods better?

Targeting engineers who want to copy some code and get done with the integration has been a core part of Stripe's DNA. This added with the fact that they don't need dedicated support / sales teams explains why they make huge margins from small and medium businesses