dtolnay

Author here. Yes, it is. It was literally made for libraries. Notably https://github.com/dtolnay/zmij and https://github.com/dtolnay/itoa use it to enforce that the libraries' public API is absent of panicking.

Unlike formatting, correct parsing involves high precision arithmetic.

Example: the IEEE 754 double closest to the exact value "0.1" is 7205759403792794*2^-56, which has an exact value of A (see below). The next higher IEEE 754 double has an exact value of C (see below). Exactly halfway between these values is B=(A+C)/2.

  A=0.1000000000000000055511151231257827021181583404541015625
  B=0.100000000000000012490009027033011079765856266021728515625
  C=0.10000000000000001942890293094023945741355419158935546875

  0.1000000000000000124900090270330110797658562660217285156249
  0.1000000000000000124900090270330110797658562660217285156251

For me the original https link fails with "SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG"

The http link redirected to safebrowse.io/warn.html where there is a "Proceed Anyway" link to get to the content.

[0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language.

[0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point?

[0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...)

[0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward.

[0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two.

[0:25:43] CH: Oh. Wow.

[0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.

I am quite sure I saw #01 at $10k earlier today and it's now higher, so I suspect he found out he initially misjudged what Destin's advice of "priced not to sell" would need to mean.

As a library maintainer, closing and empathetically conveying why a pull request is not a net benefit to the project is an order of magnitude more effort than what it takes to throw up not-well-motivated pull requests on someone else's project.

The formula is explained in https://thanks.dev/static/how.

Note that the search you linked also includes crates that only have "rust" in the description or readme, not just the crate name -- that is why it shows a much higher count.

On my machine `buck2 clean && time buck2 build :cxx` takes 6.2 seconds.

`bazel clean && time bazel build :cxx` takes 19.9 seconds.

  1  if (argc <= 2)
  2    puts("A");
  3  puts("B");
  4  if (argc <= 2)
  5    unreachable();
  6  else
  7    return puts("C");
  8  return puts("D");

It makes sense to me but I can see why the author would characterize this situation as "license to use an unreachable annotation on one code path to justify removing an entirely different code path that is not marked unreachable". In a different world one might expect A to be printed "before the UB happens".

http://www.modulecounts.com

The transpiled library now serves as the YAML backend for the widely used serde_yaml crate. Having serde_yaml be pure-Rust code instead of linking C is advantageous for painless cross-compilation as well as making downstream projects runnable in Miri.

https://github.com/dtolnay/unsafe-libyaml

    compile_error!("You meant to …");

This is not my experience at all; it's been extremely helpful for doing things outside the mold:

In a work codebase that is millions of lines of first-party Rust code with thousands of third-party Rust dependencies from crates.io, we're building with Buck not Cargo because that is what the rest of the monorepo uses for C++ and other languages. It's fantastic for this that all the third-party projects describe their dependency graph in the same standard Cargo manifest format and follow a standard project layout, even though our builds do not use Cargo, because we can programmatically translate them to Buck targets.

> something like 10% of the number of people who claim to love it have ever used it for any purpose

"Loved" specifically measures what fraction of people currently using the technology say they desire to continue using it next year. In the survey there is no such thing as non-users claiming to love it.

https://github.com/dtolnay/star-history

Here is a side-by-side comparison of graphs generated by star-history.com vs my tool: https://github.com/dtolnay/star-history/issues/8

You can distinguish a lot finer structure in my graph: coinciding with individual blog posts with not as much reach as something on Hacker News front page. That structure is almost entirely concealed in star-history.com by the cartoony graphs.

This idea is what I've seen get a lot of people lost, but it's pretty natural. By analogy, a DANGER HIGH VOLTAGE sign doesn't itself need to be dangerous or high voltage in order to be useful. If your DANGER HIGH VOLTAGE sign (the sign) is dangerous or high voltage, you'd probably want a second DANGER HIGH VOLTAGE sign pointing out this fact about the first sign. The same for Pin: if you're wanting the pinned pointer (the pointer itself) to not be Unpin, your pinned pointer would need to be pinned by some second pinned pointer.

I don't follow this train of thought; could you elaborate? Why would I want more unsafe code in my project because it's going to be there for longer? If anything I'd want the opposite -- longevity of the unsafe code being a reason against wanting more of it sitting around.

FWIW the primary use case of CXX in my work codebase is in long term hybrid-Rust-C++ projects in which dozens of libraries using CXX (in both directions) are going to be around for many years.

Some easy and efficient ways to return a vector (or similarly string) from Rust to C++ which do not involve moving it around in Rust:

1. A signature like `fn f() -> UniquePtr<CxxVector<T>>` i.e. a return type of std::unique_ptr<std::vector<T>>, which is trivially Rust-movable

2. A signature like `fn f(out: Pin<&mut CxxVector<T>>)` with a stack-allocated empty vector constructed by C++ for your Rust to write the elements into, which is pinned and never moved by Rust

3. A signature like `fn f() -> Vec<T>` returning a Rust vector i.e. rust::Vec<T> on the C++ side; rust::Vec has a fleshed out API in C++ allowing it to be used like a C++ collection, with iteration and indexing etc