Skip Navigation

Posts
65
Comments
606
Joined
3 yr. ago

  • I feel like that's an unnecessarily narrow view of what the fediverse can be. The fediverse is not only for any single particular social networking use case, like micro-blogging (Mastodon) or forums (Lemmy, Pyfed etc). It can be much more than that, and all of it at the same time. There's no reason why the fediverse should restrict itself to only certain social media use cases.

  • Not sure I understand - you think some of those things don't belong on the fediverse? What do you mean "one or the other"?

  • I know we love to hate on LinkedIn, but honestly there are plenty of reasons to want social features about employers and jobs. Reviews, salary discussions, union organization and all such stuff that employees could leverage against employers, for instance.

    Of course that's not what LinkedIn is largely used for because it's full of employers trying to brand themselves or influencers trying to make an image for themselves. But it could be different, I think.

  • but i assume the sheer amount of images/video takes up a lot of space

    You can adjust settings in Lemmy to not store other instances media like this, so this shouldn't be a big problem with the right config.

  • Already posted, duplicate post

  • Rust @programming.dev

    rust-lang/rust is adopting an LLM policy

    blog.rust-lang.org /inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/
  • Super cool! Hopefully that can resolve some of the long standing issues with the borrow checker.

  • Rust @programming.dev

    Wild Linker Release 0.10.0

    github.com /wild-linker/wild/releases/tag/0.10.0
  • Rust @programming.dev

    Soft-deprecating chrono and chrono-tz

    github.com /chronotope/chrono/issues/1768
  • I'm not really sure what you're asking. Or I guess I mean, it's a very broad question. Just start a project and get learning.

    If you have any more specific questions, feel free to ask!

  • Isn't it pretty obvious? Fastrand is not cryptographically secure, urandom provides that option.

  • Rust @programming.dev

    Casper's Blog – Why I forked rand

    casualhacks.net /blog/2026-07-27-why-i-forked-rand.html
  • Rust @programming.dev

    How to speed up the Rust compiler in July 2026

    nnethercote.github.io /2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html
  • Rust @programming.dev

    Ideas to celebrate Rust 1.100

    users.rust-lang.org /t/ideas-to-celebrate-rust-1-100/141454
  • Scenarios in gambling are rarely "purely random". I.e. the likelyhood of winning in poker depends on what you already got dealt and what other cards got dealt and so on. What does "purely random" even mean? Like a lottery with equal chance of winning for all participants? Yea that's gambling but just one kind of gambling.

  • working on a project where memory safety isn’t that important

    I can't really imagine anything where this is not the case, unless you're doing like... I dunno, small scripts for personal use or something? But why would you use Zig or C or even Rust for that, just do Python or even bash at that point? Python is memory safe and perfectly suitable for very small programs where static analysis gives little benefit.

  • ReleaseSafe which have runtime checks to prevent illegal behavior

    To prevent some illegal behaviour. Again, I'm not an expert on Zig, but as far as I understand, even Release"Safe" is not actually memory safe.

  • Saying that "memory safety is checked by tests" is basically saying "memory safety is not checked". Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren't buggy?

    Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?

    I also don't understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it's never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).

  • rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app

    That is not an "inconsistency". Crashing the application when you run out of memory is honestly in almost all cases the correct call and crashing is memory safe. Most applications can do absolutely nothing when running out of memory. "Handling" OOM is extremely complicated and most applications simply cannot handle it in any way.

    Of course low level stuff needs to sometimes actually handle this, but it's mostly an operating system thing. And Rust still allows you that control, it's just not the default behavior of the collections and such in the standard library, because again, it almost never makes sense to try to handle OOM. But if you really need that behavior, you can have it.

  • Agreed that it makes the transition from C easier, but I'd also say it makes the transition from C more pointless. I don't really know that much about Zig but from what I've heard, I don't really get the benefits - if you want a fast systems-level language without guard rails, why aren't you just writing C (or C++, if that's your thing)?

  • Can't argue with that

  • Why are you considering Zig instead of Rust? Or is it in addition?

  • Rust @programming.dev

    'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman

    www.zdnet.com /article/greg-kroah-hartman-linux-kernel-rust/
  • crates.io front-end and its accessiblity issue(s)

    Jump
  • Generally agree with the takes here and similarly befuddled that an unofficial site like lib.rs seems to be entirely better in almost every way than the official site. It's a bit disappointing.

    I've unfortunately seen first hand the stubbornness of some developers on the Rust project when I tried to contribute a minor thing myself. I perhaps just had a bad unlucky experience, but it turned me off from ever contributing again.

  • crates.io front-end and its accessiblity issue(s)

    Jump
  • it becomes possible to discover parts of the website that exist but you can’t access.

    This doesn't really apply as a concept to crates.io though, as all crates on the site are public. It seems kinda like security theater to be doing these 403s when all the data is public anyway. GitHub doing this makes sense as there are private repos.

  • crates.io: development update

    Jump
  • A code viewer for the actual uploaded code is much appreciated. The upcoming diff view sounds really useful too.

  • Rust @programming.dev

    Rewriting Bun in Rust

    bun.com /blog/bun-in-rust
  • Rust @programming.dev

    Together for a healthier Clippy | Inside Rust Blog

    blog.rust-lang.org /inside-rust/2026/07/06/unite-for-clippy/
  • Rust @programming.dev

    It's not me, it's the compiler!

    parsa.wtf /cast/
  • Rust @programming.dev

    Welcoming Wild to the Rust Innovation Lab

    rustfoundation.org /media/welcoming-wild-to-the-rust-innovation-lab/
  • Rust @programming.dev

    Sniffnet [network monitoring tool written in Rust] crosses 500k downloads

    sniffnet.app /news/500k-downloads/
  • Rust @programming.dev

    On OpenAI's Support for Rust - The Rust Foundation

    rustfoundation.org /media/on-openais-support-for-rust/
  • Rust @programming.dev

    zlib-rs in Firefox - Trifecta Tech Foundation

    trifectatech.org /blog/zlib-rs-in-firefox/
  • Rust @programming.dev

    The never type (aka !) may soon be stabilized

    github.com /rust-lang/rust/pull/155499
  • Rust @programming.dev

    burntsushi (author of ripgrep among others) was diagnosed with encephalitis

    burntsushi.net /encephalitis/
  • Rust @programming.dev

    Maintainer spotlight: Tiffany Pek Yuan (@tiif) | Inside Rust Blog

    blog.rust-lang.org /inside-rust/2026/06/03/maintainer-spotlight-tiffany-pek-yuan-tiif/
  • 3DPrinting @lemmy.world

    What 3D printer should I buy?