ratatui VS ripgrep

We use a cassowary based constraint solver within Ratatui [1]. It's kind of neat once you understand the algorithm and add your own UI rules system on top of it. Unfortunately the library[2] that we use for the actual solving is unmaintained for many years now. I've been meaning to rewrite[3] a bunch of things in the lib to be more ergonomic, but it hasn't bubbled to the top of my todo list yet.

[1]: https://github.com/ratatui/ratatui/blob/main/ratatui-core/sr...

[2]: https://crates.io/crates/cassowary/

[3]: https://crates.io/crates/kasuari

I think this may lack a bit of context, so I'll try to fill in.

This is a demo that was just showcased live by the author as part of their talk at FOSDEM'25: https://fosdem.org/2025/schedule/event/fosdem-2025-5496-brin...

The talk was centered on Ratatui (a TUI library in Rust, https://ratatui.rs/) now targeting terminals and web browsers with a shared approach. Video recording of the talk should appear online soon.

Proudly built with Ratatui: https://github.com/ratatui/ratatui :)

The graphics themselves are basically handmade pixel-by-pixel, you can take a look in the assets folders to get an idea.

For example, pirate images are generated by combining the different parts and then applying a color mapping for the different skin tones.

Planet gifs are adapted starting from https://deep-fold.itch.io/pixel-planet-generator

Excellent article of what is going on in the terminal space, agree on the TUI section where we are seeing lots of terminal tools being built in Rust and Go and libraries such as Ratatui [1] and Bubble Tea [2] becoming a new modern alternative to ncurses for building TUIs.

Python has Textualize which is also very popular for building terminal user interfaces [3]

And we've noticed this renaissance as well of new CLI and TUI tools that we list on Terminal Trove [4].

[1] https://ratatui.rs/

[2] https://github.com/charmbracelet/bubbletea

[3] https://textual.textualize.io/

[4] https://terminaltrove.com/

I recently had to look at the implementation of the Sparkline [1] widget in Ratatui which uses a similar Unicode technique but scales nicely for sparklines with larger vertical size.

[1] https://github.com/ratatui/ratatui/blob/20c88aaa5b9eb011a522...

ripgrep GitHub Fast alternative to grep

I didn't call ripgrep a replacement. Other people do. Because it does actually replace their usage of grep.

https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

> The maintainer also has been pretty rude to me about this on HN.

This is AFAIK the only other interaction we've had: https://news.ycombinator.com/item?id=41051587

> but it's still crazy to think people won't be caught off guard by this behavior

Straw-manning is also crazy. :-) People have and will absolutely be caught off guard by the behavior. On the flip side, as I said 9 months ago, ripgrep's default behavior is easily one of the most cited positive features of ripgrep aside from its performance.

The other crazy thing here is... you don't have to use ripgrep! It is very specifically intended as a departure from traditional grep behavior. Because if you want traditional grep behavior, then you can just use grep. Hence why ripgrep's binary name is not `grep`, unlike many other implementations of POSIX grep.

> Its name is literally indicating it's a grep replacement.

I also tried to correct this 9 months ago too. See also: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

For anyone else following along at home, if you want ripgrep to search the same files that GNU grep searches, then do `rg -uuu`. Or, if you don't want ripgrep to respect your gitignores but ignore hidden and binary files, then do `rg -u`.

When you think ripgrep (rg), you probably think "fast regex search tool."

I'm sure you can get creative. :-) You can set an environment variable to control the encoding, expose a flag or any one of a number of other things to control the encoding.

You've also continued to ignore my most substantive rebuttal: that a specific example where ripgrep is not compatible with grep or doesn't behave the same doesn't mean it can't be used in shell pipelines. Literally nothing you've said has invalidated anything I've said. All you're doing is finding things that some implementations of grep can do that ripgrep (intentionally) cannot do in exactly the same way. But that's fine, because ripgrep was never, isn't and will never be compatible with grep: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

So if you need grep compatibility get a fucking clue and just use grep.

> Rust applications are sometimes (often?) slower than comparable C applications

Could you cite some examples? There are plenty of counter-examples

- ripgrep is 5-10x faster than grep (https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21...)

- Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...)

- I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly, but Rust and C are comparable in speed (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)

- Advent of Code - I came across Rust codebases which solved all of AoC 2024 in under 1 millisecond (almost fully assembly), and also ordinary, idiomatic code in under 100 milliseconds. I don't recall anyone ever posting a C codebase with perf measurements, but I could have missed this.

I'm surprised by the "often", but I'd be interested in any cases where C outperforms Rust. Please share if you've found any.

ripgrep

The original comment said nothing about modifying servers or AWS engineers installing random shit. That was you. I responded to "moving binaries around," and you started yapping about change management. Two totally different things. Like obviously if you have a locked down environment, then only install what you need. But this is not what the original poster was referring to specifically.

ripgrep even specifically calls out this exact use case right in its README: https://github.com/BurntSushi/ripgrep/?tab=readme-ov-file#wh...

> You need a portable and ubiquitous tool. While ripgrep works on Windows, macOS and Linux, it is not ubiquitous and it does not conform to any standard such as POSIX. The best tool for this job is good old grep.

So, you presume too much friendo. Now, go away.