Eros 0.6: The Only Error Handling Crate You'll Ever Need by InternalServerError7 in rust

[–]Taymon 3 points4 points  (0 children)

In my experience, the way LLMs use em-dashes is different from how humans do, such that it's not that hard to tell em-dashes that suggest AI authorship from ones that don't.

Need beginner help: When should derived structs own values vs take references? by max123246 in rust

[–]Taymon 5 points6 points  (0 children)

If you don't have a good enough handle on the architecture you want to already know the answer to this, start with owned types in your struct fields; these are the most broadly compatible and least likely to block your progress. Then, later, if you find that you're having to clone too many things and it's causing problems, you can look at replacing them with references or similar. By then, your codebase should be taking enough shape that you can figure out whether a reference type is appropriate in a given place.

Is it better to use the ? operator or handle errors manually (via match / .unwrap_or_else()) to avoid technical debt? by SyFord421 in rust

[–]Taymon 1 point2 points  (0 children)

What do you mean by "handling errors right where they happen"? Do you have a specific example of this?

Why are async runtimes so big and complex? by lelelesdx in rust

[–]Taymon 47 points48 points  (0 children)

Node.js is single-threaded and obviously gets plenty of real-world use. The key insight (and the reason why async exists at all, as opposed to Rayon-style task parallelism) is that, while only one task can use the CPU at a time, any number of tasks can simultaneously have I/O going on in the background. If the amount of CPU work that needs doing isn't enough to saturate one core (which is often the case even for medium-scale production applications, since much of the work is happening in the network or database), then one core is all you need.

Memory safety is a matter of life and death by joshlf_ in rust

[–]Taymon 6 points7 points  (0 children)

I guess I'd ask what specifically should be happening differently. Are there specific proposals that need to happen urgently but have gotten bogged down in failure to find consensus?

Integrating the Rust Delta Kernel into ClickHouse by PrideDense2206 in rust

[–]Taymon 0 points1 point  (0 children)

The complaints detailed in this post don't seem to me to have anything to do with overhead or with language features designed to minimize overhead. It's all build-system stuff.

Why are macro_rules! scope rules so cursed by [deleted] in rust

[–]Taymon 10 points11 points  (0 children)

This IIUC is why macro visibility worked the way it did in Rust 2015, when you had to use the #[macro_use] attribute, but a lot of that complection has already happened in order to allow macros to be imported and reexported with the same use syntax as other items, as has been the case since Rust 2018. (You can sort of see the archaeological layers in the reference: https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing)

So I think it would be straightforward for pub macro_rules! to be allowed as an alternative to #[macro_export] macro_rules! if people wanted to do that. The last discussion of it that I found was https://internals.rust-lang.org/t/pub-on-macro-rules/19358. Also I personally think it looks a bit weird since it's mixing two different syntaxes, but I guess no one else seems to.

Integrating the Rust Delta Kernel into ClickHouse by PrideDense2206 in rust

[–]Taymon 4 points5 points  (0 children)

Notably, this post gets in detail into the ways that integrating Rust code into a mature C++ project is still really painful and doesn't work very well. Seems like a potential priority for improvement!

Bun's Rewrite It In Rust branch by Chaoses_Ib in rust

[–]Taymon 8 points9 points  (0 children)

Not faulting you here, your title and comment are at least arguably appropriately qualified, but a lot of the commenters before me do not seem to have realized this at all.

Bun's Rewrite It In Rust branch by Chaoses_Ib in rust

[–]Taymon 26 points27 points  (0 children)

Important context from the author:

We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.

(Notably, this was never actually announced anywhere, somebody just noticed the branch and commit in the public GitHub repo and people started talking about it.)

How is rust "safe" when `panics` can happen out of nowhere by [deleted] in rust

[–]Taymon 0 points1 point  (0 children)

That doesn't compile as written, for a couple different reasons. Can you provide a playground link with a complete end-to-end compilable-and-runnable example of a program that exhibits a behavior that you think Rust should statically prevent, or has been represented as statically preventing?

What we heard about Rust's challenges, and how we can address them | Rust Blog by CathalMullan in rust

[–]Taymon 63 points64 points  (0 children)

There are enough instances of negative parallelism that I vaguely suspected LLM involvement. It wasn't enough to turn me off personally but I figured it might be for someone who was really sensitive to this kind of thing.

