Ken Youens-Clark

Tim Moores wrote:Does the book delve into how to use Rust for developing Wasm code?

Even if not, I wondered if you had any opinion on using Rust for Wasm development. There is a bunch of detailed documentation at https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm to get started with. If I wanted to dip my foot into those waters, are those the tools you might use? Specifically, rustup and wasm-pack. I'm comfortable with CLI tools, just wondering if there are other options that a seasoned pro might prefer.

I am completely ignorant of how to use Rust for WASM, but I'm very interested. For many years, I've used Elm (a dialect of Haskell) to transpile JS for interactive HTML, and I use JS or Python to write APIs. I would love to use Rust to replace all of this, but I would note that using Rust to interact with databases has been painful for me. Python is much looser about types and executing SQL and dynamically sorting out the tuples whereas Rust wants very string models for all this. My current job requires no web development. If I ever move back to that space, I'll be very interested to see how Rust develops.

Tim Holloway wrote:

Campbell Ritchie wrote:Does Rust work on all platforms as C and C++ do, Carl? It can hardly replace them if it is platform‑specific.

The real question is "can Rust run in any environment from cold iron up?"

I could not do OS-level programming on IBM mainframes in Fortran, COBOL, or PL/1. They could only run under their respective language environments (which were not friendly to interrupt-level coding, privileged modes, real-time or small-footprint uses.) One cannot extend Java's "write once/run anywhere" to cold iron, as Java needs its JVM environment. Likewise, Python, although an essential part of the Red Hat Linux boot process, cannot run on bare metal.

