philm

Or in other words, you can already try it, it's open source: https://github.com/pop-os/cosmic-epoch

When it's ready...

Hmm pretty sure, it's not vim, as that would be u and C-r

(Nor anything else...)

Yes agree, I need unsafe super rarely, and often it's just for small optimizations (like std::mem::transmute::(kind) where SyntaxKind is an enum with #[repr(u16)]).

But I guess it depends on what you're doing exactly though (the higher-level, the less unsafe you need).

Also checkout https://doc.rust-lang.org/rust-by-example/. It often goes a little bit more into actual detailed code examples and often contains stuff that isn't in the book. Basics are well explained in the book though (like lifetimes)

For example, if I’m writing a compiler for a new toy language

Ok, thinking about it (since I wrote a toy language not so long ago), this is probably a perfect example where unit tests make sense almost everywhere (even for prototyping, say parser).

I think it definitely depends what you're doing, writing unit tests for prototype graphics (engine) code is no fun (and I see no real benefit).

Code readability counts, but I don’t think it’s enough.

I think it depends, For general architecture, E2E or integration tests definitely make sense, for finer-grained code, I think documentation (Rust doc) of the functions in question should be enough to understand what they do (including some examples how to use them, could be tests, often examples (similar as in std rust) in the rust doc are enough IMHO, and otherwise the code itself is the documentation (being able to read code fast is a valuable skill I guess). That obviously doesn't apply for everything (think about highly theoretical computer science or math code), but yeah it depends...

I find writing tests helps me understand my own code better, so I still do it when doing research tasks

Hmm interesting, I try to optimize readability of the actual code itself, so that when I read it again after some time, that I quickly get what this is about, if there's a edge-case or something I thought about while coding, I'll just add a TODO comment or something like that. I feel like reading tests is a "waste of time" for me most of the time (hard take I know ^^).

But all this obviously only applies for researching and fluid code (code that likely will be refactored/rewritten soon), when it's solid code targeting production etc. I'll add unit tests if friction/hassle is low, and integration/E2E tests for the overall thing. But as I said, I'm mostly in fluid/fast moving codebases that are more difficult to test (e.g. because it does gpu rendering or something like that).

I probably wouldn't see it that negative TBH. I'm often finding interesting content for whatever problem or interest I'm currently having via google (SO and yes reddit has also quite a lot to offer from the community). I rarely click anything that looks too profit-oriented and fortunately those pages although are on the first page, often aren't the first search result.

SEO got a little bit smarter nowadays, sure it's still a game with the search, but modern SEO is more focused on information and site design (e.g. does it display on mobile correctly?) etc. AFAIK.

Yeah you're right, tests should test logic. But static typing certainly helps reducing a lot of tests, which would be necessary in different untyped languages. Also you can sometimes encode your logic in types. Typing also helps reducing logic issues. But as previously said, it depends on what you're doing. I'm prototyping/researching a lot, and tests often hinder progress for me. Maintaining a backend in production is a different story.

And then there's me, who almost never writes unit tests 😬

(With strong typing I can minimize explicit tests, and I like to iterate fast, but I guess it really depends on what you're developing, backend in production that is not allowed to fail, is probably something different than a game)

Good that the Fediverse is just on the rise while these platforms are self-destructing (hopefully).