Rustbuddy is a command line suite of tools that automate some of the tasks that I thought were common as a novice learning the Rust language. You might find them handy too. Find it here:
Tools included are:
bump - increment your version in Cargo.toml
mkerr - generate a custom error in the fashion of Defining an error type chapter from Rust By Example
mktest - scaffolds unit tests for each function and method in a file. Uncomment and fill in your values for each case you want to test.
stringer - generates string representation methods for one or every enum
tree - not really a tree! Prints a table of version and publication information that recurses through a crate and all of its dependencies (ctrl+c if you get tired of it)
a nice ascii crab
usage: ./rustbuddy [subcommand] [flags] [args]
Many (maybe all) of these tools have analogs on crates.io or elsewhere, but I sometimes find it useful to have one program to act as a toolbox that holds other small programs so that I can (re)discover them with the help command.
If you don't care to build from source or don't have a go compiler, then the release tab has builds for most popular desktop platforms.
This is lightly tested software, so if you find an error, please bring up an issue. If you've got a better way, make a pull request.
is it written in go ?, my suggestion might feel useless but why not write it in rust
? plus it would be nice to have feature like taking and applying zipped backups with ability to
Yes, Cobra is a really nice library for this sort of program, and everything else I wanted is in the Go standard library. Plus distribution is a little easier than Python, for example. You don't have to write your tools in the language they operate on.
I'm not too proud to merge a PR, so if you rewrite it (or at least the parser) in Rust, @theduke, then I'll merge a total rewrite. I think that you should try rustbuddy and see if there is a problem that a Rust implementation might fix. I know clap is a good, well-maintained library, but I was more at a loss of what to use to parse a source code file and get the spans of specific code blocks. I did spend some time skimming through Syn's docs for this, but I figured that I could probably have just written my own simplified lexer in Go by the time I figured out Syn's API. Go isn't fun to write at all, but the standard library covers a lot of uses and is well documented.
Python would have been much more fun, but distribution isn't as simple (and I think mktest and mkerr at least might actually help some people).
Since nobody else has said it, thank you for this contribution of tools. Your description implies that you developed them while you were learning Rust, by using a language (Go) in which you were already quite proficient. Those readers who are already proficient in Rust can develop a Rust-based version themselves.
Odd you mention verbose. You should see how I mangled things like JavaScript to get it to read like natural language. It's quite an interesting area and allowable with compression. So it is really coding standards and style applied to design patterns if you get my meaning.
We're probably talking about different things. I assume you mean verbose in the sense of function and variable naming conventions (and maybe program structure? I would probably have to see what you mean to understand). When I say that I think Go is verbose, I mean that the syntax requires more LOC to accomplish the same task. For example, a one-line list comprehension in Python would take several lines in a for loop to express in Go. Rust has a lot of functional idioms (not to mention macros) that I think make its source a little more information-dense than Go.
Where I completely agree and support your pont here. Needless boilerplate in code has ever been a curse. Absolutely.
I did get on a tangent. I enjoyed defining code so it read like natural language. It too should be very concise.
Without current quality word prediction it was slow and the style was important. It had potential but technology is leap frogging that.
Regardless verbage that serves a purpose I like. Documentation in the code and macro (code?) attributes for example. More functionally, lifetimes and types don't seem to detract from readability.
