487 karma · joined May 3, 2012
https://dystroy.org
I suggest everyone to have at least a short glance at the introduction at https://dystroy.org/broot/
We don't have software driven vehicles, we have software driven humans.
In France, when I helped an old lady who had slipped on ice, the emergency services were on site in less than 5 minutes, with all the competences and material to provide life saving interventions. And this was just normal.
Why does it look normal in the US to have to wait 20 minutes after having called for a gunfire, and only for a transport ambulance ?
IMO good rust code often
- has most types, functions, macro definitions, etc. correctly commented (don't bother reading code when there are pages without comments)
- has a lot of code snippets in function comments
- has some test units
- has no unjustified `unwrap` and `expect`
- has understandable error management
- has "bench", "tests" and "examples" directories (they're not always necessary but if you see them, the author knows the tools and made some efforts in building a better crate)
- has a proper readme and lib level comments (if it's a lib): people who take pride in a readable documentation often take pride in a good code
I'd also suggest to first look at code which is neither very old (people learnt since and new features were added to the language) nor so recent it didn't mature
For an already experienced programmer, it's hard not to think about using multiple threads, even when just starting in the language. I know my few first Rust programs were using multithreaded constructs and I found that especially easy to do safely in Rust (when I started, there was already crossbeam and rayon, both making a lot of things easier).
What you need (a feature, a performance improvement, etc.) is usually better served with other structures, especially in languages which don't heavily favor heap allocations (in a GC based language you've already paid the allocation cost when creating the object anyway).
I think there's now some evidence that Rust prevents developers neither from making efficient applications nor from efficiently making them.
I should probably have taken my own experience with broot rather than the linked list example (which hurts many fans of its theoretical beauty).
Until it clicks and starts to be natural, there might be a quite rough period.
Until you know the essential traits, how to find them, and you're used to clauses on generics, you may also have some difficulties making sense of some generic code or making your own generic code work.
There are a few articles on the links between those vaccines and tinnitus but right now it doesn't look like a deeply studied problem, nor even one physicians are interested into.
This looks simpler than listing a bunch of other UI, many non influential and none of them giving the answer.
Another option would be to wear a more efficient mask, a less leaking one. I find FFP2 to be quite convenient past the first few seconds when you're surprised by the difference of air flow. Those masks have the advantage of not moving, you don't typically have to adjust them and there's no fog on glasses.
Have you ever tried to pipe `tree` into `less` in a real code directory, with directories containing thousands of files ? That solves no problem.
The idea of broot isn't just to "be aware of the size of your terminal": its view is BFS based to show you a useful overview.
See explanation here: https://dystroy.org/broot/#get-an-overview-of-a-directory-ev...
I was reminded by this today as I installed Debian on a new computer. Why do Gnome makers imagine it's OK to have the *default* on slow ("Animations") rather than instant ? Do they really think we'll be happy enjoying a 200ms or 500ms delay every time we reduce or open a window ?