it. Apparently this is what is expected by the youth of today. It
can be hit hard enough to stop it doing this, but you still run into
the difficulty that if you use one library from the repository, you
-end up having to trust much more widely than ideal. And at least
+end up having to trust much more widely than ideal. At least
Rust's repository contains larger libraries than, say node.js's, so
-the number of people you're trusting is much lower.
+the number of people you're trusting is much lower, but it's still
+troublesome.
Also, as a build tool, cargo can be very inflexible. Despite an
official policy that cargo should be suitable for running inside
up containing piece of opinionated curl-pipe-bash-ware, you should
expect a culture which produces these kind of problems.
+[ other problems ]
+
+Rust does not currently readily support dynamic linking between Rust
+modules. This is something the Rust community know they need to work
+on but it hasn't been their priority. Some of Rusts's language design
+choices make this challenging, although not impossible. In particular
+the very nice system of generics. Personally I like the tradeoff that
+Rust has made here. I expect that some form of dynamic linking or
+partial compilation will very likely appear eventually. But in the
+meantime there are places where replacing C with Rust is awkward.
+
+Rust depends on LLVM. So its architecture support for smaller
+architectures (with less money behind them) is poor. From my point of
+view as a Debian contributor a particular problem is the lack of an
+m68k backend for LLVM. But it provides a more general difficulty with
+supporting a wide set of embedded architectures, which Rust would
+otherwise be very suited to.
+
+
F======================================================================~
-[ rust-lang, ian.jackson@ ]
+[ rust-lang, ijackson@ ]
Despite these difficulties, and of course a fair few minor
irritations, I have found programming in Rust to be both fun and very
~ijackson / talk-2019-ghm-rust.git / blobdiff