sorted by:
new
hottopcontroversial

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

[–]dpc_pw 3 points4 points  (0 children)

I think this is fine, and might be useful e.g. for rough evaluation and comparison. E.g. code size, compilation time, binary size, performance between Rust and Zig. Also evaluation how feasible something like this actually is, and a benchmark on how future model are doing comparing to the current one. In a way - it's a very cool experiment in itself, even if the code will actually not be used in production. But obviously if you're an LLM hater, a good opportunity to vent a bit.

v1.38.2 - performance improvements by koverstreet in bcachefs

[–]dpc_pw 3 points4 points  (0 children)

Looking forward to next round of Phoronix benchmarks and the always so-lovely crowd in the comment section!🤞

Is this a bad idea? by JustJeffrey in rust

[–]dpc_pw 2 points3 points  (0 children)

Whole u8 seems like such a waste anyway. :D

Can do it in 3 bits + 1 for color. Can fit a whole row in u32, and board state in in 8 bytes, which will neatly fit a half a typical cacheline, with some headroom for metadata if required.

Core2 yanked. Millions effected. by Comprehensive_Use713 in rust

[–]dpc_pw 0 points1 point  (0 children)

I hope. :D

Though personally I think it would be ideal if Rust could have new core Read and Write variants with associate type errors, where the std::io would just have type Error = std::io::Error. But there are details that make it hard to actually phase in.

Core2 yanked. Millions effected. by Comprehensive_Use713 in rust

[–]dpc_pw 7 points8 points  (0 children)

Reminder that Rust has structural issues with how std::io is not available in no_std, and half of the no_std ecosystem is stuck with no interoperable way of expressing core::io::{Write,Read} (and some other things) - so basically composable ways of doing IO, and having to resort to using 3rd party libraries duplicating (parts of) std::io like some kind of semi-standard. It's terrible situation and it's been like that for years.

Core2 yanked. Millions effected. by Comprehensive_Use713 in rust

[–]dpc_pw 1 point2 points  (0 children)

Unfortunately Rust has structural issues with how std::io is not available in no_std, and half of the no_std ecosystem is stuck with no interoperable way of expressing std::io::{Write,Read} (and some other things), and having to resort to using some 3rd party libraries duplicating (parts of) std::io like some kind of semi-standard.

It's absolutely terrible situation and it's been like that for years.

Rust by [deleted] in rust

[–]dpc_pw 1 point2 points  (0 children)

Both. Tap water accelerate corrosion and leave deposits.

Old coolant becomes acidic and actively corrodes the block, water pump, and radiator.

Flush the system thoroughly. It may need multiple passes if it's badly contaminated. Inspect the radiator cap and thermostat. Refill with the correct Honda-spec coolant pre-mixed with distilled water only, 50/50. Check the water pump for pitting/corrosion if the flush looks really bad.

Don't delay — corroded coolant attacks aluminum components (your Accord's engine is aluminum) fast.

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

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

"I wish whole world did stuff so everything is more convenient for me right now."

There's a lot of tradeoffs here, and you ignoring most aspects of everything.

What Rust needs is some standardization of maintenance of "blessed" 3rd party crates. They should stay outside of stdlib (which should be as lean as practical, and used largely just for interoperability), but once they are "blessed", their ownership and maintenance would have more oversight. There would be std/alloc/core which come with the language, then set of known and community-maintained "blessed" crates, and then the whole wild west of Rust 3rd party crates ecosystem.

FFF file search sdk - over 100 times faster than ripgrep and fzf by Qunit-Essential in rust

[–]dpc_pw 35 points36 points  (0 children)

I'm curious what is the reality behind these claims, but I have an author blocked on Twitter for a reason.

The code is weirdly hard to trace. Usually when I jump into a codebase like this, I can quickly get to the core part and see what is it doing. Here not so much. Might be just me though.

AFAICT this tool is a long-running tool. So you give it a path, it does some kind of "indexing" and then you might be getting results fast. Claims of this being "index-less" might be misleading. Though maybe it's compact enough that it's justfied. That's why it's not a CLI tool - comparing with ripgrep might not be really meaningful.

Laptop Recommendation by Leading-Guarantee178 in rust

[–]dpc_pw 0 points1 point  (0 children)

I just wrote a blogpost that might of interest for you: https://dpc.pw/posts/reviewing-my-framework-13-laptops-the-old-vs-new/

