Asciinema 3.0 will be rewritten in Rust | Hacker News Reader

Asciinema 3.0 will be rewritten in Rust

github.com

108 pointsgoranmoomin62 comments

The fact that the demo is an Asciinema recording that demos how to record and upload an (inner) Asciinema demo is unreasonably amusing.

https://asciinema.org/a/85R4jTtjKVRIYXTcKCNq0vzYH?autoplay=1

now you can compare asciinema (rust) to vhs (go)

I still use and love asciinema, but will eventually check out vhs. It records terminal activity, outputs a gif, and you can publish to their[1] server.

Alternative you can feed it a "tape" file, aka a text file with a few configuration options and your ordered commands to run.

My workflow with asciinema sometimes has me cancelling out to redo w/ some minor change, so this tape concept is really attractive

1. https://github.com/charmbracelet/vhs

The charmbracelet team is rocking the command line with Go.

Does VHS have a way to add commands?

I do like the concept but one charming feature of asciinema is it captures natural input hesitation, typing candence, deletions and fixing mistakes, etc. The VHS tape replay seems so artifical.

I could see how to fake it with the current commands, but I could imagine a "HumanType" or something which increases the delay variance or includes typos that are backspaced and fixed etc, automatically.

Just a quick ponder.

I think it'll cover your needs. You can configure typing speeds, send commands for backspacing, if you were driving vim you could obv record doing search/replace/deletions

The fact you can iterate at all is its appeal to me

https://github.com/charmbracelet/vhs?tab=readme-ov-file#vhs-...

I saw that, yeah, but I don't want to do that manually.

A custom command that could add some jitter automatically or just pretend to be a bit more human would be nice.

Lets type "ls -lap" with some hesitation and a typo...

  Type "ls "
  Sleep 200
  Type "-"
  Sleep 300
  Type "l"
  Sleep 50
  Type "aa"
  Sleep 100
  Backspace
  Sleep 150
  Type "p"
  Enter

There is the TypingSpeed variable but its not exactly what I'm going for.

https://github.com/charmbracelet/vhs/blob/main/record.go#L22

I was looking at the code, and it seems like you could put a low value for this and it would do what you want.

I did not try it though

  // sleepThreshold is the time at which if there has been no activity in the
  // tape file we insert a Sleep command
  const sleepThreshold = 500 * time.Millisecond

EDIT:

I tested it. It actually work, but their software crash, I had to patch line 153

  for lines[i] == lines[i+repeat] {
    repeat++
    if i+repeat == len(lines) {
      break
    }
  }

EDIT 2:

I actually went ahead and created a pull request to fix the bug.

https://github.com/charmbracelet/vhs/pull/446

I appreciate and use asciinema, but a big plus one for VHS.

I like being able to store my tapes in a repo and edit them:

https://github.com/zackproser/vhs-scratch

And as the official VHS docs show you can do even more interesting things with CI/CD

Surprised no one has mentioned the big difference in that you can copy paste from asciinema animations but not from a vhs gif. At least last I looked it was like that.

VHS interesting, because you declaratively specify what you are recording and version control it.

However, I quickly hit a painful limitation, viz.: if a command takes non-trivial amount of time to run, you need to hack it by using `Sleep` to wait for command output. So I'm not fully convinced to switch from asciinema.

Incorrect link. Just goes to the list of open requests.

Here is a ticket which mentions the Rust rewrite, perhaps this was what was intended: https://github.com/asciinema/asciinema/pull/579

Seems to have been updated (or just works for me)

Yeah, and it seems like a better title would be "Asciinema 3.0 has been rewritten in Rust", since this PR was merged in November.

It is not maintained anymore, but there's termtosvg that still works and does not need javascript or service to render your output https://github.com/nbedos/termtosvg

I occasionally use https://crates.io/crates/term-transcript

Happy to see this. In my experiences,

    cargo run

works a lot more reliably than messing with Python virtual environments and trying to figure out what system wide dynamically linked dependencies you need to install.

cargo run just defaults to your home dir?

Because pip install --user is the same principle.

'cargo run' doesn't install anything; it just builds and runs directly from the source tree.

'cargo install' does install to (usually) ~/.cargo/bin/.

The useful difference, though, isn't in where things get installed, it's that a Rust binary doesn't really care where it lives, and most don't have shared library dependencies that aren't commonly installed already. So things tend to just work, unlike with Python venvs.

