I've never written a single line of Rust. But I try to keep up on it since it's one of the most interesting and ambitious languages to come along in a long time. And I will say this, I think the community is doing a great job of being transparent and making it possible to follow along on the side. If it's anywhere near as well-run on the inside as it seems to from the outside, then I think it will serve as a poster child of how to develop a language in the open and build up a community around it.
The first thing I did when my holiday break started was to configure Visual Studio Code with RLS and work through the examples in the O'Reilly Programming Rust book. There are some rough edges, but it's amazing how far the tooling has come.
How's the O'Reilly book so far? I made it through the second edition of the rust book but found it a bit lacking as a novice. I think a second time through the Rust book after writing a few programs will be really useful, but I wouldn't mind trying the O'Reilly one as well.
I’m happy with it. I totally agree with mlevental‘s assessment of the intro. Just getting through that boosted my feeling of competency a lot. I’ve been anticipating this book for a long time, and I’m not disappointed at all.
I think my original statement came off a bit harsh. For more context, I'm a C programmer who managed to avoid C++ and templating for...too long. Rust just has a lot of new (to me) ideas that will probably take a bit longer for me to grasp than other programmers.
As an example, reading the official documentation at first was an absolute struggle due to all the terminology and syntax I was only vaguely familiar from the book. It's getting easier as I practice more.
The more documentation -- the merrier. Thanks a ton for your work!
Rust support landed in gdb 7.12 (released October 2016). It has some rough edges; and some missing spots (mostly caused by insufficient debuginfo).
I'm working full time on Rust debugging now. My basic plan is to write a Rust plugin for lldb (WIP branch https://github.com/tromey/lldb/tree/rust); then update LLVM, rustc, lldb, and gdb in sync to add support for missing features.
I'm interested in bug reports and other constructive feedback.
LLDB works well enough to sometimes be useful. I've used it with the VS Code native debugger extension [1].
I've encountered a couple annoyances:
A. Using rustc to link somehow removes debugging information from static libraries I wrote in assembly [2]. This is extremely annoying, but I haven't had time to really look into it and it seems others can't reproduce it.
B. There seem to be some occasional oddball problems when stepping through code. Like it'll skip lines, or stay on the same line for many steps. And also an annoyance regarding how that VS Code extension handles "Step Into" for functions you don't have the source for: you can easily get into an infinite popup situation and have to restart the debugger.
IMO the sad truth is that if a great debugger is a prerequisite to use a language, then you're limited to about 5 total languages.
Yeah, quite possibly. I feel like I've stepped through some pretty gnarly iterator chains and it's worked surprisingly well. It is rare that I actually need to turn to the debugger, so I could be mistaken.
So far I haven't encountered a problem that wasn't caught at compile-time.
However, your question prompted me to see if I could set a breakpoint and step through a program, and I was able to do it without much effort.
I have the "LLDB Debugger" extension in VSC installed. After that, the trick was to configure its launch.json to have the "program" property set to "${workspaceRoot}/target/debug/mandelbrot".
That's all it took.
Maybe I'd encounter some shortcoming trying to actually use it in anger, but I was happy to be able to do this much.
This is encouraging! In my experience, getting to this stage - where you've actually seen the thing successfully hit a breakpoint - is 95% of the hard work with debugging. I'm not a heavy debugger user, I prefer trace logging, rich type systems and tests for most problems, but then that one time when you have no choice but to "use it in anger", it simply has to be there.
I seem to run afoul of some obscure, ungooglable edge case almost every time I try to start a debugger I don't use very often, regardless of the platform. Of course this happens when I'm frustrated enough to be considering using a debugger in the first place, which is exactly when you don't want to be rage-googling why your debugger refuses to print symbol names, but only when you start it with exactly the arguments you need to start it with to trigger the bug. Or when you try to send an email more than 500 miles away Or print on a Tuesday. By that point, your debugger problem is worse than your original bug.
There's a strong sense from a vocal portion of the software development community that debuggers aren't really needed (not suggesting that this is you, just a general observation). Coupled with the fact that building a functioning debugging tool is no easy task, we end up in a situation where far too many platforms treat debugging as a second class citizen when it's really an essential feature, even if for some of us it's a feature of last resort.
Newer GDBs have native support; Visual Studio (not Code, but also Code)'s debugger works too (we generate pdb files). Older gdbs and lldb can use a plugin/script.
When was this? Rust has been able to pretend to be C for years, now, and debugs pretty ok. However until last year you could not do things like call functions (in gdb, lldb doesn't have support yet).
We're now moving towards making Rust have Rust-specific debuginfo for a better debugging experience. tromey (who has commented below) is working on this both for lldb and gdb.
I'm an Eclipse guy and when writing this [1] for fun, debugging in Eclipse worked fine (I'm on Fedora). Code completion via Racer mostly works (except some cases like recognizing the type of the try! macro's result).
For what it's worth, while I would regularly use a debugger for C code, I've never once tried or had the urge to use a debugger on Rust code. (I've been using Rust for almost 4 years.)
I usually don’t use the debugger to debug language features, but rather my own logic. It’s very useful to step and inspect parameters when you can’t really see your own logic errors.
I have to say that my own experience over the last two years matches burntsusih's pretty close.
In the case of logic stuff Tagged Union/Enum types help me force logic at compile time. If I've got a particularly intractable logic problem a good coverage of unit tests works well to flush out any bugs and give me confidence when it comes to refactoring.
There's been a handful of times that I've wanted to reach for the debugger but a couple inspect()/println!() calls did the trick in those cases.
I have recently gotten back into coding with Rust and I must say that the strides in the compiler errors and usability have been massive. Getting things to work has never been easier and every time I get something wrong I learn a little bit more.
Not done my homework with Rust yet. Pardon my ignorance.
Does Rust have a native(all Rust) implementation of SSH client yet?
(I know ssh2-rs exists, but, I'm looking for a Rust implementation and not a wrapper over libssh2(C))
Does Rust have a stable/documented library for serving Web applications over http/2 yet?
(I have heard about h2, hyper and Rocket, but can I write a basic web app in Rocket and expect it to use http/2?)
I like everything I hear about Rust. I will allocate serious learning time to it when the answers to the above questions turn to yes. Hopefully soon!!!
Is it possible these guys fail to realize people don't use python for its speed? I, for instance, use python because it's an extremely elegant language that allows me to write short, compact, and succinct code that's incredibly easy to read and is self documenting.
I do use python, but calling any dynamically typed language self documenting is a huge overstretch. Sure, naming may be structured well, revealing intent, but without formal contracts the code is not self documenting. There is this problem with computers that they perform what they are told to, not what is expected from them. Good naming and structure help closing the gap between expected and actual behavior, but the gap is always there, therefore this is documentation in at most a very broad meaning having very little to do with language in question.
Static types, on the other hand, actually document things - at the very least what can be passed and what will be returned. This may not be completely necessary when reading code or even writing code in a well known environment and context that fits into programmer's head, but without formal contract programmer is faced with two choices: trust manual or read and understand ALL the code. Python is notorious offender here with args and kwargs - when reading code using some wrapper library I must understand how underlying library is used, because customization of underlying library behavior is not part of wrapper library documentation.
I agree. I'm learning Rust by rewriting someone else's small Python app in it. Rust requires you to define your variable types, especially for container types like vectors. I'm a decent Python programmer, and the app code is straightforward, but I realized I don't know what data the app operates on at each stage! I was forced to randomly insert print() around.
