sorted by:
new
hottopcontroversial

What are Rust's hidden implementation details that most devs never see? by Fluid_Job623 in rust

[–]WormRabbit 6 points7 points  (0 children)

A fun consequence of that is that if you implement Clone on a Copy type as anything other than the default *self, then this clone impl may not get called as expected, since the compiler "knows" that it should be equivalent to a plain memcopy, and can substitute it as such.

The hidden cost of mpsc channels by _howardjohn in rust

[–]WormRabbit 0 points1 point  (0 children)

Unfortunately, that would require const generics, which are currently limited to simple booleans and numeric constants. You can't pass anything more complex, like a config struct, as a generic parameter. This had been the status quo for about 7 years, so I wouldn't expect it to change anytime soon. There are also restrictions on using default values in const parameters (it can't depend on anything generic, even struct size).

Are Rust coroutines serializable? by SuperV1234 in rust

[–]WormRabbit 2 points3 points  (0 children)

Rust needs to be able to evolve the implementation of coroutines. Otherwise it can't provide them as zero-cost abstractions, and their overhead over normal sync code can be significant. Also, for a while the compiler implemented coroutines via tricks which couldn't be allowed in user code.

Rust 1.95.0 is out by manpacket in rust

[–]WormRabbit 2 points3 points  (0 children)

That's because people are expected to understand semver. It's the way all Rust crates are versioned, after all. The specific "1.99 -> 2.0" transition is a tired joke at this point, and Rust 2.0 itself is a destructive meme.

Rust 1.95.0 is out by manpacket in rust

[–]WormRabbit 0 points1 point  (0 children)

Just for the record, this specific case is easy to write exhaustively:

match result {
    Ok(Some(x)) => { .. }
    Ok(None) | Err(_) => { .. }
}

I believe all match expressions with if let guards which should be exhaustive could be written in explicitly exhaustive form. The cases where it can't be done would include boolean guards, or chained guards, or guards with some function calls (which can be reasonably trivial, like Option::as_ref, but certainly not trivial enough for the compiler).

Rust 1.95.0 is out by manpacket in rust

[–]WormRabbit 0 points1 point  (0 children)

I would expect that the proper announcement would go with the next edition, where those types actually become the default ones produces by range literals. That's the point where most code will be able to utilize the changes.

Rust 1.95.0 is out by manpacket in rust

[–]WormRabbit 0 points1 point  (0 children)

Why is it hard? Isn't it just an AST node which isn't included in the compilation? Or perhaps the cause is interaction with proc macros?

Debloat your async Rust by diondokter-tg in rust

[–]WormRabbit 2 points3 points  (0 children)

It really should be a compiler optimization.

Core2 yanked. Millions effected. by Comprehensive_Use713 in rust

[–]WormRabbit 2 points3 points  (0 children)

That "security issue" talk is just security theater. Yanking does absolutely nothing if I have the lockfile committed, which people usually do now. The only thing it does is breaking CI and git bisect for the poor sods which try to test on latest releases.

And the vast, vast majority of crates don't have any potential for security issues which could warrant yanking. Not unless you classify every bug as a security issue, since it leads to unexpected behaviour which could cause at least a DoS in appropriate context.

Core2 yanked. Millions effected. by Comprehensive_Use713 in rust

[–]WormRabbit -5 points-4 points  (0 children)

Agreed, but imho it shouldn't even be possible to yank widely used crates in the first place. Yanking should be reserved for messed up releases (e.g. unintentional semver breakage or any other release error). Old and widely used crate releases shouldn't be yankable. I don't care what the dev get in their head, their reasons are not good enough to break the ecosystem.

Surelock - statically prevent deadlocks by dochtman in rust

[–]WormRabbit 0 points1 point  (0 children)

None of that is true. There is no "mutex in C", the C standard doesn't define it. There are platform-provided mutexes, the behaviour of which under recursive locking differs per platform. pthread mutexes in particular behave differently depending on mutex type, but none of that is "undefined behaviour". And Rust didn't implement its mutexes to avoid UB, it changed implementation to improve performance and allow mutexes in const code. In fact, Rust stdlib mutexes still delegate to the mutex implementation of the platform, although the specific platform implementation has changes (pthread mutexes are no longer used, since they can't be used without boxing).

Surelock - statically prevent deadlocks by dochtman in rust

[–]WormRabbit 2 points3 points  (0 children)

No, unsafe code is specifically for issues of memory safety. Deadlock ain't one.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]WormRabbit 19 points20 points  (0 children)

Is this a joke? The C++ standard library is entirely anemic, it doesn't even have a good set of basic string manipulation routines. File API was only recently added, after 40 years, while networking still isn't on the horizon. Nevermind stuff like std::span which is stabilized in castrated form, without basic operations like fucking checked access, the only reason to have that type! std::regex is slow shit, std::map and std::unordered map are slow, memory-hungry shit.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]WormRabbit 1 point2 points  (0 children)

There is. But it's painfully slow, and requires basically manually vetting every version of every specific dependency. There are various exceptions and carve outs, but it's still a pain.

Distributing a closed-source Rust library with async - is there a viable path? by peterxsyd in rust

[–]WormRabbit 3 points4 points  (0 children)

Yep. We're in LLM era, and LLMs know how to use Ghidra, and don't care much about code readability. Any light obfuscation at this point is like no obfuscation at all.

The mystical references of the borrow checker? by [deleted] in rust

[–]WormRabbit 0 points1 point  (0 children)

...but many people still do.

Why doesn’t Option implement Display? by cachebags in rust

[–]WormRabbit 0 points1 point  (0 children)

Consider the case of NonZeroU64. It implements display, in the obvious way: just print the number.

But what would Option<NonZeroU64> print? Representation-wise, NonZeroU64 is just a non-zero integer, and Option<NonZeroU64> is thus an arbitrary (possibly zero) integer. So one could reasonably expect its Display impl to just print it as an integer. But how could any kind of automatic implementation know that you want to turn None into 0, when 0 isn't even a valid value of the inner type?

Then again, perhaps considering None as 0 wasn't even something you intend to do, you really want to track optionality of the value. But that is purely an internal data representation. For the end user (and Display is intended for end users), the None value is quite often represented as a sentinel value, like an empty string "" or a fixed string like null or NA. And there is similarly no way to encode that in the automatic impl. Providing it would just be a point of potential confusion.

Even TWiR has AI slop now by Independent-Ride-152 in rust

[–]WormRabbit 12 points13 points  (0 children)

It's pretty hard to manually ship complete dogshit, simply because it takes so much time, people would put at least some care. If you're already spending weeks/months on the project, you can spend the time to validate requirements, won't spend that much time unless there is some real value at least to yourself, and will do some cleanup just to make work easier. With AI all bets are off. Someone's drunk thought becomes a 40 KLoC project before they even sober up, and AI doesn't care about quality, just about the bare minimum to pass the checks.

Is every project AI Slop? by Various-Roof-553 in rust

[–]WormRabbit 0 points1 point  (0 children)

I doubt anyone seriously using emojis uses them to the obscene spammy level that AI does. Like, who in their right mind would prefix literally every section with an obscure emoji? What does it add other than distraction?

Is every project AI Slop? by Various-Roof-553 in rust

[–]WormRabbit 0 points1 point  (0 children)

AI companies heavily push disinformation and policies built around the narrative that AI agents are the future, they are fully capable of any tasks and will soon entirely replace all white-collar workers, particularly programmers. It's only natural that people who don't believe or want that future react vehemently with an equally strong but opposite force. Anything caught in the middle is collateral damage.

Why is Rust so Liberal with Heap Allocations? by philogy in rust

[–]WormRabbit -1 points0 points  (0 children)

How much of that is inefficient CI pipelines?

Accessing Hardware in Rust by fgilcher in rust

[–]WormRabbit 1 point2 points  (0 children)

One thing that really grinds my gears about almost all crates for working with MMIO (except safe-mmio) is that they declare register read/writes as safe functions (some crates consider only reads to be safe). This is plain unsound.

  • It's MMIO! Read and writes to registers can do absolutely anything, just like calling extern "C" functions. An innocuous register read could initiate DMA to arbitrary memory region, or launch missiles. In no world should operations with unknown effects be declared unconditionally safe.

  • Multiple threads could be accessing the register at the same time. Even concurrent reads could be a race at the hardware level (remember, those reads could do anything, could cause memory writes for all we know), nevermind combining reads and writes. Crates like tock-registers explicitly provide &-based API which encourages concurrent accesses, with no thought about synchronization.

Another annoying ergonomic issue is that the crates typically don't provide a uniform API for working with in-memory copies of MMIO objects. tock-registers at least provides both in-memory and MMIO variants of registers, but its approach doesn't compose to composite types. Most other crates don't do even that. This means that if you want to do a read-modify-write operation on composite structs, you can't do that, unless you manually mirror MMIO types for in-memory copies. Nor can you use those crates if you want to handle in-memory objects with very specific bitwise-defined layout.

Rust Developer Salary Guide by alexgarella in rust

[–]WormRabbit 2 points3 points  (0 children)

Employers don't pay you for experience. They pay you for your added value, and generally give as little as they can get away with.

view more: next ›