BB_C @ BB_C @programming.dev

Posts

10

Comments

366

Joined

2 yr. ago

First of all, sometimes I write in a stream of consciousness half-jerking style. It's not meant to be taken 100% seriously. I thought the writing style itself, when I do that, makes that clear!

Secondly, whatever that is of real technical value from the Ferrocene project, wasn't sold well by that ad. This could be by design, and maybe no one here would fall under the target audience of it. But then, I would question the point of posting this ad here in the first place.

Thirdly, the ad mentions nothing regarding Ferrocene's general availability (binaries, source, source+binaries, neither), nor is there any mention of software licenses. I think you would agree that mentioning this directly in the ad would have made it infinitely more informative for readers around here.

bureaucratic procedure

Not all verification/certification efforts fall under that banner of course. And some of them do provide value.

But the answer to your question is simply:
bureaucratic procedure

Funny you should mention that. Recently, glibc 2.38 was released with broken performance in its allocator API. Hell, one of the developers tried to argue the regression is good to force people to stop using the regressed API unnecessarily (the argument didn't go far, regressions got fixed).

Reports in the wild:
https://github.com/mpv-player/mpv/issues/12076
https://bugs.archlinux.org/task/79300

Links to the libc-alpha relevant threads can be found there.

Speaking of libc allocators, musl's allocator is also shit. That's why some Rust projects use another global allocator in their musl builds. Some of them probably haven't noticed yet that those builds are not static anymore because of that 😉 .

Ah, the good old RHEL promise of quality, stability, and security.

Can't wait for the CentOS Alma version... oh wait, no copyleft!

I will stick with arch rustc, thank you very much.

FYI, I had some time to check out hyper v1 today.

The new API of hyper proper is very low-level. Directly usable API is apparently moved to a hyper-util crate, which, as expected, does have a hard dependency on the tokio runtime.

So, while it's good that hyper proper won't hard-depend on tokio rt, it appears that non-tokio-rt usage will either depend on a higher-level 3d party crate, or a lot of effort from direct hyper dependants to write a lot of glue code themselves.

As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare.

I myself often use channels. And pass owned data around.

I don't think anyone argues that Arc+interior-mutation is ideal. But it's the over-the-top language like "complete nightmare" that some may take issue with.

Note that I again make the distinction between Mutex, and all interior mutation primitives. Because Mutex is indeed a bad choice in many cases. and over-usage of it may indeed be a signal that we have a developer who's not comfortable with Rust's ownership/borrowing semantics.

You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).

• Same note about Mutex specifically as above.
• Avoiding deadlocks can definitely be a challenge, true. But I wouldn't say it's often an insurmountable one.
• What crate did you use for interior mutability, async-lock, tokio, parking_lot, or just std?

A good topic to chat about.

But before that, I should mention that I had to use the browser's inspector to disable that background color. Light and dark backgrounds are both fine (I have color inversion bindkeyed after all). It's the ones in the middle like this one that are a no-no.

And while you could exclusively use the runtime and ignore the rest, it is easier and more common to buy into the entire ecosystem.

Stats? User surveys?

I would expect that many users (including myself) actually just use the runtime, directly or indirectly (e.g. via async-global-executor with the tokio feature), while API usage is covered by crates like async-io, async-fs, async-channel, blocking, ...etc.

In fact, I would hypothesize that, from an ecosystem adoption POV, tokio's only killer feature is hyper's dependence on it. If it wasn't for that dependence, tokio's adoption, I would expect, would be much lower. But this is admittedly anecdotal.

Any time we reach for an Arc or a Mutex it's good idea to stop for a moment and think about the future implications of that decision.

This and the quote above it seem to be Rust intellectuals' flavor of the month position.

It kind of reminds me of the lowering dependencies' compile times craze from a few years ago. Stretching the anti-MT-RT narrative to the point of making bad advice like recommending sync channels for an IO task adds to the parallels.

The choice to use Arc or Mutex might be indicative of a design that hasn't fully embraced the ownership and borrowing principles that Rust emphasizes.