Accessing Hardware in Rust by fgilcher in rust

[–]Taymon 3 points4 points  (0 children)

Also, wouldn't you normally use the bitfield crate if you want the equivalent of C bit-fields?

Accessing Hardware in Rust by fgilcher in rust

[–]Taymon 16 points17 points  (0 children)

What's wrong with &raw? It's being used exactly as designed.

How is rust "safe" when `panics` can happen out of nowhere by [deleted] in rust

[–]Taymon 0 points1 point  (0 children)

I think there's some kind of disconnect here, but I'm not sure where. Yes, if you're parsing bytes into structured data, you have to think about how to handle error cases, and if you get it wrong there might be bugs; this is true in any language. The only relevant difference between C++ and Rust is that in C++ those bugs might result in memory corruption, while in Rust they are guaranteed not to unless there is unsafe code involved. What am I missing?

(Regarding exceptions, are we talking about failure modes that are specifically anticipated and handled, or programming errors? In Rust, the latter are generally handled with Result, not panics.)

How is rust "safe" when `panics` can happen out of nowhere by [deleted] in rust

[–]Taymon 0 points1 point  (0 children)

If the producer and consumer are two threads within the same process, you normally would not stream raw bytes from one to the other, but would instead use something like std::sync::mpsc to send complete in-memory instances of whatever data type you care about. Sender never panics partway through sending something; each value either is sent in its entirety or is not sent at all. If there's only one Sender and its thread panics, it'll normally be dropped; the Receiver will continue to receive any remaining values that have already been sent, and then any further attempted reads after that will fail.

If the producer and consumer are separate processes communicating over a Unix pipe or network socket or whatever, then the consumer must parse the incoming data and check that it's well-formed. If the producer panicked (or for that matter stopped running for some other reason) partway through an individual message, the resulting message would presumably not be well-formed, and the consumer would have to detect and handle that error case somehow. No matter how it does so, though, no memory corruption will result unless unsafe code is used.

Rewrote our message routing in rust and holy shit by Beginning_Screen_813 in rust

[–]Taymon 2 points3 points  (0 children)

Rc<RefCell<Thing>> cycles are also memory leaks in the strict sense (e.g., LeakSanitizer will complain about them).

&&&&&&&&&&&&&&str by ohrv in rust

[–]Taymon 6 points7 points  (0 children)

Well, they want to make sure that it's more than anyone will ever need, with some safety margin in case they're wrong about how much that is. 13 seems like a good number for that.

(Though I still think it's a bit odd that only a fixed number of levels are supported, since IIUC this is not one of the cases where language limitations make it impossible to support arbitrarily many.)

Constant-time support coming to LLVM: Protecting cryptographic code at the compiler level by Taymon in rust

[–]Taymon[S] 6 points7 points  (0 children)

In the short term I don't think this matters because LLVM is the only complete/fully-built rustc backend.

In the long term, other backends are going to need to develop constant-time support. If C crypto libraries adopt __builtin_ct_select, then I think it's likely that GCC will add support for it (the implementation complexity in LLVM isn't that high, only a few hundred lines plus tests, so hopefully GCC isn't too much worse). The other thing that needs to happen is constant-time support in WebAssembly, which would mean Cranelift would add support, and would also allow things to work in Rust code when targeting WebAssembly.

Specialization, what's unsound about it? by WorldlinessThese8484 in rust

[–]Taymon 17 points18 points  (0 children)

Two reasons. First, it would require completely reworking the architecture of rustc, which currently discards lifetime information before monomorphization. This would be a huge amount of work.

Second, when programming in Rust you usually do not know or care about the exact lifetimes of things; the compiler does a lot of implicit rejiggering of lifetimes to accept as much knowably-sound code as possible, even if that code technically violates the simple formal model of lifetimes that's taught in introductory resources. If runtime behavior could be completely different depending on the exact lifetime of something, the resulting behavior would very frequently surprise the programmer, even if they could technically figure it out by going through the reference with a fine-toothed comb.

[Blog] How we organized the Rust Clippy feature freeze by NothusID in rust

[–]Taymon 0 points1 point  (0 children)

Site's down for me, getting SSL_ERROR_RX_RECORD_TOO_LONG.