Granted, there are exceptions. Prime Computer wrote most (but not all) of its OS in Fortran (the hardware was actually optimised for Fortran, as I've mentioned occasionally). They also later adopted a dialect of PL/1, as Fortran was not the best language to do byte manipulation in on a word-addressed machine. I'm fairly certain that the Honeywell GCOS minicomputer systems could do OS-level code in COBOL (!!!).

But the point is, those were exceptions. C and C++ can run OS-level code on virtually any platform. The languages are designed for a very minimal external language environment. Well, C was specifically designed to write an OS in (Unix).

Rust is at heart a safer C and its language environment is, so I understand, to be suitable for even low-level OS code just like C. So much that the Grand Penguin himself (Linux Torvalds) has been looking towards having Rust code in parts of the Linux OS.

My formal education is in arts/language/music. I don't have a CS degree. I'm a self-taught hacker who's mostly worked in dynamically typed languages like Perl and Python. All those caveats said, I believe Rust can directly replace C/C++. As you note, it's probably going to become part of the Linux OS. Interpreted languages like Java, Perl, and Python require sometimes large runtimes/interpreters. One thing I note in the preface is that a Docker container with a useful Python runtime environment can run into the 100s of MB whereas I can build a similar Rust program and copy it to a bare-bones Linux VM that weighs in the 10s of MB. I believe some C libraries are needed (please don't hold me to that), but it's not much.

Campbell Ritchie wrote:Does Rust work on all platforms as C and C++ do, Carl? It can hardly replace them if it is platform‑specific.

I believe Rust will compile on every platform as C/C++. You can look at https://doc.rust-lang.org/rustc/targets/index.html for more information. What I adore is that I can *really* write cross-platform code that works on macOS, Linux, and Windows--I tests all the code in my book on all three platforms. I can barely get Python to act the same on all these.

Carl Byrd wrote:Hi Ken,

Congrats on the book. Do you think Rust will eventually replace C/C++ for most system-level type projects? Thanks.

I sincerely hope so! I should note that I have spent my entire 25-year career studiously avoiding C/C++ (and Java!), so my criticisms of those languages is entirely as an outsider. That said, I'd recommend you read the O'Reilly Programming Rust book, which was written by veteran C programmers who point out again and again the various ways that C/C++ allow you to write insane code with all kinds of undefined behavior and how Rust will not allow this (except for "unsafe" code).

Junilu Lacar wrote:I realized I should have said "crate" instead of library.  

Thanks for the tip. I'll check it out.

This tripped me up the whole time I was writing the book. Old habits die hard. I had good Rustaceans checking my code and writing who kept me honest.

Junilu Lacar wrote:Is there a library for Rust to process command line arguments?

I've worked with libraries in Go, Groovy, and Java and those have some really good abstractions for processing of Unix-like command line arguments, including displaying of usage messages, long and short options, automatic type conversion of arguments, etc.

If there are multiple such libraries for Rust, which one(s) would you recommend?

I exclusively used "clap" (command-line argument parser). It was the most similar to similar code I've used in Perl and Python, quite verbose and less "magic" than others. For the book, I wanted something with lots of documentation and very straight-forward usage. One problem is that I used v2.33 and they release v3 just after I published. (Rust moves very fast--the language itself updates *every six weeks*.) Some people don't like that clap can produce relatively larger binaries because it does so much. I don't personally care about that. To be honest, clap was the first crate I found that did what I wanted, so I didn't bother looking elsewhere.

I've seen some criticism that I used clap (both the older version and because of the binary size thing), but I've responded that each program I present clearly defines a section for parsing the arguments and a section for implementing the program logic itself. While I used clap, the reader is welcome to use any code they like so long as it passes the test suite (or they modify the tests to suite how they want to parse the arguments). Each chapter has a first section where I explain the goal of the challenge program and give lots of examples of inputs and behavior. This section always ends with a partially working version that shows how I use clap to parse the arguments, and the reader should complete the program using the test suite before moving to the solution section. Separating the code into the part that deals with the inputs and the part that does the thing means that programs can be use as CLIs/binaries or by other code.

D.J. Quavern wrote:Dear Ken,

I looked at the table of contents of the book and, in addition to the content (omy I did not know about `fortune`!), I love the typography I have to say.

For a while ago I was trying to put together a small program to "gamify" errors in Rust, displaying a cute graph on which error the programmer made, areas of improvement etc. I would like to pick it up again and I think reading the book would help me. (I did lots of tests, Junilu taught me well   )

My question would be about your thoughts behind the book take-aways: if I understand correctly, every chapter have practical exercises where we implement the linux cli. How long do you estimate those little exercises would take to a beginner+ person with some experience with Rust?

You are correct that each of the 14 chapters is a challenge program to implement in Rust. They all exist already--often many versions e.g, BSD and GNU--so there are ample examples of how these programs might work. The programs get progressively harder, so the later chapters will probably take relatively longer than the earlier examples. I've had the good fortune to teach programming skills in the college classroom (at the Univ of Arizona in Tucson where I live), and I would say I might be able to get a class of intermediate programmers through this book in a 16-week semester, averaging one program each week. It depends wildly on your background and determination, of course, but I think a few months could be enough.

Note that my teaching style is to present lots of small challenges that I hope will encourage the reader to put the book down and hack. For instance, in Chapter 4 where you write a Rust version of "head," I want you to write a Rust function that turns a string into positive (non-zero) integer. I provide and explain the function signature (fn parse_positive_int(val: &str) -> MyResult<usize>) and provide a unit test along with instructions on how to run the test. One early reader (an undergrad CS student who didn't know Rust at all) dutifully stopped and spent several days to understand how to write this and use all the types involved to not only create the correct result but also to create the correct error. Another reader might figure this out in an hour or a few minutes where another reader might choose to keep reading and use the solution I provide. If a person did nothing other than read the book and type out the source code provided, I still think they'd learn a good deal of Rust (and test-driven development!). If a person really challenges themselves to figure things out by reading documentation and hacking and writing their own solutions, I think they would learn even more.

Geoff McKay wrote:Congrats Ken Youens-Clark on your new book Command-Line Rust: A Project-Based Primer for Writing Rust CLIs.

With some languages it's necessary (or best practice) to define a variable's Type. (e.g. String, Numeric, Integer, etc.)

With Rust CLIs, is it best practice (or required) to specifically define a variable's Type?

Sometimes it's easier to read code if a variable Type is specifically defined initially, and this can help prevent potential confusion or debugging issues.

Using PHP as an example, you can specify a Type of Variable instead of allowing PHP to set this automatically based on how the variable is used. (I have heard people say PHP is a weak typed language, because you are not required to declare variable type)

What are best practices regarding Variable Type Declaration in Rust CLIs?

Sorry it took me so long to find the questions!

In Rust, you can sometimes leave off the type declaration because the compiler can figure it out, but it is sometimes necessary to be explicit as the compiler may choose a type you don't want (e.g., list vs vector). I would say it's best practice to use type annotations as much as possible. Function signatures do require all the type annotations, and I find this makes them easier to understand.

I code a lot in Python, and type declaration is relatively new there. Some people find it abominable to declare types in Python, but I find it far easier to read and use tools like pylint/flake8/mypy to check my code. This means, of course, that it's my responsibility to write and run my tests and those code profilers to ensure I'm doing everything correctly. I prefer that the Rust compiler does all this for me.

Junilu Lacar wrote:I'm planning on making Rust my choice for this year's Pragmatic Programmer Learn a New Programming Language every year.

A few questions for newbies:
1. Is there an IDE that works better for Rust programming? What does your development environment look like?
2. Is Rust mostly for command line / console programs or can it be used for other things?
3. What kind of programs might it not be the best choice to use?

1. I learned vim 25 years ago, and it's been my only text editor my whole career. I write every language (bash, Perl, Python, Haskell, Rust, JavaScript, etc.) in it. (I've also written all three of my books in vim. I detest Word.) I have a few customizations for each language mostly around syntax checking and auto-formatting (e.g., yapf with Python, rustfmt for Rust). I personally dislike IDEs. I find them busy and pushy. I don't like using a mouse. I prefer using vim shortcuts where my hands never leave the keyboard, and I find I'm quite faster at editing code. With my training in music, I actually feel like vim is an instrument that I've mastered such that I barely think about how to execute very complex operations. I usually open 2-3 terminal windows where I use the command line to execute programs and tests in some and edit source code in others. I keep it as simple and as possible, so when I'm developing locally on my machine I use the same tools that I use when I'm shelled into a remote machine.
2. Rust is killer on the command line and is making progress in many other areas such as WASM (web assembly) and the Linux kernel. Honestly, I've only used it for CLIs, which is about 90% of what I do. For web development, I use Elm to write front-ends and generally Python to interact with databases for the API. Rust is a relatively young language, so I expect it will keep expanding into all these areas. I would love to use Rust to code web front- and back-ends one day. I still have a lot to learn, esp about WASM.
3. I find I still have to use Python quite a bit in the data science realm. My gig is bioinformatics, and while Rust is making some headway there, most of the tools and libraries I need are Python and R. E.g., I rely a lot on the Python "pandas" library to parse tabular data and perform basic statistical operations. The relative looseness of Python can be an advantage with nebulous and poorly formulated data, so I would only jump to Rust if I was trying to battle-harden some code. I did recently write a rather large Python application for a customer and found Python required me to write loads of tests, many of which would have been superfluous in Rust. Unfortunately, I was lacking Rust libraries to parse some very specific and tricky genetic data. Time constraints didn't allow me to roll my own version in Rust because the Python module was just fine. This will change one day, and maybe I should work on that Rust library (in my copious free time!).

Jeanne Boyarsky wrote:I just emailed him. Too late for the promo, but not too late to be helpful.

Hi Ken,
The idea was to check https://coderanch.com/f/60/ol and look at the titles. There are a number of questions about the book. Even though the promo is over, you can still go back and engage with those.

-Jeanne

Yep, I totes botched that. Sorry! I'll get on the other replies now.

Tim Cooke wrote:Don't forget that this thread is for welcoming the promo author only and posts here aren't eligible for the prize winners draw.

If you want to ask a question about the book and be eligible for the prize then start a new Topic in the Other Languages forum. For the promo week Ken will be watching the forum for your questions, although there's nothing stopping Ken from hanging around longer if he so desires. Everybody is welcome.

Yeah, I'll keep checking back in to see if anyone has a question. I didn't seem to find many takers for Rust, but hit me up if you ever want to give it a try or you have questions!

Campbell Ritchie wrote:Good to see you here; hope you have lots of awkward interesting questions

Yeah, so I'm here to convince Java types to learn Rust! I think Rust has some amazing things to contribute to one's understanding of how different languages can shape how you think and code. For kicks, compare how you might write a Java version of "cat" to my Rust version in https://github.com/kyclark/command-line-rust.

D.J. Quavern wrote:Hello everyone! And welcome Ken .
Is it your second Rust book, I think I saw something else from you pass.

Long time no see <3. Ooooh I would love to play for this book!

I am in the (long on and off) process of writing a Rust gamepiler (compiler that gamifies the errors you do) and it would help me greatly :p

This is my first Rust book but my third book to publish. The first two are on Python: Tiny Python Projects (Manning, 2020) and Mastering Python for Bioinformatics (O'Reilly, 2021). All my books (so far) take the same approach of presenting a challenge program in each chapter. The reader is provided tests and inputs to help create a program that works according to the spec. Rust has a steep learning curve, so the book starts with printing "Hello, world!" and slowly moves through how to get command-line input from the user to how to read files and STDIN then how to write files and STDOUT and so forth. Since I stress how to write and use tests to develop the program, I'm also teaching test-driven development (TDD), which I think is the most important skill the reader can apply no matter what language they use or learn.

Sorry, I missed this thread. Happy to answer any questions or give any encouragement. Learning by coding and testing is a great path, IMHO!

I think of Makefiles as runnable documentation. I would be lost without them. I'm including an appendix on Makefiles in my 2nd book, _Reproducible Bioinformatics with Python_ (O'Reilly, 2021).