latte VS ratatui

This tool is probably the fastest in its class - does this code look like having a lot of lifetimes or other cryptic syntax?

- https://github.com/pkolaczk/latte/blob/main/src/main.rs

- https://github.com/pkolaczk/latte/blob/main/src/exec.rs

There was one fundamental "aha" moment for me when it clicked: move semantics.

> Does https://github.com/pkolaczk/latte count?

This is just Rust code. Where is the equivalent Java code?

> Or the Optional cost described on my blog here: https://pkolaczk.github.io/overhead-of-optional/?

Why aren't you using OptionalLong[1]? You shouldn't use Optional, that's never a good choice. At any rate, nobody should be claiming Java optionals are are free, they're a high level abstraction and absolutely do not belong in hot codepaths.

In general it's fairly easy to construct benchmarks that favor any particular language, which is why you constantly see these blog posts about how high level interpreted languages (JS, Haskell) are faster than C++.

> And what do I do with that knowledge if it turns out the optimization didn't happen?

The way the JIT works is by aggressively overassuming, and then recompiling with more generalized interpretations of the code when assumptions turn out to be false. But the wider problems of compilers occasionally generating suboptimal instructions isn't something that is Java specific.

[1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base...

A few weeks ago, an interesting issue appeared on our GitHub tracker. It was reported that, despite our care in designing the driver to be efficient, it proved to be unpleasantly slower than one of the competing drivers, cassandra-cpp, which is a Rust wrapper of a C++ CQL driver. The author of latte, a latency tester for Cassandra (and Scylla), pointed out that switching the back-end from cassandra-cpp to scylla-rust-driver resulted in an unacceptable performance regression. Time to investigate!

As a sound and music computing person, I rarely used tui before although I use cli tools often, e.g. SoX. I usually use Audacity to record on Mac. But then I realized I wanted a tool that could quickly open and record inspiration, and that's when TUI came into play: I decided to write my own custom tool called asak (audio Swiss Army Knife) [1]

This way I can quickly record on Mac, and of course, since this is Rust and ratatui [2], this tool should also be cross-platform.

[1] https://github.com/chaosprint/asak

[2] https://ratatui.rs/

> If someone plopped me in front of a rust codebase I'd be at the mercy of the manual for quite a long time.

This is not a representative sample of Rust. That's explicitly triggering edge cases which requires abuse of syntax you wouldn't normally see.

Check out this for something more realistic that anyone should understand https://github.com/ratatui-org/ratatui/blob/main/examples/ca...

nice work!

can I use "cargo install --git https://github.com/aabiji/muse"?

I also recommend:

https://github.com/ratatui-org/ratatui

https://github.com/mikaelmello/inquire

for your further development

I also have a Rust CLI music project here if you want to have a look

https://github.com/glicol/glicol-cli

There are apps that are built on ratatui that support mouse already including an example in the repo[1], and crates (and some internal changes to the buffer) to support iterm/kitty/sixel based images.[2]

[1]: https://github.com/ratatui-org/ratatui/tree/main/examples#cu...

[2]: https://crates.io/crates/ratatui-image

Compared to TurboVision, Ratatui has a lot of missing things:

- Containers

- Dialog types (I'm working on this in https://github.com/joshka/tui-prompts)

- Higher order combinations of widgets (e.g. combine the scrollbar and paragraph)

- Menus

- Any event system (apps bring their own - we just handle display)

- etc.

- There's lots of things in TV that are provided as external crates (like editors, treeview, etc.)

The main thing is that Ratatui is at least right now, just the display side of things. Things to do with events or application shell aren't built-in. This somewhat stems from the immediate vs retained mode approach to the library, but this may change in the future.

The TUI is built with the awesome Ratatui [0] library (formerly tui-rs [1]). UX is certainly not my area of expertise and I would not have been able to create Trippy without this library.

[0] https://github.com/ratatui-org/ratatui

[1] https://github.com/fdehau/tui-rs