mandreyel

I completely agree. It’s depressing to see the whole thing steadily come apart at the seams due to their own leadership (or lack thereof, one could argue).

Actually I realize what I wrote above is less true now as they have fired a good number of their incredibly skilled engineers, many of them of course Rust developers. So I suppose my post should be rephrased along the lines of “what Mozilla should or could have done”.

[edit]: Rephrased to be less dramatic.

A possible alternative source of income for Mozilla I think would be, and one I haven’t seen mentioned before, providing consulting services in their areas of expertise.

For example, demand for Rust engineers seems to be steadily increasing[1] and I can’t think of a better company with a larger concentration of Rust expertise than Mozilla. Perhaps the same could work for other areas (ex frontend), but I’m biased toward Rust. Due to lack of experience in this regard I’m not sure if this could actually work, but I could imagine allocating part of their engineering time budget to consultation, whose income would fund their core products.

[1] Besides all the articles popping up about starting to employ Rust by well known companies, my anecdote as a full-time Rust SDE is that I’m getting more and more requests on LinkedIn, and not just for the usual crypto roles.

It's a valid point, I think. I'd probably also trust something so established as Boost more than some random guy's lib on GitHub. However, I specifically wrote mio because I prefer not to use Boost, and from what I understand, many others don't either.

Oh, I missed this response (still a little overwhelmed). I'm so glad I checked again because there is some precious wisdom in there. Thank you for taking the time to write it down. And it indeed seems like I was misusing mmap...well, next time I'll know better!

That is a great idea, thanks. Opened an issue on it.

Thank you for the kind words. I'll buy you a beer if we ever meet!

Hmm, I see, I haven't come across this suggestion but I may not have researched this topic well enough. I'll try your suggestion next time.

I appreciate the responses--learned something new today!

This is a valid point. My use case was very frequent reads of large files at pretty much unpredictable positions, so in theory mmap seemed justified. However, I never got around thoroughly testing this assumption, and may indeed just have been better off using read(2) and its variants.

You seem very experienced, so I hope you don't mind a question. In my use case the files were as large as tens of gigabytes and I was creating read-only mappings of 256KB-1MB chunks in them, keeping the mmap handles around according to a cache policy and RAM usage limit. Do you think in this case using mmap could in theory introduce performance gains?

[edit: typo]

This is definitely unfortunate, but in my defense I was not aware of Rust's mio (or anything related to Rust beyond its existence) at the time of writing and naming my library. I have no emotional investment in the name, so I'm open to suggestions should anyone take issue with it.

Author here. Long time lurker, but made an an account now.

Wow, I did not expect this. I'm really touched. I wrote this as a small utility for my own consumption because I was unsatisfied with the existing selection at the time, so I'm both surprised and delighted to learn that people are finding it useful. Although to be completely frank, I think this library is way too small and insignificant to deserve a spot on HN's front page, but it definitely made my day. So thank you kind stranger who posted it!