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
456
Joined
3 yr. ago

  • Bugs Rust Won't Catch | corrode Rust Consulting - Analysis of Rust Coreutils (uutils) Bugs

    Jump

  • That's a question of API, not type system. And FD types (e.g. OwnedFd, BorrowedFd) are already in std.

  • Memory Management: Ownership vs. Reference Counting

    Jump

  • "Fearless Concurrency" predates "async" in rust nomenclature, and points to specific compile-time guarantees around things like thread safety and races (Send, Sync, ...).

    It was around when we used event loops and the mio crate (and rayon for parallelism), with no async or await in sight (because they didn't exist yet).

    Some people actually still prefer to do "concurrency" this way, especially if they wish to stay close to the abstraction level from C land. io_uring also came later which introduced a new OS low-level interface and paradigm for doing "concurrency".

    "Fearless Concurrency" has nothing to do with how easy you can write async code, especially if you're someone who struggles with the language basics like ownership.

  • An update on rust-coreutils in Ubuntu

    Jump

  • There is the odd (genuine) security issue tbf. But they are more of the variant:

    "If an attacker is close enough to sneak that on me, then I'm probably already screwed."

  • An update on rust-coreutils in Ubuntu

    Jump

  • Why are you hallucinating facts?

    • There is no "team of 200 rust developers".
    • "

      <lang>

      developer" is not an identity.
    • uutils is not a "professional" project, as in people are paid by the (non-existing) uutils company to work on it.
    • The project started as personal hobby of one person during COVID, There were no 200 contributors who sprung up magically and simultaneously from the start.

    They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.

    If you think you saw a group of 200 people starting uutils and doing this. You should seek medical help.

  • An update on rust-coreutils in Ubuntu

    Jump

  • The "reported upstream" link is broken (fixed link).

  • I accidentally made the fastest event system in the world

    Jump

  • Why does emit() take an owned E value?

  • A video arguing C++ is the worst programming language to ever exist

    Jump

  • mostly compatible with C

    It's not mostly compatible, not even on the surface level, with any version of C post C89. And most of the ever-growing crap in the language came after the early years anyway, with constructs that are C++-exclusive.

  • A video arguing C++ is the worst programming language to ever exist

    Jump

  • compatible with C

    myth

  • Rust @programming.dev
    BB_C @programming.dev

    Slint 1.16 Released (GUI toolkit)

    slint.dev /blog/slint-1.16-released

  • specify build dependency of a feature

    Jump

  • I don't understand the problem.

      sh
        
cargo new tt-build
cd tt-build
cargo new --lib opt-dep
echo 'pub const NAME: &str = "opt-dep";' > opt-dep/src/lib.rs

  

      rust
        
// build.rs
fn main() {
    #[cfg(feature = "opt_dep_b_ft")]
    println!("cargo:warning={}", opt_dep::NAME);
    #[cfg(not(feature = "opt_dep_b_ft"))]
    println!("cargo:warning=none");
}

  

      rust
        
// src/main.rs
fn main() {
    #[cfg(feature = "opt_dep_r_ft")]
    println!("Hello with {}", opt_dep::NAME);
    #[cfg(not(feature = "opt_dep_r_ft"))]
    println!("Hello with none");
}

  

      toml
        
# Cargo.toml
[package]
name = "tt-build"
version = "0.1.0"
edition = "2024"

[features]
default = ["opt_dep_b_ft", "opt_dep_r_ft"]
opt_dep_b_ft= ["dep:opt-dep"]
opt_dep_r_ft= ["dep:opt-dep"]

[dependencies]
opt-dep = { path = "./opt-dep", optional = true }

[build-dependencies]
opt-dep = { path = "./opt-dep", optional = true }

  

      sh
        
% cargo run --no-default-features 2>&1 | rg 'Hello|warn'
warning: tt-build@0.1.0: none
Hello with none

  

      sh
        
% cargo run  2>&1 | rg 'Hello|warn'
warning: tt-build@0.1.0: opt-dep
Hello with opt-dep

  

      sh
        
% cargo run --no-default-features --features=opt_dep_b_ft  2>&1 | rg 'Hello|warn'
warning: tt-build@0.1.0: opt-dep
Hello with none

  

      sh
        
% cargo run --no-default-features --features=opt_dep_r_ft  2>&1 | rg 'Hello|warn'
warning: tt-build@0.1.0: none
Hello with opt-dep

  • Every dependency you add is a supply chain attack waiting to happen

    Jump

  • I will let you expand on this before responding to both:

    And also, cargo.toml has inconsistencies and double-standards.

  • Every dependency you add is a supply chain attack waiting to happen

    Jump

  • Not cargo per se, but even the tutorial for a cli-tool is like “setup clap, which has 20 dependencies and a kitchen sink”. The whole (cargo-centric) ecosystem is much like Node, with the same problems.

     
        
cargo new with-clap
cd with-clap
cargo add clap --no-default-features

  

     
        
% cargo tree
with-clap v0.1.0 (/tmp/with-clap)
└── clap v4.6.0
    └── clap_builder v4.6.0
        ├── anstyle v1.0.14
        └── clap_lex v1.1.0

    And also, cargo.toml has inconsistencies and double-standards.

    Can you expand on that?

  • Every dependency you add is a supply chain attack waiting to happen

    Jump

  • Why do you think cargo is a problem?

  • Is it bad form to patch a dependency?

    Jump

  • Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.

    The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what "patched dependencies" effectively are.

    There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.

    And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.

  • Is it bad form to patch a dependency?

    Jump

  • Then you could be forced to vendor everything. And if it's open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)...etc.

    And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers...etc).

  • Is it bad form to patch a dependency?

    Jump

  • This would depend on the language/ecosystem. It's worse for C and C++ than for example Rust because of packaging policies and ease of distributability.

  • Rust to C++: Implementing The Question Mark Operator

    Jump

  • I didn't read your post. But note that ? depends on traits /type classes with associated types (Try, FromResidual, and From), and is often implemented for sum types (e.g. Result, Option) with at least two variants containing Output and Residual type values.

    The FromResidual part does value conversion for the Residual, which is how you e.g. get auto-converted error values matching the return Result value. These converted error values are often themselves contained in variants in an enum/sum Error type.

    So neither an actual equivalent in C++ is possible, due to type system limitations/differences, nor whatever you tried to do is an apples-to-apples match, or even represents two fruits from the same basket.

  • Why have supply chain attacks have become a daily occurrence?

    Jump

  • how many real-world attacks happened since the XZ fiasco outside of the webshit ecosystem?

  • Fixing our own problems in the Rust compiler - Trifecta Tech Foundation

    Jump

  • Off-topic: The switching between light background for text and dark background for code is stupid and annoying. Either use dark for both, or light for both (so I can apply my custom inverse shader without hurting my eyes or breaking the reading flow). This back and forth switching is almost as stupid as using a background color with middle lightness, which I've also seen.

    This has been irking me for a while, so I decided to randomly whine about it now.

    As for the blog content. It's a weird collection of clippy bugs which covers basically the first half of the blog, then a couple of miri bugs and limitations. Then it finally gets to actual rust compiler stuff which just involves cfg_select (a nice to have) and c_variadic support (ffi use-case). So, IMHO, that title is a bit over the top, and it almost does a disservice to a lot of actual good and interesting work that is being done.

  • Fish Shell 4.6 Brings Better Emoji Handling, Bash Compatibility

    Jump

  • (I guess zsh, dash and probably oil?)

    zsh doesn't even share var eval syntax with bash (${(P)foo} vs. ${!foo})

  • Programming @programming.dev
    BB_C @programming.dev

    Wild linker v0.8 released (and updated benchmarks)

    github.com /davidlattimore/wild/releases/tag/0.8.0
  • Programming @programming.dev
    BB_C @programming.dev

    koto v0.16.0 released (koto is a scripting programming language)

    github.com /koto-lang/koto/releases/tag/v0.16.0
  • Programming Circlejerk @programming.dev
    BB_C @programming.dev

    When I found out even Rust needed the clib, it was like seeing an iron-clad fortress only to look closer and see it was being held up by sticks, ducktape, and prayers.

    github.com /rust-lang/rfcs/issues/2610
  • Programming @programming.dev
    BB_C @programming.dev
    OC

    Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead!

  • Rust @programming.dev
    BB_C @programming.dev
    OC

    Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead!

  • Rust @programming.dev
    BB_C @programming.dev

    Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language

    koto.dev
  • Programming @programming.dev
    BB_C @programming.dev

    Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language

    koto.dev
  • Rust @programming.dev
    BB_C @programming.dev

    kdl 6.0.0-alpha.1 (first version with a KDL v2 implementation)

    github.com /kdl-org/kdl-rs/blob/f67e3d2998dcf0d198b4d03be7b23062cab21723/CHANGELOG.md
  • Rust @programming.dev
    BB_C @programming.dev

    COSMIC ALPHA 1 Released (Desktop Environment Written In Rust From System76)

    system76.com /cosmic
  • Rust @programming.dev
    BB_C @programming.dev

    cushy v0.3.0 Released

    github.com /khonsulabs/cushy/releases/tag/v0.3.0
  • Rust @programming.dev
    BB_C @programming.dev

    slint 1.6.0 Released

    github.com /slint-ui/slint/releases/tag/v1.6.0