most non-Mac laptops have a spare slot for an SSD (and the original one is likely replaceable), with RAM being replaceable too. Why wouldn't the desktop prices apply here too?
I know a core developer (Marek) recently got a Framework 16 and submitted some fixes after early testing iirc - might be worthwhile chasing it with him
Thank you very much for this resource!
Reading through the article and the discussion here I was really surprised why nobody discussed using actually existing modules, this clarifies how far that is from a solution.
You should really post this as a separate Show HN story!
"Estimated finish by the year 5134" made me chuckle
And we just improved the waiting time by about 1000 years, by adding flux to the list of supported projects. But sarcasm aside, yes this is a bit of criticism of the c++ ecosystem that moves a bit too slow. Many libraries pride themselves with only using c++11/14.
> The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them "write good code", but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean that this is a desirable way to write code. I've often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.
The latter part of this is true for any strongly statically typed language (with Rust expanding this to lifetimes), which negates the beginning of this paragraph -- once you get things compiled, you won't need to refactor, unless you are changing major parts of your interfaces. There are plenty of languages that do not have this problem because it is a design choice, hardly something Rust can "fix", it's what makes it Rust.
This is the opposite of my experience with other strongly typed languages. They're easier to refactor, because when you change the types, say you delete a field, everywhere that field was used is a compile error. Clean them up and on your way.
The borrow checker is an entirely different beast. People forget that safe Rust allows a subset of programs. Finding the subset which does what you want can range from easy, to hair-pullingly gnarly, to provably impossible.
The author is asking for a "give me a break" feature. I would say that in a strongly typed functional language, this is akin to mutating objects. The author seems to wish for an unsafe option to locally turn off the borrower check. Is it something Rust could not offer?
You can always dip into raw pointers and come back up for a reference, or eg. do a transmute to a static lifetime. Absolutely not okay according to the language rules but it will compile and will probably also run without an issue if you're not doing something wrong in your code (eg. Wanting to keep a reference to a string while you also mutate it.)
I'm actually surprised that the author didn't seem to consider this much of an option.
having recently done similar day-and-night long suites of benchmarks (on a laptop in heat dissipation conditions worse than on any decent desktop), I've found that there is no correlation between the order the benchmarks are run in and their performance (or energy consumption!). i would therefore assume that a non-overclocked processor would not exhibit the patterns you are thinking of here
the total lack of sources and references (other than to the articles on this very blog) is annoying to say the least. is there anything at all to read on this alleged Elbrus influence on Itanium plans, in Russian or English?
