BB_C
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.
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:
- Isn’t Ferrocene going to be a downstream* certified compiler?
- Won’t that compiler need a software license?
- Won’t that compiler be packaged and distributed (a cloud-only offering would presumably be off the table, at least for “serious clients”)?
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.