quodlibetor

It's available online: https://doc.rust-lang.org/book/second-edition/ , a publisher that didn't believe in digital sharing that also agreed to publish it would be a little... surprising.

That all makes sense, and the immediate return + threads solution you describe sounds like what I was imagining, I just didn't have the context to use the correct parts of the Erlang FFI. I'm glad that there is a pattern for that kind of thing!

> to write a NIF that could somehow yield back and then be "continued" later would be a royal pain.

I know... nothing... about the NIF interface, but the way that I would want this to work wouldn't involve NIF resumption at all, but rather for NIFs to be able to put responses back on a channel.

Unfortunately neither quick internet searches nor searching the rustler docs revealed anything about a NIF/channel interface. I'm not sure how feasible it is to pass a channel into a nif and allow it to pass that into some thread and return, nor how good of an idea that would be.

Docker is go, and afaik has always been.

https://github.com/docker/docker

Plantuml is (I think) built on top of graphviz. In any case the syntax is extraordinarily similar. This[1] is similar to the first example:

  @startuml
  component ripgrep
  component ignore
  component globset
  component grep

  ripgrep --> ignore
  ignore --> globset
  ripgrep --> globset
  ripgrep --> grep
  @enduml

You can get the structure right, and easily, but those beautiful icons are not something that I know how to create, and the 90-degree turns are I think actually impossible.

The fact that it is so elegantly expressed in plantuml but it's still so ugly (by default) makes me really wish for a theme that's as nice as the hand-created diagram the author wrote.

[1]: http://www.plantuml.com/plantuml/uml/SoWkIImgAStDuU9ApiyjoCz...

Darn, I was hoping that they were created with some custom [plantuml] theme that I could steal, but it seems like they're [manually created] with inkscape.

[plantuml]: http://plantuml.com/

[manually created]: view-source:http://blog.mbrt.it/2016-12-01-ripgrep-code-review/crates.sv...

For the non-install case, like when you're running a package index, having to eval the dependency specifying is horrible.

This is also why wheels (the new python package format) use a static file instead of setup.py. The Python ecosystem has been trying to get off of "just eval setup.py" for years.

To make this more concrete, you're suggesting something like

   [dependencies]
   hyper = { metapackage = { rust-platform = "2.7" } }

I like the general theme of having the platform be just a set of known-compatible versions, but on the other hand this feels like it loses out on many of the ease-of-use advantages of just specifying a platform version and knowing that you have all the crates inside of it.