The most important part of curl is the library, not the CLI tool. And the TLS backend is very much relevant due to varying features supported, different licenses involved, and varying levels of ease when it comes to building and distribution.

That’s when you’re providing binaries. Otherwise, you would have to be wary of potential compatibility issues with libcurl packages provided by different Linux distributions for example.

See CURLOPT_ECH for a recent and still evolving example of this.

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.

Another huh from me. Or maybe I’m missing something, because this should all be obvious.

The source of the standard library is a rustup component that everyone should have installed. As for crates, you don’t have to manually download any sources. Just add the crate as a dependency, and jump around definitions as much as you like. You can remove the dependency later if you decide to not use it.

this wasn’t easy for me to find

Huh! This is the internal ExitCode, and it’s two jump-to-definition calls away. The first to get to the public type definition, and the second from the public type’s struct field to the private type.

ExitCode is a struct, therefore it behaves like a type with many fields which define the types contained in the struct.

That’s a bit too off. structs in rust are product types. A struct may define zero or more fields. And fields can be named or not. if not, such structs are called tuple structs.

In the doc page, if you clicked on source, it would have taken you to the definition.

pub struct ExitCode(imp::ExitCode);

That’s a public struct with one unnamed private field. The type of the private field also happens to be private/internal.

As for why, usually the purpose is providing type safety, a unified interface,… etc. Notice how for example a windows-only extension trait is implemented that allows converting raw u32 exit codes into ExitCode.

So now you have exit codes possibly sourced from u8 or u32 values depending on the platform. And you need a safe unified interface to represent them.

I hope that’s an enough starting point.

I would move all struct members from Foo<false> into a “new” Foo<true> and return that?

Yes… if you don’t define Drop for Foo.

If you do, then you will have to either use mem::take()/mem::replace() with each field, or if you don’t mind unsafe {}, you can just do a trivial transmute. Justunsafe { transmute(self) } should work.

I’m stating the obvious here, but if you have ownership at the time of conversion, then you can just change the type, you don’t have to use dyn (a la impl Foo<false> { fn into_debug(self) -> Foo<true> {} }). That may require some code restructuring of course.

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.

Yeah, I got that.

I’m asking what would be the benefit of not using a single error enum for all failure reasons?

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

🤣 🤣 🤣 🤣

use-case?

naysayer

🙂

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.

It’s quite simple. Just remove the permalink field! If you are calculating it then no need to store it in the struct.

This is inefficient. It should be the other way around. Remove base_url and rel_permalink, and store permalink and the rel_permalink offset.

That way, you can get a zero cost &str for any of the three.

With all the respect to the author and his wild experiments, 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-unitsand codegen-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 like lto and opt-level.

Let’s assume that opt-level shouldn’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 it release-dev).

Same goes for lto, where you can have it set to "full" in your optimized profile, and completely "off" in release-dev.

And finally, with codegen-backend, you can enjoy what is probably the biggest speed up in the cycle by using cranelift in your release-dev profile.

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 cranelift for 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 nu for anything. But I’ve been thinking (unironically) that nu with its built-in from_json and to_json can 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.

nu even 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, Arc and Mutex would be useless, irregardless of whether you’re doing it right or wrong.

This is neither news*, nor majorly relevant. Having rustc_codegen_gcc as a rustup component is going to be way more relevant, and is much closer to delivery, just to give an example.

* The post itself (not the content of it) appearing on the official blog was sort of pleasantly surprising (brought tears to my eyes, i tell ya). Hopefully that was a result of maturity, rather than external pressure.

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.org matrix room mentioned in the project page?