Is Rust going to fail in a glue project?

I wanted to learn Rust for some time. I am starting a new small standalone project and I am considering it to finally write some code in Rust. The project is mostly about text processing, file operations, calling external commands etc.

I wonder whatever Rust is a good choice for something like that? Maybe for such project staying with glue language like Ruby or Python would be a better choice?

Rust can do all of this with just the standard library; in particular, string handling of Rust is excellent compared to basically any other systems language and IMO on par with that of scripting languages. Regular expressions from the regex crate are blazing fast.

The only thing you might be annoyed with is compile times, depending on primarily the number of dependencies of your project.

1 Like

Is it something that is visible from scratch, from hello world, growing linearly as I add more dependencies or is there a risk of compile time suddenly growing exponentially without a clear reason?

In this project I am unlikely to care at all about execution speed. Execution speed of regexp is unlikely to be a bottleneck in this project.

But info that Rust has things like "copy folder and all its contents to location XYZ" in the standard library is a good news.

"string handling of Rust is excellent" - as in "sane UTF8 default everywhere" or as in "all reasonable functions are in the standard library and consistent" or just "not null-termination mess like in C"?

Rust's standard library is actually small; it's kept that way so that it can be ensured to be future-proofed. It (Rust) is designed to be heavily dependent on external crates (the name for libraries in the rust world), making it necessary to have external dependencies for a variety of things.

Build times aren't that bad, at least not in my opinion. The slowest thing I've personally had to compile is a web project with yew, which took 20 seconds. On top of that, rust's first compilation of a project is the slow one, after that it no longer has to download and compile dependencies thanks to incremental compilation.

  • String is the default utf-8 based one, with str being a view into its data (A special pointer to a string). It's different from a Vec<char> in that it packs the characters tightly, ensuring the smallest size.
  • CString (And CStr) are for c-based interop, and are analogous to a String + null byte.
  • OsString (And OsStr) are made specifically for talking to the OS, and will be guaranteed for platform compatibility. This is essentially treated as a Vec<u8> for the most part since it can contain not valid utf8.
1 Like

Your compile times might bloat suddenly if you take a dependency on a crate which has in turn many dependencies (directly or nested).

Rust's native strings are UTF-8. Rust also contain standard library types which handles C style strings for you and enforces that no null bytes are inserted and that the string is null terminated.

UTF-8 everywhere, and also all reasonable functions are present.

The only tools for dealing with UTF-16 are encoding and decoding, and on windows the standard library takes care of this completely for you (though it has to expose an OsStr type to preserve unpaired surrogates on windows as well as arbitrary bytes on Linux. Sometimes working with this type is annoying).

It gets a bit annoying when you have something that's not UTF-8 but still a superset of ASCII, because the type we generally use for such strings is simply &[u8], which doesn't provide any string utilities. There are some crates that provide a dedicated "ByteStr" type for this.

1 Like

Rust's str and String types are defined to be UTF-8 and when something potentially non-UTF-8 comes out of a process, for instance, then you can still conditionally convert an OsString to a String, etc. And yes, functions on str and String are reasonably comprehensive. I'm not sure what you mean by "consistent" – just like any other functions, string operations won't be able to corrupt string contents (for example) from entirely safe code.