As I discovered and mentioned here a couple of months ago, there is a new hyper-util crate that may/should bring a higher-level API interface back. It also predictably brings a hard dependency back on tokio rt. So there is that.
hyper-util was also just mentioned by Sean (hyper dev) in the discussion you linked.
What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian
[closes tab]
Should have told the auditors that stripping symbols is stupid and counterproductive instead of playing along. That segfault a user managed to hit once and only once with their self-built binary, and that useless core file that was left behind, shall hunt you in your dreams forever.
And I love how that commit was merged with the comment "A further reduced binary size! 🎉". Exhibit number #5464565465767 why caring that much about "dependency bloat" and binary sizes always was, and always will be, a result of collective mania in action.
deleted by creator
See! Unlike the post from last week, this post actually provides useful and actionable info.
Good luck to the Ferrocene team.
Is everyone genuinely liking this!
This is, IMHO, not a good style.
Isn't something like this much clearer?
// Add `as_cstr()` to `NixPath` trait first
let some_or_null_cstr = |v| v.map(NixPath::as_cstr)
.unwrap_or(Ok(std::ptr::null()));
// `Option::or_null_cstr()` for `OptionᐸTᐳ`
// where `T: NixPath` would make this even better
let source_cstr = some_or_null_cstr(＆source)?;
let target_cstr = target.as_cstr()?;
let fs_type_cstr = some_or_null_cstr(＆fs_type)?;
let data_cstr = some_or_null_cstr(＆data)?;
let res = unsafe { .. };
Edit: using alternative chars to circumvent broken Lemmy sanitization.
It’s not like RHEL
The parallels between this and RHEL (including RHEL derivatives like Oracle Linux) are maybe longer than you think.
it has nothing to do with licensing or even packaging/distribution.
Not sure what you mean. I don't think I implied that that's the point of certification.
But:
I think all of this is very much relevant info to know.
* "downstream" is the fifth word in the article/ad.
It’s also not something that Ferrocene needs to “sell”
Something is being sold by Ferrous Systems. I don't think that's a point of dispute by anyone!
Now, what that something exactly looks like will depend, in part, on the answers to the questions above, no?
in the sense of convincing users to migrate to it from rustc
I didn't argue that. I don't think anyone argued that.
In case you didn't realize, the quintessential Arch user wouldn't be the target of a RHEL sales pitch either 😉 .
And now any remnants of a joke are ruined by all the explaining.
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 that those builds are not static anymore because of that yet 😉 .
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.
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.
Cargo.toml => badThere 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!
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!
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.
Yay. My first ad-masquerading-as-a-genuine-post experience on Lemmy!
Thus, we’ve developed a cargo extension that transparently queries the Phylum API for information about a package before it’s allowed to build.
Only our* malware-like behaviour is blessed. Because it's a feature. And research-based. And security-oriented. And commercial! We told you about it beforehand and sold you the idea.
* Assuming the malware discovered is not theirs too.
Most specific and technically relevant point:
You can read more in the RIIR PR.