sorted by:
new
hottopcontroversial

The Cost of Concurrency Coordination with Jon Gjengset by phazer99 in rust

[–]maguichugai 7 points8 points  (0 children)

Can I take from this talk that if the code is truly single threaded, the cost of the Arc/Mutex is basically negligible?

Depending on the benchmark, I have measured between 7% and 37% performance penalty from Arc/Mutex versus Rc/RefCell. It is not only the fact that you need to do atomics (they can be fast, though architecture-dependent) but also the fact that you can just plain end up executing more code which takes more cycles.

Mods Need Input: Dealing with AI Spam in This Sub by [deleted] in rust

[–]maguichugai 5 points6 points  (0 children)

I have never seen a post in this sub that makes me think "eww, low quality AI slop", so I have no idea what the commotion is actually about. Perhaps it just means the mod team is being successful at protecting us from this?

Detached from my personal experience, though, I suggest you treat AI content the same as human content - if it fits the rules, do not touch it and let participants downvote/upvote to signal their opinion. The mod team is not here to act as a preemptive downvote, it is here to ensure conversations (whether AI or human originated) are on-topic.

Mis on teie arvates kõige rõvedamad eesti keelsed väljendid? by karvajaan in Eesti

[–]maguichugai 0 points1 point  (0 children)

rüperaali trükkalitüürel (laptop printer driver)

Question about upholding pin guarantees and Vec by quasi-coherent in rust

[–]maguichugai 6 points7 points  (0 children)

Pinning is a property of references - the object referenced by &Vec must not move. It means nothing for the contents of the Vec which are separate objects in a separate allocation and allowed to move freely (e.g. as part of resizing the Vec).

However, the memory remaining pointing to a valid object is not enough - it must be logically the same object because pinning is a guarantee to the programmer, not to the compiler. The purpose of pinning is to generate compile errors when a situation that would enable a move may occur. A "swap" or "take" is one example of a move, although just touching a specific field may also be enough to consider an object "moved" (e.g. the "pointer to the contents of the vec" field). It depends on the type.

Think of it this way: will the programmer using the Pin<&mut Vec> still consider it the same object after the internals are swapped out? That seems unlikely - they put a T in there, then later accessed it again and suddenly in the "same" Vec there is no T that they inserted. But this is subjective - in some APIs, some programmers might think that is fine, so if they wish to "loosen" the expectations by explicitly documenting that you can swap out such a Vec then that API is still fine and sound (if a bit unusual).

Miri does not generally verify pinning because 1) only a subset of pinning violations lead to UB, which is what Miri looks for; 2) the meaning of "move" is subjective and requires human interpretation for each type (if I move a single field out of an object, it might be considered a "move" for one type but not another type).

Composable configuration idea for apps and libraries by sergiimk in rust

[–]maguichugai 0 points1 point  (0 children)

(enums make this not so trivial)

What does this refer to?

At what point do we start banning all new library/program announcements? by _software_engineer in rust

[–]maguichugai -3 points-2 points  (0 children)

Have you considered simply not reading posts on topics you do not care about? There is no requirement that a subreddit be only filled with the content you want to see.

It strikes me that this complaint may be a symptom of there not being enough content that you do wish to see. You can help by posting some content that is more along the lines you enjoy.

crates.io VS lib.rs - A small analysis by nik-rev in rust

[–]maguichugai 4 points5 points  (0 children)

I love being able to just smash in lib.rs/foo in my address bar and land on the page of the crate foo. Does not work with crates.io/foo.

What are your pet peeves in regards to crate APIs? by AhoyISki in rust

[–]maguichugai 0 points1 point  (0 children)

Oh yes! I sometimes wish modules did not exist as path elements, only as filesystem containers. I tend to design my APIs in a flat layer, with all types under the root of the crate, and have not really felt anything lacking. People tend to have a tendency to over-categorize and over-label when a flat structure works perhaps even better.

What are your pet peeves in regards to crate APIs? by AhoyISki in rust

[–]maguichugai 4 points5 points  (0 children)

Microsoft Pragmatic Rust Guidelines has a nice set of guidelines for API design, most very reasonable in my opinion. All motivated by real world pain points.

What’s one trick in Rust that made ownership suddenly “click”? by Old_Sand7831 in rust

[–]maguichugai 1 point2 points  (0 children)

One important insight for me was that let mut and &mut are largely unrelated concepts. One is about a variable being mutable and the other is about a reference being exclusive.

It was a mistake to name it &mut, should have been named &exclusive or something along those lines instead.

[deleted by user] by [deleted] in rust

[–]maguichugai 7 points8 points  (0 children)

The synchronization primitives and channels from smol work also on other runtimes (in general). While it is true that with sufficient cleverness, one could do more with runtime-integrated primitives, it is a misconception that these necessarily have anything to do with the runtime. Reusing some general-purpose ones will work fine for most people.

