Runtime performance is entirely unaffected by the use of macros. It can have a negative impact on compile-time performance though, if you overdo it.
Might be relevant to mention that Rust has formal verification methods available as well, similar to SPARK, but also optional. One that looks pretty appealing is this one: https://verus-lang.github.io/verus/guide/overview.html
While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else
clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.
Issue resolved
I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async
thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.
0° being “very cold” and 100° being “very hot” is intuitive.
As someone who’s not used to Fahrenheit I can tell you there’s nothing intuitive about it. How cold is “very cold” exactly? How hot is “very hot” exactly? Without clear references all the numbers in between are meaningless, which is exactly how I perceive any number in Fahrenfeit. Intuitive means that without knowing I should have an intuitive perception, but really there’s nothing to go on. I guess from your description 50°F should mean it’s comfortable? Does that mean I can go out in shorts and a t-shirt? It all seems guesswork.
The System76 scheduler helps to tune for better desktop responsiveness under high load: https://github.com/pop-os/system76-scheduler I think if you use Pop!OS this may be set up out-of-the-box.
It’s a bit arguing about semantics really. But Rust and Haskell are merely the first ones with patches out. The issue affects other languages as well, including Java, Node.js, Python and seemingly every language with Windows support. I think it’s fair to call it a Windows problem, since it affects everyone there.
But languages like Rust and Haskell are promising their users that they are protected from this kind of behavior, which is why they want to patch it quickly. Some of the others merely updated the documentation, effectively saying yeah it’s a risk. Java went as far as saying they won’t fix the issue.
Good question! 😂 maybe I’m overthinking it, but you seem to be making the point that it’s silly for people to like WASM based on the argument the JVM already exists and people are not fond of it/Java. If that’s not the point, why did you make the meme at all?
Of course, technically you can compile anything to almost anything. But I don’t think linking to a project that’s unmaintained for 15 years really helps your argument.
Ah yes, exactly.