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)
implement object oriented programming in C is kind of absurd
Well IMHO OOP or specifically inheritance in general is absurd (hard take I know, I have had my traumatic experiences with inheritance hierarchies and refactoring/maintaining them - hell...).
I have done that (vtable OOP emulation in C) in my early years as CS student (like hmm I think 10 years ago?). It was fun experimenting with it, but ultimately I think C should be done imperative/procedural and modular composition of functions, and as such expose an API that is based on that.
I do for my GUI Toolkit written in C
Funny, I'm currently contributing to something similar in Rust :). Recently it also came up how to achieve cross-language bindings, Raph did prototyping for python a year ago in https://github.com/linebender/druid/tree/idiopath_py
I don't think I would go an inheritance based route for a GUI toolkit/framework. Inheritance was IMHO generally a mistake in programming paradigms (at least this strong integration/promotion in most modern languages), too strong interconnected dependencies where they don't make sense and constantly shoot you in the feet.
I think in times where React, Flutter, Jetpack Compose and SwiftUI etc. dominate (IMHO for a good reason), I would go into the direction of composable and declarative reactive UI. Make widgets strongly configurable on a fine-grained basis, and offer high-level bindings, but don't offer more. In case that is an issue, I'd extend the core or maybe offer a way to natively extend the toolkit (e.g. because of performance, better integration/architecture/maintainability etc.)).
Sure, but I think it's rather shows the shortcomings of C IMO, I could write C like Rust (no_mangle everywhere), and achieve the same, but than I would miss out a lot of the nice features of Rust that are missing in C (among one is better automatic compiler optimizations (e.g. vectorization, better byte-packing of structs etc. not even starting with all the functional features).
I don't think it's really an issue, you can get fancy within the Rust crate, and build a C compatible interface on top, that are just wrapper functions, and you likely think more about the API/interface to other languages which is probably not a bad thing, while having an idiomatic API for other Rust crates.
But I agree, that it works better to just stay in the ecosystem of Rust (you can provide a nicer API/interface for your crate with generics/traits etc.).
Anyway I don't completely get what you mean with "extensible from any languages"?
Yeah but you can achieve this with Rust as well with extern "C" and #[no_mangle] (I couldn't really go back to something like C anymore IMHO, all the high-level language niceties and a really good static type system, while maintaining the power of C...)
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).
(Nor anything else...)