Collecting downvotes since before forums even had thank you's.
What serious Linux users buy GPUs based on raw gaming performance on release week?
I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.
My current GPU is an AMD/Radeon one because of that. But I'm reconsidering my position when my next hardware upgrade comes.
I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.
If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.
I’m getting Hans Reiser vibes from Overstreet
You would do good on a CoC board.
Friendly Advice: If you hang out in microblog platforms, especially mastodon, do it less. The echo chamber discourse there is not good for your sanity. This is general advice, not just for you, really.
Later: short summary of the conclusion of what the committee didn't do (read 307 minutes)
Fixed that for you.
If you read the post, you will see it explicitly stated and explained how the committee, or rather a few bureaucratic heads, are blocking any chance of delivering any workable addition that can provide "safety".
This was always clear for anyone who knows how these people operate. It was always clear to me, and I have zero care or interest in the subject matter (readers may find that comment more agreeable today 🙂 ).
Now, from my point view, the stalling and fake promises is kind of a necessity, because "Safe C++" is an impossibility. It will have to be either safe, or C++, not both, and probably neither if one of the non-laughable solutions gets ever endorsed (so not Bjarne's "profiles" 😁), as the serious proposals effectively add a non-C++ supposedly safe layer, but it would still be not safe enough.
The author passionately thinks otherwise, and thinks that real progress could have been made if it wasn't for the bureaucratic heads' continuing blocking and stalling tactics towards any serious proposal.
I’ll wait for the conclusion of what the C++ committee does
🤣 🤣 🤣 🤣
for multi threaded workloads there aren’t many options
Anyone who actually writes Rust code knows about tracing my friend.
We also have the ever useful
#[track_caller]/Location::caller().And it's needless to say that dbg!() also exists, which is better than manual printing for quick debugging.
So there exists a range of options setting between simple printing, and having to resort to using gdb/lldb (possibly with rr).
But yes, skipping debugging symbols was a bad suggestion.
With all the respect to the author and his
wildexperiments, that title does not match the linker-only focus of the content.So not only the post ended up with two (IMHO) bad recommendations (disabling debug info, building non-relocatable binaries with musl). But it also didn't mention other important factors like
codegen-unitsandcodegen-backend. Since you know, code generation is the other big contributor to the cycle time (the primary contributor even, in many cases). There is also other relevant options likeltoandopt-level.Let's assume that
opt-levelshouldn't be changed from defaults for no good reason.With
codegen-units, it's not the default that is the problem, but the fact that some projects set it to 1 (for performance optimization reasons), but without adding a separate profile for development release builds (let's call itrelease-dev).Same goes for
lto, where you can have it set to"full"in your optimized profile, and completely"off"inrelease-dev.And finally, with
codegen-backend, you can enjoy what is probably the biggest speed up in the cycle by usingcraneliftin yourrelease-devprofile.And of course you are not limited to just two release profiles. I usually use 3-4 myself. Profile inheritance makes this easy.
And finally, you can set/not set some of those selectively for your dependencies. For example, not using
craneliftfor dependencies can render the runtime performance delta negligible in some projects.Using the parallel rustc front-end might become an interesting option too, but it's not ready yet.
Another meme answer:
nu.I never actually used
nufor anything. But I've been thinking (unironically) thatnuwith its built-infrom_jsonandto_jsoncan be interesting.The use-case I had in mind is not games or anything like that, but some system or dev tools that traditionally utilized shell scripts, but are moving towards better languages like python. So I thought a single binary that embeds
nu, but also has a lot of sub-commands that implement a lot of sub-tasks in Rust directly, and with JSON used as an exchange format, the combination can be interesting.Now that I think about it more, this can work in both directions, with main execution being in nu (what I had in mind), or in Rust.
nueven has an lsp server, so the development experience should theoretically be good.You appear to be generally confused.
If you're using the multi-threaded work-stealing tokio runtime (the default), you are "talking threads". And if you aren't,
ArcandMutexwould be useless, irregardless of whether you're doing it right or wrong.Use libcosmic 😑
No, but seriously.. skip to the end.
Iced and Egui both can’t handle Arabic, which is a deal breaker.
Iced can handle Arabic shaping-wise when cosmic-text is used, but it can't handle the direction (yet). If you only need it for the interface, a shit workaround would be to prefix all text with an RLM (RIGHT-TO-LEFT Mark). This would left-align all text of course.
Iced takes forever to compile and iterate, maybe that’ll be fixed with dynamic linking.
Fast iteration is already fixed by using cranelift in your release-dev profile (or whatever you want to call it), and mold as a linker. The binary will be slower, but iteration will be much much faster.
Okay, something helpful instead: Did you try asking in the
rust:gnome.orgmatrix room mentioned in the project page?&Baris a reference to something. That something is either a part ofself, or a part of the static context. There is no other context because there is no runtime/GC. So there is no logical not-nonsensical scenario where this would be both a valid and a limiting situation in Rust. And this is why your surface analogy toIndexis invalid.If the return value may depend on something other than
selfor the static context, and still need to be reference-like, then the trait definition is wrong. It should either return aCow, or go for the obvious generalization of returningimpl AsRef<Bar>values. With that generalization, references,Cows, and more can be returned.There is also the possibility that the trait definition is right, and you (the implementer) are trying to break a (probably) deliberate constraint (e.g. the return value in
Indexbeing tied to&self).I would wager a guess that what you call an escape hatchet is considered a very bad C# style anyway (or will/should be). Just like how mutable statics are considered very bad in Rust 😉
Cowdoes not work when you are actually required to return a referenceWhat does that even mean? Can you provide a practical example?
(I'm assuming you're familiar with
Derefand autoref/autoderef behaviors in Rust.)Is what the author calls a C# borrow checker purely lexically based? The first error message gives that impression. And if it is, then it wouldn't qualify for any such comparisons with 2018+ Rust.
- Unconvincing use-case: why is returning an
Optionnot an option? - Unconvincing objection: what concrete problems are caused by utilizing
Cows? - Wrong demonstrated "solution": why would one have to create a value and leak it with each call instead of using one
LazyLockstatic?
Their indices start at 1
Why do you hate zsh so much? 🙂
Sorry, I thought you meant the use of
..in Rust is odd. So I pointed out that{0..9}and{a..z}is also used at least in bash and zsh. That's at least 10s of millions of users!I know of
..being used for appending by lua at least. So still not odd-ball I would argue, since the people who interacted with lua code in their life probably outnumber those who interacted with all functional languages combined.It’s not like it’s an odd-ball usage of the symbols, that’d be
..which I vaguely remember some language using.I take it, you don't bash/zsh/...?
Is this going to be re-posted every month?
Anyway, I've come to know since then that the proposal was not a part of a damage control campaign, but rather a single person's attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn't, and there isn't.
The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical
mushroomsguidelines and real specified and implemented profiles.The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.
So not only there was no concrete strike back, it wasn't even the empire that did it.
Maybe this is a reductionist simplification of it, but his point is basically that, at least in the context of rust, async code is explicit and easy to introduce in a blocking context by simply blocking on it, while blocking code is not explicit about how blocky it is (and it's not a binary), and thus, it's not trivial to know where explicit unblocks are needed in an async context.
Blocking on async code is usually done with
some_executor::block_on(), of which some very lightweight implementations exist, combined with the possibility of not requiring that the data's ownership be moved to the executor, nor is the data required to beSendable to other threads (an executor doesn't have to be a multi-threaded work-stealing one).Meanwhile, unblocking is done usually via
blocking::unblock()orsome_executor::spawn_blocking(), and doesn't offer such flexibility.
Such posts are more suitable as microblogs IMHO.
Anyway, string lengths are byte lengths, and indexing strings is actually not panic-safe. This is why we have (still-nightly) char-boundary methods now.
If you want to work on characters. use
.chars().count()and.chars().nth().And character boundaries are themselves not always grapheme boundaries, which is also something that you might need to keep in mind when you start writing serious code.
With all that in mind, you should realize, for example, that probably every string reversing beginner exercise answer in every language is actually wrong. And the wrongness may actually start at the underspecified requirements 😉