This Week in Rust is a weekly newsletter summarizing news, RFCs, crates, and community posts from the Rust ecosystem.
HN recommends it for following Rust's progress and stability, and lists it among favorite weekly tech newsletters.
I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here.
Another example is the "This Week in Rust" newsletter which takes progress that would've taken you hours to read about yourself, and puts it into a succinct format that you can get through in minutes [1].
The Rust 2017 roadmap which targeted forward movement on all the language's weakest features was admirable in itself, but even moreso is how much progress has already been made. In particular, I'm really excited about incremental compilation, which is showing as much as 5x speedups in early results [2].
I was also very happy to hear that the Rust team acknowledges that regardless of how performant they are, futures are not a particularly ergonomic or maintainable way to write code, and are considering what new constructs might look like over the longer term:
> Over the rest of this year, we expect all of the above libraries to significantly mature; for a middleware ecosystem to sprout up; for the selection of supported protocols and services to grow; and, quite possibly, to tie all this all together with an async/await notation that works natively with Rust’s futures.
I'm still on dabbling in Rust, but I'm fairly convinced that in another…
Here's a funny quote about that...
>> Can you eli5 why TryFrom and TryInto matters, and why it’s been stuck for so long ? (the RFC seems to be 3 years old)
> If you stabilise Try{From,Into}, you also want implementations of the types in std. So you want things like impl TryFrom for u16. But that requires an error type, and that was (I believe) the problem.
> u8 to u16 cannot fail, so you want the error type to be !. Except using ! as a type isn’t stable yet. So use a placeholder enum! But that means that once ! is stabilised, we’ve got this Infallible type kicking around that is redundant. So change it? But that would be breaking. So make the two isomorphic? Woah, woah, hold on there, this is starting to get crazy…
> new person bursts into the room “Hey, should ! automatically implement all traits, or not?”
> “Yes!” “No!” “Yes, and so should all variant-less enums!”
> Everyone in the room is shouting, and the curtains spontaneously catching fire. In the corner, the person who proposed Try{From,Into} sits, sobbing. It was supposed to all be so simple… but this damn ! thing is just ruining everything.
> … That’s not what happened, but it’s more entertaining than just saying “many people were unsure exactly what to do about the ! situation, which turned out to be more complicated than expected”.
https://this-week-in-rust.org/blog/2019/03/05/this-week-in-rust-276/
https://www.reddit.com/r/rust/comments/avbkts/this_week_in_rust_275/ehe2kre/?context=1
Assuming that "crypto" was meant to refer only to cryptocurrency, there are a few companies working on non-blockchain/non-cryptocurrency crypto(graphic) tech which are paying as much as web dev jobs.
For example, I stumbled upon ockam.io during my last job search (no affiliation, and never interviewed with them as they weren't actively hiring when I wrote to them last year). I vaguely remember there being a few others, though I can't remember any names off the top of my head (it has definitely gotten harder searching for those kinds of companies as most job ads are drowned out by all the blockchain jobs). Old job posts on https://this-week-in-rust.org/ often contain a few interesting companies.
(Shameless plug: If anyone is interested in working at a non-profit focusing on non-blockchain cryptography in the field of multi-party computation, the company I'm working at is hiring at the moment and the salary ranges [for a 4-day work week] are listed: https://sinefoundation.notion.site/SINE-Job-Board-d28eda00c5db43f297c627ba8c29cabb)
https://www.jendrikillner.com/tags/weekly - Graphics Programming weekly
https://halisavakis.com/category/technically-art - Technically Art weekly
https://us17.campaign-archive.com/home/?u=ac8ab0580c321574fe178a646&id=466256ba5a - Blender Guru Newsletter
https://twitter.com/search?q=Creative%20Code%20News%20(from%3AsableRaph)%20filter%3Alinks%20-filter%3Areplies&src=typed_query&f=live - Creative Code News
rarely:
https://tympanus.net/codrops/collective - Codrops - web design news, resources
https://speckyboy.com/?s=Weekly+News - Speckyboy - designers news
https://kerkour.com/tags/newsletter - Kerkour - favorite links
https://habr-com.translate.goog/ru/search/?q=%D0%B4%D0%B0%D0%B9%D0%B4%D0%B6%D0%B5%D1%81%D1%82&target_type=posts&order=date&_x_tr_sl=ru&_x_tr_tl=en - habr ru - various technical weekly news
bookmarked:
https://www.datascienceweekly.org/newsletters - Data Science Weekly
https://this-week-in-rust.org - This Week in Rust
https://www.fightaging.org/archives - Fight Aging
Copy paste from https://this-week-in-rust.org/blog/2021/10/06/this-week-in-rust-411/#quote-of-the-week
There's a common trope among people unfamiliar with rust where they assume that if you use unsafe at all, then it's just as unsafe as C and rust provided no benefit. Comparing C's approach to safety vs Rust's is like comparing an open world assumption to a closed world assumption in formal logic systems. In C, you publish your api if it's possible to use correctly (open world). In Rust, you publish a safe api if it's im possible to use in correctly (closed world). Rust's key innovation here is that it enables you to build a 'bridge' from open world (unsafe) to a closed world (safe), a seemingly impossible feat that feels like somehow pairwise reducing an uncountable infinity with a countable infinity. Rust's decision to design an analogous closed-world assumption for safe code is extremely powerful, but it seems very hard for old school C programmers to wrap their head around it.
This
>I have a very hard time grasping all the functionality/concepts
is (partially) because this
> if we ever want to control the tsunami of security flaws
Most focus in how the borrow checker work "against" you but that is not even the harder. Performance and how manage memory are more "painfull" in rust.
BECAUSE NOBODY KNOW HOW DO FAST & SAFE CODE.
Not ALL the time. Without extra help of the compiler your assumptions can get wrong in invisible ways...
Rust WANNA:
- See what is costly
- See what is unsafe or not
- See what own what
- See what is on heap or stack
The borrow checker is just a part of it.
From https://this-week-in-rust.org/blog/2019/07/02/this-week-in-rust-293/
Python and Go pick up your trash for you.
C lets you litter everywhere, but throws a fit when it steps on your banana peel.
Rust slaps you and demands that you clean up after yourself.
– Nicholas Hahn