rustfmt VS rr

Hey so I've recently come across a few tools that make coding with rust just that little bit nicer. Things like automatic source code formatting; and cross compiling with docker. I'm only aware of a minor few > Rust src formatter

Am I alone in wanting a semicolon after that? Let's see.

I could list all the tracking issues for them like for control_brace_style but honestly I feel as that would be rude and that is not my intention here. But if you want you can scroll through their configuration page and see which features are stable. I'm not quite sure if I can use these even though they aren't stable yet.

See: https://github.com/rust-lang/rustfmt/issues/2924

See here for my suggestion.

There isn't overlap between these concerns (formatting and linting), formatting is syntactic analysis and linting is semantic analysis. There's only overlap because ESLint has some formatting capabilities as well. In modern languages, these are separate tools because they are separate concerns (rustfmt and rust-clippy , gofmt and go vet ).

rustfmt

I really wish Haskell had something like rustfmt. Pretty much all Rust code follows the same default rustfmt style. rustfmt is also deterministic, so the original formatting has no effect on the new formatting. This makes things very regular and predictable.

Reported.

Even recommending AMD CPU is wrong without knowing full use case of user, I bought AMD and this doesn't work for years https://github.com/rr-debugger/rr/pull/2671 and a good deal of software which depends on performance counters and Virtualization. Intel is still better when it comes to software. Thankfully, most thing are fixed nowadays.

For execution, a stack is a continuation. For debugging, we pretend like it's a historical record, and mostly get away with it. Various things break the correspondence slightly. TCO breaks it a lot more.

Debugging is important. It doesn't get enough respect. Stacks are a pretty critical component of debugging, for better or worse.

It would be great if we didn't depend on this fiction quite so much. With native code, there are definitely alternative options now, such as rr[1] and Pernosco[2] where if you want to look back in time—well, you just go back in time. For JavaScript, that's becoming more and more possible with things like Replay[3]. Perhaps before long, the debugging argument will just go away.

[1] https://rr-project.org/

[2] https://pernos.co/

[3] https://www.replay.io/

One of the most known time travel debuggers is rr. Basically, when the program runs, it records a trace, and after it crashes, it allows you to step backwards in time to see where the problem originated from.

Rr\ (37 comments)

rr numbers each 'event' it records, and you can pass an event number to the gdb 'run' command to tell it to start from that event. Recent 'rr' now also supports the -e option to replay meaning 'start the debug session pointing at the last recorded event, whatever that was'. Details in the usage page: https://github.com/rr-debugger/rr/wiki/Usage

AIUI you get 'start at an event' basically for free, because 'step backward' is implemented as 'start at the preceding event and then step forward by N', so events are frequent in the trace and the machinery to get to that point without running all the way from the start of the debug session exists anyway. There's some stuff on the website about how this is all implemented, I think.