That's right, and buying new and taking very good care of your stuff + using to the point of being unusable probably beats serial-buying second hand devices you mistreat.
There has to be second hand users tough, otherwise the second hand devices that, for a reason or another, are not used to the end by their original buyer never get used again.
A friend of mine had a broken finger print reader (a few cents online), he couldn't find any repair shop who wanted to repair it (probably because the display would have to removed).
> I personally don't think it's worth it to buy a Fair phone for the extremely low chance that a component breaks and you can't get it repaired.
I might be misreading you, but this comes across a little like "that one use case doesn't prove you need a fairphone so don't buy a fairphone".
I don't think most people are evaluating tech like that. Only a zealot is going to consider a fairphone as the only option, they probably are looking at a bunch of criteria and options.
There's no correct answer to "what phone should I buy?" in a way that could be proven / argued for. I think people here are just saying fairphones have great repairability.
I'm addressing the intent of the original question.
No one would ask this question in the case where the struct is generic over a type parameter bounded by the trait, since such a design can only store a homogeneous collection of values of a single concrete type implementing the trait; the question doesn't even make sense in that situation.
The question only arises for a struct that must store a heterogeneous collection of values with different concrete types implementing the trait, in which case a trait object (dyn Trait) is required.
When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust!
(And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)
You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning.
In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been brought up as evidence in the first place.
Plus if things like work-stealing queues and complex synchronization are not relevant to editors, then editors are a poor example for demonstrating Rust's concurrency story in the first place anyway.
Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?
Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are.
To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law).
Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful.
The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
It reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer.
- "That's not even close"
- "Yeah, but it was fast"
Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty?
And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
I use a FP3 too, but I am a little surprised
reply