[GTALUG] A find alternative: fselect

David Mason dmason at ryerson.ca
Thu Jun 13 10:40:47 EDT 2019


My preface: 40 years of C programming is enough! I don’t plan to write any more C; where I need that low-level efficiency, I’ll use Rust. Ditto no C++; if I want objects, I’ll do it right with Smalltalk.

With that said, Hugh makes a legitimate point (if we were talking apples and apples).
> On Thu, Jun 13, 2019 at 1:12 AM (actually, earlier) D. Hugh Redelmeier wrote:
 |   Rust culture and practice doesn’t seem to like shared libraries.. I do.

Rust does tend to create static code from crates (its packaging system). But C does too, for source code that you compile into your code. The difference is that, because crates are understood by the compiler it is *much* easier to make decisions about what version you want in Rust.

Rust also *does* use dynamic libraries for C/system code. I have a web server that uses sqlite3 and the generated executable includes the sqlite3, resolve, and system dynamic libraries.

So the static part is the crates, and it is trivial to discard the previously frozen versions and compile with the latest versions.

HOWEVER, since Rust code is intrinsically much, much safer than C code, stability of API is much more legitimate a characterizer of the version that you want than bug-fixes (and bug-fixes are almost never security/safety related). Rust uses semantic versioning of crates, so you can specify, e.g. version 2.3.* of a crate, to get any bug-fixes without any breaking changes.

All in all, I think Rust is making the right choice here. (And C is making the right choice for C code, too - because it’s so unsafe!)

../Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20190613/3dbfdd3a/attachment.html>


More information about the talk mailing list