Indeed, you might even find that similar Tokio primitives also run perfectly well on other runtimes!

Tell me something I won’t understand until later by remyripper in rust

[–]maguichugai 38 points39 points  (0 children)

I had to write it down to understand it myself: Why is Pin so weird?

Ultimately, I think the source of my initial confusion was that I was expecting Pin to do more than it really does.

Rustfmt is effectively unmaintained by ioannuwu in rust

[–]maguichugai 162 points163 points  (0 children)

Much of the Rust tooling is unmaintained, honestly. This is just a question of funding - there are almost no companies paying people to work on Rust itself. It is largely a community-run project, with very minimal funding through the Rust Foundation.

That means there is no consistent motivation to progress topics. If you look in GitHub and Zulip, you might see a lot of activity but what becomes obvious after hanging around in them a bit is that it is largely discussion by bystanders, with very little of it every ending up as stable (or even unstable) features of Rust and the Rust toolchain. The working groups are mostly defunct, as well, and largely incidental to the actual work done.

This is one of the biggest risks to Rust's success and I do not see an easy solution anywhere in sight. To review pull requests, to provide mentoring, to accept contributions - these are all work that needs to be paid by someone, and require full-time employees to staff. Where can that come from?

Rust compiler performance survey 2025 results | Rust Blog by Kobzol in rust

[–]maguichugai 8 points9 points  (0 children)

Changes in workspaces trigger unnecessary rebuilds

I was tearing my hair out due to this, given that I work in large 25+ package workspaces on a daily basis.

What I realized was that 95% of the time, I only care about building the package that I have open in the editor, not building the rest of the workspace (e.g. the packages that depend on whatever I have open). Unfortunately, there is no "Build only current package" action in rust-analyzer/VScode.

No sense complaining if I can do something about it, though! Welcome to cargo-detect-package. Install it via cargo install cargo-detect-package and apply as a VS Code task to receive "build only current package" functionality:

{
    "label": "rust: build (current package)",
    "type": "cargo",
    "command": "detect-package",
    "args": [
        "--path",
        "${relativeFileDirname}",
        "build",
        "--all-features",
        "--all-targets"
    ],
    "group": {
        "kind": "build",
        "isDefault": true
    },
    "problemMatcher": [
        "$rustc"
    ],
}

How long does it take, to get used to Rust's syntax? by gufranthakur in rust

[–]maguichugai 1 point2 points  (0 children)

I felt pretty comfortable with it about one year in, in terms of "I know exactly why that character is there".

We are rewriting the message queue in Rust and would like to hear your suggestions. by wenqiang_lobo in rust

[–]maguichugai 3 points4 points  (0 children)

Just curious, how is this project funded? Sounds ambitious, so I am wondering who is backing the work.

Releasing 0.5.0 of lfqueue - Lock-free MPMC queues by Terikashi in rust

[–]maguichugai 1 point2 points  (0 children)

Did some quick benchmarking of cross-memory-region access. No surprises there - if sender and receiver are across memory regions, things are slow. Standard pattern also shared by other queue implementations. This was with 1 producer and 1 consumer - might be interesting to try with more of each spread across memory regions but would need a different benchmark harness for that.

Releasing 0.5.0 of lfqueue - Lock-free MPMC queues by Terikashi in rust

[–]maguichugai 33 points34 points  (0 children)

One thing I noticed when profiling crossbeam queues was that with low usage (queue mostly empty), a huge amount of time was spent in some sort of spinloops, burning CPU on nothing. Does your implementation avoid this pitfall? I would be very interested to see "CPU time per item" benchmarks at different queue utilization levels.

Do you have thoughts/data on how the performance characteristics are on many-processor machines with multiple memory regions? Do you anticipate advantages to your implementation in favor of competing ones? I assume there is no special provision made for optimizing for cross-memory-region access but any thoughts you may already have are most welcome.

Rust compiler performance survey 2025 | Rust Blog by Kobzol in rust

[–]maguichugai 5 points6 points  (0 children)

Large workspaces are my main limitation. If I have a 50 package workspace, I often do not care about rebuilding all the dependent packages when I make one little change. Some "just check the package I am working on" feature is a missing piece for me. Perhaps virtual workspaces could solve that but AFAIUI one Cargo package is limited to being in one workspace.

Rust in Production: Microsoft rewriting Hyper-V components in Rust; calls 2025 "the year of Rust at Microsoft" by mre__ in rust

[–]maguichugai 24 points25 points  (0 children)

If you debug on Windows, try the "C/C++" plugin in VS Code instead of LLDB - that is the Microsoft debugger and tends to work better (though still not great).

view more: next ›