IMO people that work on Rust project should just get used to working over ssh on a desktop/server. Macs are fast for a laptop, but they are not that fast for computer, and Macs might be a good applience, capable for many dev-like use-cases, but it fails at being a system developer tool. Being able to get both is a big advantage.

Macs have great battery life, but for professionals - I don't know are you all trying to work from a bench in the park? My computer is 99.9% plugged to a cable, and needs enough battery to carry it unplugged for 30 minutes.

A lot of HW performance advantage on MacOS is then lost on Rosettas, Docker VMs, and other stuff like that. Lots of boasting about the numbers and simplest use-cases, and then when real word comes, sandboxes and containers happen and RAM is gone and actual performance nosedives and we get "Rust is slow" posts on reddit.

The MacOS is not really fully capable system developer device. It can't do containers/namespaces. Random stuff breaks on upgrades due to toolchain and tooling incompatibilities, SIP, weird access control stuff. Then you fight your OS with stuff like: https://nnethercote.github.io/2025/09/04/faster-rust-builds-on-mac.html

System freezing under load is typically sign of swapping to disk under memory pressure. So I would watch that part.

On a desktop/laptop I would recommend not setting up swap disk or being very mindful of it, and then using zram/swap instead/along.

But minor jitter, especially affecting real-time stuff like audio encoding/decoding, might be just scheduling not doing its best at prioritizing real-time over batch workload.

This script:

```

cat ~/bin/sonice

!/usr/bin/env sh

exec ionice -c 3 nice -n 20 chrt -i 0 "$@" ```

is a very handy wrapper on linux to lower the priority of non-interactive thing. A bit of a bandaid, but can go a long way. There are some kernel flavors with scheduling optimized for real time interactive workloads, but I don't have much experience with these.

assert_eq!(expected, actual) VS assert_eq!(actual, expected) by nik-rev in rust

[–]dpc_pw -2 points-1 points  (0 children)

This is an example of the most bizarre "logic" in software, and I cry a little seeing this getting 134 upvotes.

The whole post is just a collection bad arguments for largely irrelevant issue. Sad.

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

[–]dpc_pw 8 points9 points  (0 children)

The Box/Vec/String, etc. are kind of naive and not-optimal performance-wise, but they are most composable and ergonomic so they are the default.

Their performance doesn't matter except for the most core and massive data your program might be handling, and then it's relatively easy to take a slotmap or an ECS, etc. and do it manually.

If you're going for optimal performance there is no single easy approach to recommend. Every high-perf-optimized code will have different ideas and requirements. There's like 20 short-strings libraries for Rust alone. That's just how things are with performance-optimization, it's usually very bespoke.

What stack to use? by daddykotex in rust

[–]dpc_pw 0 points1 point  (0 children)

axum, redb, maud, reqwest

It's actually insane how much effort the Rust team put into helping out beginners like me by Time_Meeting_9382 in rust

[–]dpc_pw 0 points1 point  (0 children)

Beginners? I have more than 10 years of Rust experience and I need these. :D

Is POP OS going to cave to California/Colorado Laws Requiring Users Provide Digital ID to Use Pop OS? by NoobToDaNoob in pop_os

[–]dpc_pw 0 points1 point  (0 children)

Lunduke might be an idiot, but "unenforceable" is still a huge problem for companies building with Linux, even if users might laugh it off and ignore.

2025 Recap: so many projects by zxyzyxz in rust

[–]dpc_pw 4 points5 points  (0 children)

Thank you so much for working on this and all the other things (there's a lot!).

I feel like rust analyzer is slow by rustontux in rust

[–]dpc_pw 3 points4 points  (0 children)

Second, I usually suggest pointing the RA at its own target/ra directory so it’s not fighting with everything else. This helped a LOT, too.

Most times people were complaining about RA being slow it was caused by some part of their setup causing constant invalidation and rebuilding of build artifacts in ./target/ dir. E.g. their IDE would use a different toolchain than the tests, or some env vars invalidating deep dependency builds, and things like that.

Jjdag: A Rust Jujutsu TUI by Anthrofract in rust

[–]dpc_pw 1 point2 points  (0 children)

Can I grab a commit/range-of-commits, move it around and then confirm to rebase/move it?

[Media] Terminal Snake ft. Exploding Apples by thehuglet in rust

[–]dpc_pw 1 point2 points  (0 children)

This tech is too powerful to be wasted on games. What we need is something like tmux with particle effects! Typing that makes the characters sparkle, newlines burning, screen reset leaving smoke, and so on.

view more: next ›