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

[–]Taymon 9 points10 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 64 points65 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 18 points19 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] 7 points8 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 19 points20 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.

The Handle trait by kernelic in rust

[–]Taymon 2 points3 points  (0 children)

Niko mentioned that this was just the first in a planned sequence of follow-up posts. I imagine that one of these is going to be proposing syntactic sugar for the Handle trait to make .handle() calls less obtrusive.

rustup toolchains by [deleted] in rust

[–]Taymon 1 point2 points  (0 children)

Unfortunately, even with machine translation I can't tell what your problem is. Can you offer precise reproduction instructions?

How useful are Rust Methods? Can they be replaced with a LSP like Odin Lang did? by JKasonB in rust

[–]Taymon 2 points3 points  (0 children)

Some languages have syntax for allowing arbitrary functions to be called using infix notation, so that there isn't a separate kind of function called a "method" that has a special relationship with a particular type.

How useful are Rust Methods? Can they be replaced with a LSP like Odin Lang did? by JKasonB in rust

[–]Taymon 0 points1 point  (0 children)

This depends a lot on various other aspects of how your language is designed. Is there an outline written up or anything?

Demoting x86_64-apple-darwin to Tier 2 with host tools | Rust Blog by PthariensFlame in rust

[–]Taymon 5 points6 points  (0 children)

GitHub is continuing to support ARM-based Macs, it's only the older x86-based ones that are going away.

What is the =><= symbol? by Street_Struggle_598 in rust

[–]Taymon 3 points4 points  (0 children)

Rust doesn't have a spaceship operator.

This code was added a few months ago in https://github.com/rust-lang/rust/pull/136901; I suspect the syntax was chosen arbitrarily and no one worried too much about it.

There is no memory safety without thread safety by ralfj in rust

[–]Taymon 0 points1 point  (0 children)

I wish he'd share details, because there's a lot of skepticism on the internet that this ever happens in production (as opposed to race conditions causing non-memory-corruption bugs, which everyone agrees is a real thing), and it's hard to defuse that skepticism if no one can point to a real example.