Cargo run just builds and runs the produced binary. It doesn't even install it

Vcpkg, Conan, and even CMake (kinda) attempt to do similar things.

It's almost like static linking is new technology

It’s not about static linking, it’s about an ecosystem and build tool that specifies dependencies directly rather than ambiently.

Vcpkg, Conan, and even CMake (kinda) do this. That's why I mentioned them. They're all trying to replicate pip, npm, cargo' success.

The second sentence was not clearly a second unrelated thought, but it was.

Fair! Sorry for misunderstanding you. Yeah I didn't realize it was unrelated.

Yeah, having starting to code back when dynamic linking was only available in systems like the Xerox Workstations, or Amiga libraries, it is ironic to keep seeing static linking as something extraordinary, never done before.

I'm happy to see the impact of cargo (pip, npm) on other language ecosystems.

C++ has a few good options now: vcpkg, conan, and to a lesser extent CMake with github integration.

In a world with millions of developers, it just makes sense to allow an easier integration pathway.

We used Asciinema on our revamped Caddy homepage :) https://caddyserver.com/

That's really nice, especially with the perspective transform.

The player is still in SolidJS.

https://github.com/asciinema/asciinema-player/blob/develop/p...

https://news.ycombinator.com/item?id=29387761

The Rust frontend frameworks have been creeping up the perf charts, though.

The mentioned rewrite is about the CLI though. The player is fine where it is (Solid.js + Rust/WASM).

I’ve already been using asciinema 3 as a Rust library to build tools - specifically, a tool that runs a command and streams the output logs directly to AWS CloudWatch.

So far, apart from some minor bugs which mostly didn’t affect me, things have been working perfectly - so much so that it’s kind of surprising really. Kudos to Marcin (and my thanks for being so engaged on Mastodon when I had questions!)

Interesting. When you use it as Rust library, do you produce a cast? What does it record actually?

Does using it as a library obviate vhs?

The cast format is effectively line-oriented JSON, which adapts well to being streamed directly to CloudWatch, with each line being a single entry in the CW log stream. It's then fairly easy to pull back out and replay as needed.

It's published up at https://github.com/rmccue/cinemastream if you're interested in trying it - it works, but still very early days, as it was just a holiday side-project. That said, likely to become a production tool for work, so will be cleaning it up a bit soon and squashing some bugs.

Worth noting that asciinema is not directly usable as a crate currently, so I did need to fork it to add a lib.rs, but the code was so well-structured that there's not much to do there: https://github.com/rmccue/asciinema/blob/rust-lib/src/lib.rs - Marcin did say he's open to it once 3.0 stabilised though.

I don’t care what Marcin writes it in: asciinema is just the single best combination of “I use this constantly for serious work” and “this is so fun I forgot I’m even working”. Speaking of which, time for me to donate now that I think of it. Off to do that.

"Last but not least, I enjoy working with Rust much much more than with Python :)"

Wow. I'm so curios about Rust now.

yeah honestly I built 1 little mac app in Rust and now I'm using typescript and can't stop thinking about how I miss Rust's Option and Result

TS solves that too right? Just return a type "MyInterface | null". You can even make it a generic Option<T>, or Result<V, Err> which maps to type Result<V, Err> = V | Err. I'm on my phone but I think that compiles :D

Yes, I'm stoked you brought this up, as I had previously googled and found some articles that recommend doing this in typescript. I haven't tried it out yet though, mainly because it seems like every article has a different approach to production-ready error handling in typescript and I don't know the best approach. Do you / does anyone have any suggestions for articles etc. on this?

no I would just do what makes sense to me, which is what I commented. you can do exceptions or type the return values. sounds like you want to do the latter. handling it isn't as nice as in rust though, I agree. You could create a simple object to emulate it though like "ReturnValue { unwrap: fn, ifOk: fn, ifErr: fn } " where unwrap throws if invalid, ifOk returns true if the response is valid, and ifErr returns true if an err.

Cheers!

Asciinema is great! The only thing it’s lacking is full screen support for mobile. Currently, on mobile the full screen button doesn’t work. I can zoom in the page but this never really aligns well.

The problem here is, at least on iOS, webkit on iOS doesn't support fullscreen API unfortunatelly. Once Apple fixes this it should just work (tm). Not sure about Android though (if it doesn't work for you on Android then let me know).

