Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)B

BB_C

@ BB_C @programming.dev

Posts
12
Comments
457
Joined
3 yr. ago

  • Leaving Rust gamedev after 3 years

    Jump

  • It’s the elitist neckbeard attitude the early linux forums were known for that’s still present in places like the Arch community.

    LMAO

  • Leaving Rust gamedev after 3 years

    Jump

  • The hacker news comments are as usual very good too

    lol

  • Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog

    Jump

  • p.s. I’m also curious if you have any actual evidence that these two are more reliable than gtk. It’s reasonable to think they might be, but I’d like something more than “they’re written in Rust and have fewer features.”

    I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).

    I didn't make any specific claims about imaginary reliability score points.

  • Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog

    Jump

  • iced or slint

  • Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog

    Jump

  • iced or slint

  • Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog

    Jump

  • The crash reporter has a very unique requirement: it must use as little as possible of the Firefox code base, ideally none!

    we already ship GTK with Firefox on Linux to make a modern-feeling GUI, so we can use it for the crash reporter, too.

    I'm almost hoping for some GTK-caused crashes. They can enjoy the native look and feel while debugging that!

    Maybe then they will learn how to stick fully to logical requirements instead of going for "meh big dependency" and "meh look and feel".

  • Removed

    Rust in Thunderbird

    Jump

  • Thunderbird is still going?

    What's next? Rust in Songbird?

  • Curl: Hyper, is it worth it?

    Jump

  • To be fair, the latest stable version of hyper until a few months ago (pre v1) did offer usable high level API. What you describe only strictly applies to v1 hyper which hasn't been around (in stable release form) for long.

    On the other hand, I'm not sure why the parent commentator thinks lack of too much core development is a bad thing, or why they think hyper "needs help".

  • Curl: Hyper, is it worth it?

    Jump

  • As a user of both libcurl (haven't followed it's development for years though) and hyper, I'd say either commit to making hyper the default at some point and make that a priority, or drop it altogether. And since there is no intention/plan to do the former, then latter does indeed follow logically.

  • Biome v1.7

    Jump

  • Yep.

    I think we are way past the point where a random release of a project that happens to use Rust as an implementation language would meet the "interesting" threshold.

    Being webshit-related doesn't help of course, but maybe that's just me.

  • How can Rust be so fast in the TechEmpower Web Framework Benchmarks?

    Jump

  • the shittiest

    subjective

    slowest

    nope

    Thank you for participating.

  • Security advisory for the standard library (CVE-2024-24576)

    Jump

  • Were there actually any real-world use-cases affected by this? Do any of them not deserve to be named and shamed irregardless of this vulnerability?

    If it was up to me, I would nuke the cmd custom implementation, leave some helpful compile error messages behind, and direct users to some 3rd party crates to choose from.

  • Ratatui Received Funding: What's Next? - Orhun's Blog

    Jump

  • Didn't read the post yet. But I've been keeping half an eye on Ratatui for a while. I decided to put off writing anything utilizing it because I was hoping things would move along here at some point. Nothing yet on that front, unfortunately.

  • pyo3 async runtime

    Jump

  • I don't have an informed answer, and may be you know all of this already.

    (I only used pyo3 once in one of my projects, and didn't know about this new experimental feature, I also only used it to call python code from Rust, which is the other half of the crate, so to speak.)

    https://github.com/PyO3/pyo3/blob/main/guide/src/async-await.md

    Python awaitables instantiated with this method can only be awaited in asyncio context. Other Python async runtime may be supported in the future.

    So the runtime here is from the python side. And my first guess would be that support doesn't extend to use-cases where special (Rust) runtime support is needed, like the typical io (and sometimes time) features of the tokio runtime that are often used.

    Maybe the reference to "Other Python async runtime" in the quote above is hinting at something that may support such use-cases in the future.

    If your Rust code doesn't work without using one of the enable_() methods here, then, that's probably your answer.

  • "Clean" Code, Horrible Performance in Rust

    Jump

  • No

     
        
struct Shapes<const N: usize>([Shape; N])

impl<const N: usize> Shapes<N> {
 const fn area(&self) -> f64 { /* ... */ }
}

    Bad article 🤨

  • Rust Digger: More than 14% of crates configure rustfmt. 35 have both rustfmt.toml and .rustfmt.toml

    Jump

  • Other than a couple already mentioned, I like match_block_trailing_comma. Besides the symmetry, trailing commas in general are good for potentially reducing diffs in the future.

    But really, I'm not that bothered.

  • Cranelift code generation comes to Rust

    Jump

  • Well, obviously that will depend on what defaults (and how many?!) a developer is going to change".

    https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles

    And the debug (dev) profile has its uses. It's just not necessarily the best for typical day-to-day development in many projects.

    I actually use two steps of profile inheritance, with -cl (for Cranelift) inheriting from a special release-dev profile. A developer does not have to be limited in how they modify or construct their profiles.

  • Cranelift code generation comes to Rust

    Jump

  • Yes. And to complete the pro tips, the choice of linker can be very relevant. Using mold would come recommended nowadays.

  • Cranelift code generation comes to Rust

    Jump

  • Forgot to mention, and this is tangentially related to my comments from yesterday:

    A paper from 2020 showed that Cranelift was an order of magnitude faster than LLVM, while producing code that was approximately twice as slow on some benchmarks. Cranelift was still slower than the paper's authors' custom copy-and-patch JIT compiler, however.

    Cranelift is itself written in Rust, making it possible to use as a benchmark to compare itself to LLVM. A full debug build of Cranelift itself using the Cranelift backend took 29.6 seconds on my computer, compared to 37.5 with LLVM (a reduction in wall-clock time of 20%).

    Notes:

    • It's easy to gloss over the "order of magnitude" part in the presence of concrete and current numbers mentioned later.
    • It's actually "orders of magnitude" faster.

    But the numbers only show a 20% speed increase!

    The unattended reader will be left with the impression that Cranelift compiles 20% faster for a 2x slowdown. Some comments below the article confirms that.

    What the article author missed (again) is that the biggest Cranelift wins come when used in release/optimized/multi-pass mode. I mention multi-pass because the author should have noticed that the (relatively old) 2020 research paper he linked to tested Cranelift twice, with one mode having the single-pass tag attached to it.

    Any Rust user knows that slow builds (sometimes boringly so) are actually release builds. These are the builds where the slowness of LLVM optimizing passes is felt. And these are the builds where Cranelift shines, and is indeed orders of magnitude faster than LLVM.

    The fact that Cranelift manages to build non-optimized binaries 20% faster than LLVM is actually impressively good for Cranelift, or impressively bad for LLVM, however you want to look at it.

    And that is the problem with researches/authors with no direct field expertise. They can easily miss some very relevant subtleties, leading the readers to make grossly wrong conclusions.