I always felt "for embedded" was always selling this crate short, or rather pushing potential users away who aren't aware some data structures here are useful in non-embedded scenarios.
I for example use the admittedly simple Deque (with its is_full()) method in one of my projects for pushing/popping tasks to/from a fixed-size thread queue, which one could argue is a very unembedded-like use-case 😉.
Forgot to mention that I wasn't exactly young at the time. We just didn't have reliable broadband internet back then in my neck of the woods. So I had to download ISOs and save them in a USB thumb drive in a uni computer lab.
Early Mandriva with KDE 3.4 or 3.5 I think, but I can barely remember anything with clarity. It couldn't have been bad though, since I haven't used Windows on my own devices since 😉.
From my foggy memory, I think it was good for my then nocoder self, easy to use, stable, relatively lite, and had good looks.
I missed the Mandrake and pre-Fedora Red Hat era, but not by much.
Be realistic. Filling out forms to get CI runners means no serious users will be attracted. They can just go to GitLab instead. And even then, a migration wouldn't be fully seamless.
Those are immediate show-stoppers before we get to contributor pool sizes and network effects.
My purist young self picked Gitorious over GitHub. I even vaguely remember the KDE presence there, so it was a trusted host with big(ish) betters on it. But it closed shop soon after, and that was a quick learned lesson.
I will be more intrigued by the first jj-native forge when it appears. I may even help alpha test it, as it may bring a breath of fresh air to the space, unless it's going to be AI buzz-filled. In that case to the trash blocklist it will go.
messy Result type just seems like a case of something that should’ve been handled already (or properly propagated up).
My point was that without flattening, "provide context and propagate" vs. "directly propagate" is always explicit and precise, and is obviously already supported and easy to do.
Use with functional chaining, as pointed out by others, wasn't lost on me either. I've been using Option::flatten() for years already, because such considerations don't exist in that case.
res_res??;
// or
res_res?.map_err(..)?;
// or
res_res.map_err(...)??;
// or
res_res.map_err(...)?.map_err(...)?;
With res_res.flatten()?, you don't know where you got the error anymore, unless the error type itself is "flatten-aware", which is a bigger adjustment than the simple ergonomic library addition, and can become itself a problematic pattern with its own disadvantages.
With all the surface false analogies and general lack of solid knowledge in the comments here, I truly hope that at least half of them are LLM generated.
This is cool and lies within my area of interests.
One thing that is not clear is if there will be a way to do playback outside of custom players. If a stream can't be trivially grabbed, and/or played directly in mpv (via ffmpeg library support or otherwise), this won't be very useful for me.
It would also be interesting to see how the video streams are encoded, if the GOP size is forced to 1 and it's all intra frames or not, and if it's not, how synchronization after recovery (where FEC is not enough) is done.
Hopefully this gets posted again when the code is released.
As someone who hasn't been following this, playing the connotation game (using "automatic" instead [partially] "implicit") is rubbing me the wrong way.
Otherwise, the keyword use seems too generic to be used for this. But I'm sure this has been bikeshedded already, and if it hasn't, it will be.
Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as "Rust makes it harder for a 'contributor' to sneak in LLM-generated crap".
/mj this post was an experiment to see If I should start posting from my personal jerk archive here. But exactly as I expected and anticipated given the visibility in public feeds, this community has decent traffic, but none of the culture, or any familiarity whatsoever with the meta-ironic jerking style of the OG community. The lack of a separate meta sub/community is also not helpful since it forces users to /mj inline. But that separate community would have been public too, possibly compounding the problem.
It is indeed when paired with an optimizing assembler, a sophisticated static analysis tool in its own right. And just like Rust, you have greybeards hating on such provided safety because "meh it's not close to the hardware anymore", like that old man Mel.
Thank you for the update.