ProDBG switches to Rust

A little about ProDBG from the translator and author of the project

ProDBG is a new debugger that Daniel Collin is currently developing. One of the goals of the project is to support multiple architectures and operating systems. Initially written in C / C ++, plugins support is included. At the moment, is at an early stage of development, and is mainly aimed at MacOS. Then I give the floor to the author of the post.

---

As known to those of you who follow me on Twitter, I don’t really like C ++. He has his usual problems with header files, slop patterns, and so on. And the big problem is finding an alternative. I was considering switching to C #, but making it work well on all platforms seems like a very difficult task (for example, there is almost no x86 support on the Mac). In addition, some people will not like this choice.

I like (Common) Lisp. I admire the device of its macros, it has that elegance that is not found in all languages. However, it seems somehow alien to many people, so investing in a project will become much more difficult. In addition, I want to use the language without a garbage collector whenever possible, and although Lisp can be greatly accelerated, this is not so easy to do.

Rust entry

I followed Rust for several years, but I never wrote anything on it before version 1.0 was released in May 2015. When I began to get accustomed to Rust, I wanted to understand whether there was something useful in it for me. On paper, everything looked good (I will give a list of the most interesting moments for me):

• Guaranteed memory security.
• Streams without race data.
• Minimum runtime.
• Effective binding to C.
• No garbage collector.
• Modules.
• Using LLVM.
• Compiled into native code.

I decided to see what use Rust will lead me. I also made a presentation about Rust, which can be viewed here .
')
At that time, I began to review the list of platforms supported by Rust. It supports Mac, Windows and Linux. Windows support is usually so-so, at least for “new” languages. I was pleasantly surprised that Rust works fine on Windows, for which many thanks to the Rust team.

My other question: “is Rust used for large projects?” The transition to a language that will not be used anywhere in the next few years is a sludge, and although this is not the end of the world, the result can be quite painful. It seems that Rust itself is written in Rust , and it is quite large. Mozilla's Servo is also a big project, and is also written in Rust.

Is Rust suitable for plugins?

My next move - by the end of the Christmas holidays, add Rust support for plugins (only C / C ++ is now supported) to find out how easy it will be to write plugins on it. And it seems that wrapping Rust around a C API based on structures with function pointers works great. Here is an (early) example .

Although a lot of the code in this example can be improved if it is made more idiomatic for Rust, it does work with the C API, which I wanted to prove.

Can ProDBG be rewritten to Rust without complete rewriting?

I started playing, revealing the different parts of C ++ code and calling only “prodbg_main” from Rust. After fixing several link errors, everything worked! This is one of the advantages of Rust: being a compiled language, it can be linked with C / C ++ code without glue in the form of a DLL.

Then I began to reveal the rest of the code. I wrote a “plug-in processor” that loads dynamic libraries (plug-ins) and shows one of them on the screen. At the same time I added a reload of the plugins, so now when I compile the plug-in (which can be written in Rust or C / C ++) it will reload on the fly, which is great.

Here you can look at the test code with which you can play before a deeper dive into the main code (at the moment the code is no longer available - approx. Transl.) .

And now what?

After I played around a bit with Rust, the language definitely captured me. This is a great language that offers great features (see my presentation ). I especially want to mention the system of lifetimes and borrowing. What is good about borrowing / lifetime is that the Rust compiler can be controlled with a truly immutable state, which allows the noalias of the LLVM phase to be turned on, so that Rust can even outrun the C code in performance.

Participating in the Rust community and observing language development gives me hope for its future, so I decided to start writing ProDBG in Rust. At the same time, I will rely on external C ++ code (like imgui, Scintilla, bgfx). I have no reason to rewrite everything to Rust. The API, which is also open to plug-ins, will still be on C. Thanks to this, adding support for other languages ​​(Lua, Python, JS, .NET) will become much easier in the future.

disadvantages

Switching to the language used by as many people as C / C ++ always has its problems. A slower compiler (they are working on this problem), difficulties in debugging (there is no good front end yet, but I think this is a good motivation for me :), fewer people who know the language, and no one knows what will happen in the future. Despite all this, I still think that Rust is on the right path, and it seems to me that going to it is the right decision.

The biggest drawback is that the transition at the beginning will slow down the development of the project, which sucks. I was hoping to have reached version 0.1 by now, but now the release is being postponed.

Afterword

That's it. The decision was not easy, because it affects all project participants. Notice that the API will be in C, and I accept input as plugins written in C / C ++.

And yet I think the decision was right. Here you can read about what happened to the language during 2015, and what awaits it in 2016.