As is known by Python users, one can do many things when using ipdb to debug python.

But I found that when i am using gdb or some Rust-IDEs to debug Rust, I can do far less things on breakpoints（see examples below）which may certainly bring lots of inconvenience to Rust coding and debugging.

I want to know the reason(My misoperation or some theoretical reasons？)

I also raise a question about simliar problem on Stackoverflow: Edit – Stack Overflow

Thanks for your replying~

So，May I conclude that：

• The debugging difference between Python and C++/Rust are almost equal to the debugging difference between interpreted languages and compiled languages
  • When I am using interpreted languages, surely there is more convenience while debugging.
• But The debugging difference between C++ and Rust is from the current poor Rust support of debug tools
  • Maybe in the future Rust codes(even c++ codes) can be debugged more conveniently, but not now.

On the flip side, I can not write C++ w/o valgrind + gdb, but in Rust, println! + logging has been enough for everything I need. I.e. it is not clear to me effort spent on “better debugging” is better than spent on “reduce need for debugger / catch more at compile time”

Yeah I think that is the advantage of Rust, one can spend less time on manually solving memory problems which is unavoidable in other languages.

But in my daily works, memory management is not the main problem, the challenge is mainly about writing complicated codes to achieve various complex functions(or effect? Pls ignore my poor English)

So i …just cannot endure the inconvenience of using “println!”https://users.rust-lang.org/”debug!” and then compiling once to debug. Each time I do that, I miss the convenience of C++ debugging and Python ipdb, badly

Maybe Rust is not suitable for research works? I think…

There is GitHub – evcxr/evcxr , but I do not think “repl / interactive” driven development is the Rust way — and I used to use Clojure before Rust.

Thanks, i will immediately try it out