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

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

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.

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.

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).

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.

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.

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).

I don’t feel like rust compile times are that bad, but I’m coming from C++ where the compile times are similar or even worse. (With gcc at work a full debug build takes 40 minutes, with clang it is down to about 17.)

Rust isn’t an interpreted or byte code compiled language, and as such it is hard to compete with that. But that is comparing apples and oranges really. Better to compare with other languages that compile to machine code. C and C++ comes to mind, though there are of course others that I have less experience with (Fortran, Ada, Haskell, Go, Zig, …). Rust is on par with or faster than C++ but much slower than C for sure. Both rust and C++ have way more features than C, so this is to be expected. And of course it also depends on what you do in your code (template heavy C++ is much slower to compile than C-like C++, similarly in Rust it depends on what you use).

That said: should we still strive to optimise the build times? Yes, of course. But please put the situation into the proper perspective and don’t compare to Python (there was a quote by a python developer in the article).

Here are some I found and used in my own code:

• itertools
• regex
• anyhow and thiserror (error handling)
• indoc (indented/formatted multi line string literals)
• strum (various derive macros for enums)
• petgraph (for working with general graphs)
• winnow is a great (and fast) parser combinator library.
• bpaf, clap and xflags are three different command line argument parser libraries. Which one to use depends on the needs of the project and if you need to match the behaviour of an existing non-rust program (as I needed to in one case)

Saying “it’s a graph of commits” makes no sense to a layperson.

Sure, but git is aimed at programmers. Who should have learned graph theory in university. It was past of the very first course I had as an undergraduate many years ago.

Git is definitely hard though for almost all the reasons in the article, perhaps other reasons too. But not understanding what a DAG is shouldn’t be one of them, for the intended target audience.

1. Not for me. It is clearly not trying to be a systems programming language. And that is why I’m interested in Rust. I work in hard realtime (day job) and do embedded as a hobby.
   That rust is also useful higher up the stack is just a nice bonus to me which means I can keep using it when writing automation things that are too complex for a simple shell script (it has largely replaced python for this purpose for me now).

2. Rust gained momentum because it filled a niche that was unoccupied (systems capable but safe and high level). Oxide seems to be aiming for an area already occupied by Rust from one side and things like Go from the other side. That rarely works out.

Seems rather limited: only targeting some high level languages. Now, if this could also generate C++ bindings i would be very interested.

I really don’t see what niche it is trying to fill that isn’t already occupied.

Rust is as successful as it is because it found a previously unoccupied niche: safe systems programming without garbage collector and with high level abstractions that (mostly) optimise away.

I don’t think “better C” is a big enough niche to be of interest to enough people for it to gain a critical mass. I certainly have very little interest in it myself.

In my manual implementation I would assume you would use a newtype, so not really relevant.

Seems to be a wrapper around implementing the “index into data store”-pattern (not sure if there is a better name), but without support for removal from said data store.

From a quick glance I don’t really see what this gives you that wouldn’t also be quite easy with a manual implementation. And then you avoid the proc macro compile time overhead as well.

There are existing approaches: GNU gettext and Mozilla fluent comes to mind. I would try to use one of those. I understand that Mozilla Fluent has good support for the Web (unsurprisingly).

Your idea will work with minor changes (if comments are supported in your file format). At work our tooling create entries like 123="English text" // UNTRANSLATED. Obviously not quite the same format, but it should be adaptable to any format that supports comments.

Oh, this seems to be specific to the SQL framework you use after looking into it. I thought it was a general rust question about function parameters, sorry. Unfortunately I’m not familiar with that sql framework (or any other, I’m an embedded developer, not a web dev).

Hope you find someone who knows diesel, and sorry again I couldn’t help you.

Unfortunately your code here in this post is unreadable with the buggy html escaping in it. Consider posting to the official rust playground and creating a shared link. And/or report a bug to lemmy about the broken quoting.