Vorpal

joined 1 year ago
[–] Vorpal@programming.dev 3 points 7 months ago

The standard library does have some specialisation internally for certain iterators and collection combinations. Not sure if it will optimise that one specifically, but Vec::into_iter().collect::<Vec>() is optimised (it may look silly, but it comes up with functions returning impl Iterator

[–] Vorpal@programming.dev 0 points 7 months ago (1 children)

Please, send an email to lwn@lwn.net to report this issue to them, they usually fix things quickly.

[–] Vorpal@programming.dev 6 points 7 months ago* (last edited 7 months ago) (1 children)

Sounds interesting! As I don't know restic that this is apparently based on, what are the differentiating factors between them? While I'm always on board for a rewrite in Rust in general, I'm curious as to if there is anything more to it than that.

EDIT: seems this is already answered in the FAQ, my bad.

[–] Vorpal@programming.dev 14 points 8 months ago

I have read it, it is a very good book, and the memory ordering and atomics sections are also applicable to C and C++ since all of these languages use the same memory ordering model.

Can strongly recommend it if you want to do any low level concurrency (which I do in my C++ day job). I recommended it to my colleagues too whenever they had occasion to look at such code.

I do wish there was a bit more on more obscure and advanced patterns though. Things like RCU, seqlocks etc basically get an honorable mention in chapter 10.

[–] Vorpal@programming.dev 7 points 8 months ago* (last edited 8 months ago) (1 children)

Yes, Sweden really screwed up the first attempt at switching to Gregorian calendar. But there were also multiple countries who switched back and forth a couple of times. Or Switzerland where each administrative region switched separately.

But I think we in Sweden still "win" for worst screw up. Also, there is no good way to handle these dates without specific reference to precise location and which calender they refer to (timestamps will be ambiguous when switching back to Julian calendar).

[–] Vorpal@programming.dev 4 points 8 months ago

My guess is that the relevant keyword for the choice of OpenSSL is FIPS. Rusttls doesn't (or at least didn't) have that certification, which matters if you are dealing with US government (directly or indirectly). I believe there is an alternative backend (instead of ring) these days that does have FIPS though.

 

This is a Rust replacement for debsums (on Debian/Ubuntu/...) and paccheck (on Arch Linux and derivatives). It is much faster than those thanks to using all your CPU cores in parallel. What it does is check files installed by your package manager for changes and reports those on stdout.

This is a project I have been working on over the past few weeks. There are more details (including benchmarks) in the readme.

I normally don't advertise my open source projects (having users other than yourself is both a blessing and a curse), but since there was recent discussion on how to grow this lemmy group I'd thought I'd post it. Maybe it is useful to some of you.

I also spent quite some time on optimising this (including a lot of benchmarking, profiling and trying alternative solutions). In the end I'm happy with the performance, though I am considering io-uring for disk IO.

The main goal of this project is not actually the program produced so far, but to continue building this into a library (currently very little is exposed as pub, because the API will change). I have a larger project in the planning phase that needs this (in library form) as part of it.

[–] Vorpal@programming.dev 4 points 8 months ago

Another aspect is that calling a cli command is way slower than a library function (in general). This is most apparent on short running commands, since the overhead is mostly fixed per command invocation rather than scaling with the amount of work or data.

As such I would at the very least keep those commands out of any hot/fast paths.

[–] Vorpal@programming.dev 13 points 8 months ago

That assembly program the author compares to is waay bloated. This guy managed with 105 bytes: https://nathanotterness.com/2021/10/tiny_elf_modernized.html (that is with overlapping part of the code into the ELF header and other similar level shenanigans). ;)

All kidding aside, interesting article.

[–] Vorpal@programming.dev 1 points 8 months ago

The example FileDescriptorPollContext doesn't really work. What if my runtime uses io-uring instead of polling? Those need very different interfaces to be sound. How do you abstract over that.

[–] Vorpal@programming.dev 15 points 9 months ago (4 children)

Swedish layout. Not ideal for coding (too many things like curly and square brackets etc are under altgr. And tilde and backtick are on dead keys.

But switching back and forth as soon as you need to write Swedish (for the letters åäö) is just too much work. And yes, in the Swedish alphabet they are separate letters, not aao with diacretics.

[–] Vorpal@programming.dev 5 points 9 months ago (1 children)

Two tips that work for me:

  • After cargo add I have to sometimes run the "restart rust-analyzer" command from the vscode command pallette (exact wording may be off, I'm on my phone as of writing this comment). Much faster than cargo build.
  • Consider using sccache to speed up rebuilds. It helps a lot, though uses a bit of disk space. But disk space is cheap nowadays (as long as you aren't stuck with a laptop with soldered SSD, in which case you know what not to buy next time).
[–] Vorpal@programming.dev 3 points 9 months ago

Thanks for the clear and detailed explanation!

 

I'm not affiliated with the site, but I found this interesting. Especially the quite nuanced discussion about if rust is hard or not.

With my background in systems level safety critical hard realtime C++ (plus a bunch of functional programming as a hobby) I feel that the answer was no (for me personally). Basically learn about lifetimes and borrowing and then learn the syntax, done. (Async and unsafe are arguably harder, but again I had the requisite background for it to be mostly familiar, though haven't needed to write much unsafe yet.)

But it was very interesting hearing the other perspective as well! Why rust might feel hard if you have a background in JS/Python/Go etc.

And it was awesome to hear such a nuanced discussion on the Internet, that is truly a rare thing these days.

 

Lots of new features!

Thought I should share this with those who don't use users.rust-lang.org. Note: I'm not affiliated with lib.rs, I'm only reposting to lemmy.

view more: next ›