You say that Rust is like a religion
the community is toxic
and you rather stay apart.
You say that C can be coded safely
that it is just a skill issue
still I know you just don't care.
R: And I say "what about mem'ry unsafety?"
You say "I think I read something about it
and I recall I think that hackers quite like it"
And I say "well that's one thing you got!"
In C you are tasked with managing mem'ry
no help from the compiler
there's so much that can go wrong?
So what now? The hackers are all over
your systems, running over
with CVEs galore.
R: ...
You say that Rust is a woke mind virus,
rustaceans are all queer furries
...
And now let's jump right in!
Sorry that the graph is from right to left. I didn't find the time to
fix that. The median point release - if there was one - can out 15 days after
the point zero release. So if you can wait a bit more than two weeks to update,
you'll still have many of the benefits with only half the point updates.
Note that every problem found in beta will also create a new beta backport.
Let's move on to cargo
perhaps not all of you know that cargo can run examples like this?
or that cargo has built-in shortcuts? Reduce your RSI!
To counter the meme that rust binaries are large, strip your release
binaries, unless you need the debuginfo for something
cargo has a project- and user wide configuration file. Here's where to
put it. And now let's see what we can do with it:
note that clippy will also check all lints that cargo check does, and
then some. bless is mostly used with compiletest, a tool that checks if we
get the right compiler errors. So if you do type shenanigans to ensure your
users' safety, perhaps use that, too.
But wait, there's more! You can have cargo compile to use all your CPU's
bells and SIMD whistles (especially if it has AVX512 capabilities)
Also consider using a shared target folder to reduce duplication of build
artifacts on your disk.
you can also configure lints here, so it won't be needed in your code
The lint will report multiple crate versions, in this case `rand`.
The downside is that both versions need to be compiled, and may even
lead to incompatible types later down the road.
With that said, it's often not really an issue.
avoid ambiguity that would later need a turbo fish to resolve
insta will use either the debug representation or a serialization in
various formats as "snapshot" that you check once, then reuse.
Run your code locally under a WASM runtime, the argument is used to
allow accessing the current directory. You can also use different directories
Note that the bindings of those patterns must have the same types
and closures are functions, too
If you use "allow", the annotation will just stay there even if the code
changes so the lint no longer applies. On the other hand, using expect gives
an error in that case, so you don't forget to remove the annotation.
If you write a library, help your users avoid mistakes.
You can annotate functions that are only useful for their results with
`must_use` so the `unused_must_use` lint will pick up calls that don't.
You can also annotate types that should always be used when returned from
functions.
Sometimes you have internal types, so that when a trait implementation is
required, type inference should not recommend them. In that case, add the
annotation to the impl, not the type.
Thank you for being such a nice audience.
To live-rebuild:
while ! inotifywait -e modify life.md; do marp life.md; done