Does anyone have information on the success of Rust rewrites? Rewrites in general have a bad reputation, but I'm wondering if it's better for Rust since this course of action is so popular.

I've rewritten two personal, non-trivial projects in Rust and both have been successful. The most recent Python -> Rust conversion did take a bit more time than expected but it's stable and has already saved me a few hundred in AppEngine hosting bills.

I'd be interested in some elaboration. How did switching languages save you money?

Presumably the normal way (since they're talking about hosting bills). Rust is faster than Python assuming you don't go out of your way to make an inefficient program, and typically consumes fewer resources (though not always, but for roughly equivalent programs it should). This means you can get away with either fewer instances to perform the same amount of work, or the same number instances but for less total time. (Which benefit you get depends on the style of your system, but both will save you money.)

I moved from AppEngine hosting to self-hosting (on a Pi). The server was expensive to run on AppEngine and effectively free to run at home. The CPU barely ticks up, even when running a load test.

I didn't realize that AppEngine supported Rust. Are you compiling to wasm and then using their JavaScript runtime?

idk, I've always found rewrites to almost always pay off. You get to start with a clean slate, roughly know what it needs to look like, and know where most if not all of the dragons lie. Maybe very large systems that can't reasonably be rewritten by a single person wouldn't benefit from it, but anything below that scale probably can.

afaik some famous ones are like InfluxDB, Fish, and of course some parts of linux kernel (v4l2) that most of them improved the performance while rust provides abstraction at zero cost so it does make life easier

Rewrites have a bad reputation in the business world because it's nearly impossible to sustain the political will to make it happen for long enough to actually complete the transition, so you get partial rewrites that were supposed to be full rewrites. Open source projects are usually governed by the contributors, so there's less pressure for them to call a rewrite off early if they were all on board to begin with.

> Rewrites in general have a bad reputation

This is because of Spolsky's classic essay deriding rewrites, but that was in the context of a software company in a competitive market where the cost of a rewrite had to be weighed against the opportunity cost of letting your competitors erode your market share with shiny new features that you could have been matching otherwise.

Absent a competitive market (e.g. in volunteer OSS) rewrites are often quite successful, as long as they're undertaken by the original authors of the tool and as long as they avoid the second-system effect. (Note that nowhere does it say that rewrites must be in a new language.)

Now it'll be even better.

I'm impressed that the reasoning was more than just "Rust is super cool."

Rust is wicked fast?

blazingly fast

Like any low-level language it can easily saturate a single core, and it has pretty easy concurrency syntax.

My understanding is that there are lots of functional reasons to use rust in such situations, which are why it's considered "super cool".

Not really though. He keeps pointing out that he wants to integrate with Rust libraries, but it's actually pretty easy to write integrations between Rust and Python[1][2]. If that were the actual reason, there is a much better path of least resistance available.

The only other type of given argument for moving to Rust was that the author enjoyed it, so it appears to be another "Rust is super cool" rewrite. It really speaks to the power of developer experience. People are willing to rewrite their entire application to be more comfortable. I know I am, only my language of choice is Common Lisp.

1: https://saidvandeklundert.net/learn/2021-11-18-calling-rust-...

2: https://www.infoworld.com/article/3664124/how-to-use-rust-wi...

The startup time mentioned is actually a big deal for me – I do record all of my terminal sessions (I even wrote a tool that uses his avt library to grep through the terminal logs, although I never got around to making it fast enough to be really useful: https://github.com/moyix/termgrep), and with the Python version I often lose the first few characters of my first command in a new terminal because asciinema is still starting up...

You record all of your terminal sessions?! Sessions that are open for days? Commands that accidentally spew huge amounts of garbled nonsense to stdout multiple times because you're figuring a command out?

Maybe the new `asciinema convert demo.cast demo.txt` command (in 3.0, develop branch) would be useful to you? It converts the session to plain text using avt (which is now embedded in the CLI).

You could grep like this:

asciinema convert demo.cast /dev/stdout -f txt | grep foo

I'd usually agree, but the list of reasons involve integrating with Rust libraries, all of which it appears were written by the same author of asciinema.

I think it just boils down to the author feeling a lot more productive and less frustrated in Rust than Python. Which is a perfectly fine reason to switch!

Reply on news.ycombinator.com