Or maybe you know, using APIs that already existed in std for a reason, as intended!

It's worth reconsidering if the shared state is genuinely necessary or if there's an alternative design that could minimize or eliminate the need for shared mutable state.

Generally true. But probably false here.

People reaching for Arc+Mutex/RwLock/... (doesn't have to be a Mutex) in asyc code are probably aware of alternative designs, but still decide to use Arc+Mutex/RwLock/... when it's either necessary, or when it actually makes things simpler, and the downsides (performance) are of no measurable relevance, or the alternative design is actually slower (i.e. the multi-threaded runtime is actually helping).

I would consider arguments that talk about "killing all the joy of actually writing Rust" in this context as either intellectual posturing, or simply disingenuous.

Otherwise, there is not much to disagree with.

• Enabling features via Cargo.toml => bad
• Blanket enablement of preview features => bad
• Preview features in stable => bad (anyone taking bets on what will be the first perma-preview feature)!

There is prior art that wasn't mentioned that I think is relevant. It's rather obscure though, so it's understandable that it was missed. It's called "The Alpha Version".

Alright let me explain it a bit, since I expect no one heard of this before. Alpha versions are like pre-beta versions that are not nightly. They are used at the start of a release cycle, but without any stability guarantees. You don't need a very good reason to pull a feature, like with betas. Just a reason would do.

If everything goes well, the release cycle continues with the new to-be-stabilized features. If it doesn't, stabilization candidates can be pulled and their inclusion postponed to the next release cycle or beyond.

So instead of immediate Stability Proposals, we can have Alpha Inclusion Proposals for the V+1 release cycle, at the start of the V release cycle. Accepting/Rejecting proposals happens at the start of the V+1 cycle. A Stabilize/Postpone decision is made before the first beta. The release cycle can be extended from 6 to 8 weeks if needed so people have enough time to play with alphas.

So instead of nightly => stable (beta) => stable? (stable).

We can have nightly => stable candidate (alpha) => stable? (beta) => stable? (stable)

Pretty novel stuff, I know. This way, people can test stabilization candidates alone in a non-nightly setting, and report feedback. Lack of enough feedback may be used as a "good enough" reason to postpone stabilization!

Here you go, preview features in a release, but not a stable release. And no possibility (ok, less possibility) of previewise-and-forget and perma-preview stuckness for some low-visibility features.

Especially when dealing with ffis things get very muddy very fast.

True. But an ffi biding API leaking resources (memory or otherwise) is a bug in that binding. This holds true for any RAII-using language, including C++. I don't think faulty Drop implementations have anything to do with the subjects covered by the article!

I feel like, in 10 or so years, there needs to be a breaking edition addresses some of these concerns.

Maybe 10 years would be enough time to figure out how to release a new version (not edition) of Rust, with older versions being external to the new one with some ABI guarantees! That is if the problems accumulate to a level where it would be felt that this needs to be done.

Leaking might be safe, but not knowing that somewhere in the stack you’re forgetting values is so hard to know when you want to build very long running programs

Apologies if I 'm missing something obvious, but..

What do you mean? How do you not know about forgetting values? Wouldn't you have literally called mem::forget() on them?

Or do you mean values that stayed alive longer than you expected? That's a whole nother story. But these are not forgotten. They are still alive because they need to be. And the onus will probably still be on you to figure out why, because these new additions, if implemented, will only be of use in limited applicable scopes.

Or maybe new/better build-time and/or run-time analysis tools will be of help. But those shouldn't be dependant on these new language additions either!

I think the point of the “BIG_GLOBAL_STATIC…” name is that global statics are bad, not that the syntax is ugly.

Yes. And my point was that there is an obvious way of sharing data besides passing static-refs, cloning, and using Arcs, which is moving data bidirectionally. That was conveniently, or ignorantly, glossed over by the coping gopher.

fn foo(＆big, ＆chungus)

is out,

async fn foo(＆BIG_GLOBAL_STATIC_REF_OR_SIMILAR_HORROR, sendable_chungus.clone())

is in.

Or maybe you know

fn foo(＆big, ＆chungus)

is out

async fn foo(big, chungus) -> (big, chungus)

is in

Or

    
async fn foo(big, chungus) {
  // ...
  tx.send((big, chungus)).await?;
  // ...
}

  

is in

Moving (movable/sendable) data is not limited by number or direction, you know. And that second one even makes use of them great Hoare channels! And gives us control on how long we hold on to data before sending it back (modified or not). But I digress. Let's go back to the important talking point that Hoare was right!

No. It's “don’t mix URI parses”.

Or if you want to be more specific, it's "make sure security-sensitive paths are maximally specified, safely constructed, and maximally typed all the way".

A combination of file:// URLs being under-specified, and a C library (and not any C library, but glib, a special level of shit) predictably offering crap interface and contract guarantees (and hidden bugs to boot, yay).

This reaching attempt for some shallow generic common wisdom explanation actually reminds me of my first ever Lemmy discussion, where URLs were also incidentally involved.

I'm arguing (humbly of course) that intended vs. unintended use of what is at the end of the day a part of the public interface shouldn't be taken into consideration by default. Otherwise, other cases can be argued as non-breaking too!

Foo was never meant to be sent to other threads, So, losing Send is not a semver- breaking change!

Exhaustive enum Bar is only meant to be matched exhaustively internally. We say so in the docs. So adding a variant to it is not a semver-breaking change!

And giving more powers to a (kludge) doc attribute just doesn't seem in my eyes to be a generally wise move.

A: cargo-semver is still complaining about this item which I already have cfg-ed under an exp_api crate feature (which I don't want to rename). CI is failing.

B: PRO-TIP: Just slap a #[doc(hidden)] on it and CI will pass!

A: What if I still want to see the docs?

B: We are pushing for document-hidden-items to stabilize soon. So you can just simply use that!

Good work.

"Just don't write bugs" ( or "Just don't write semver violations" in this case) is now rightfully recognized as a joke proposition by many (although derivative ability/experience arguments are sometimes still used, UNIRONICALLY). But it's the "better education" (or its sister magic pill "better docs") that still has many believers. So it is still valuable to explicitly make the argument for reliable automated tooling as the only real logical solution. But I digress.

if our Example enum above was #[doc(hidden)], adding a new variant would not have violated semver.

Violations in #[doc(hidden)] items should definitely trigger errors by default IMHO. To give what was a kludge in the first place more powers is not something I would call wise. Not to mention, module source code is just one click away from html docs, and it's also one click/key-combination away from a crate user's editor/IDE with LSP (rust-analyzer).

So

how #[doc(hidden)] items sometimes have semver obligations after all,

I would argue it's always the case, unless the user of the tool explicitly decides it's not.

Maybe create a separate "Rust Drama" Lemmy community for such posts!

Languages: Just Rust!

You got my attention.

    
fn app(cx: Scope) -> Element {
    let mut count = use_state(cx, || 0);

    render!(
        rect {
            height: "20%",
            width: "100%",
            background: "rgb(233, 196, 106)",
            padding: "12",
            color: "rgb(20, 33, 61)",
            label { 
                font_size: "20", 
                "Number is: {count}"
            }
        }
        rect {
            height: "80%",
            width: "100%",
            background: "rgb(168, 218, 220)",
            color: "black",
            padding: "12",
            onclick: move |_| count += 1,
            label { "Click to increase!" }
        }
    )
}


  

Oh, it's stringly-typed Rust.
Yeah, no thanks.

Misuse/Overuse of the word "federated" is apparently all the rage in 2023.

Funny, considering in Leipzig's case, most plasticism exists on the anti side, especially with non-Germans playing pretend traditionalist.

Bonus points when it comes from an EPL old-money big 6 fan.

thnx for pointing that out bruv

the joke went completely over my head like

thought it was a real group L and Chelsea was accidentally written instead of Sporting or Leverkusen