Continuing my tweet about Express as another data point to iron/diesel per “Teaching libraries through good documentation”—

I’m not sure I can answer your question, since I somehow learned it a few years ago, basically by cobbling enough of an understanding on how the pieces fit together for the official API docs to make sense. But Express is a superstar so there are tons of online tutorials—all of them quite bad I found 😅. There’s a very brief official “hello world” which, when I was a beginner, I ignored because it was so short, and a much longer yet much less useful page on using a project generator to get started. Occasionally when I need to throw together an Express app, I revisit the Hello World page and then look up the API docs, each time. It’s really strange, I honestly don’t know how people learn to use Express, although obviously they do…

Another example in this space is in Clojure, where a lot of people use the combination of ring (HTTP server) & compojure (routing). Dozens of plugins, like express—for anti-forgery, cookies, timeouts, JSON, &c.

Of course, for both Clojure and Node there are Rocket-like frameworks (Rails-like?), but they seem not as popular, in those ecosystems, as these hypermodular libraries. Definitely a head-scratcher for me…

When you have married and had children, you will have a different viewpoint.

The Irregular pronunciations table on the Symbol Pronunciation page is missing the column that actually specifies the irregular pronunciations.

Hi! I can't help but notice the absence of your amazing content. We all miss it! Eagerly waiting for your next blog post - they're always a hit! 😃

Small typo in footnote:
"Guaranteed to by a"

Link - https://deterministic.space/elegant-apis-in-rust.html

Possible improvements

• Remove use of try!().
• Replace mentions of error-chain and quick-error with anyhow and thiserror.

I like the idea, but it'd be nice if some things were optional, such as rustfmt (there are still bugs with it for some patterns; I need to collect them and file bugs), CI (not everyone uses CI that has artifacts in the repo, so some way to say "done externally" would be great), and potentially other things (not everyone uses git, so .gitignore).

Hi,
I was looking for exactly what you described in your Rich diffs of rendered HTML article and your approach seems very interesting. Do you know if there has been any progress (by you or anyone else)?

Thanks

I can see interpreting it as 5 February or 2 May, but not your interpretation.

Tom

In this nice write-up, the following code example bothers me:

let package = Package::new(); // -> OpenPackage
package.insert([stuff, padding, padding]); // -> OpenPackage
package.seal_up(); // -> ClosedPackage
// package.insert([more_stuff]); // ERROR: No method `insert` on `ClosedPackage`
package.send(address, postage); // -> DeliveryTracking

I don't see how the package type could change from one line to another. I think a realistic example would be:

let package = Package::new(); // -> OpenPackage
let package = package.insert([stuff, padding, padding]); // -> OpenPackage
let package = package.seal_up(); // -> ClosedPackage
// let package = package.insert([more_stuff]); // ERROR: No method `insert` on `ClosedPackage`
let package = package.send(address, postage); // -> DeliveryTracking

Hi,

On https://deterministic.space/elegant-apis-in-rust.html, it looks like there's a small issue with a code example near the end:

let p: OpenPackage = Package::new();
let p: OpenPackage = package.insert([stuff, padding, padding]);

let p: ClosedPackage = package.seal_up();

// let p: OpenPackage = package.insert([more_stuff]);
//~^ ERROR: No method named `insert` on `ClosedPackage`

let p: DeliveryTracking = package.send(address, postage);

I think all the let p: … bits should be let package: …, shouldn't they?

I think you might be looking for something like ontologies and the semantic web. These technologies would let you create objects and their relationships and then automatically apply reasoning to them based on their properties and relationships. It's also the idea that TBL had for the web all along. Exciting stuff :)

At "Take Closures" there is this code example:

let res: Result<i32, String> = Err("oh noes");
res.unwrap_or(42) // just returns `42`
res.unwrap_or_else(|msg| msg.len() > 12) // will call the closure

I think the > 12 part should be replaced by as i32, because the types i32 and bool don't match, making compilation impossible.

Hello Pascal,
this isn't an issue strictly related to your blog, sorry to take this shortcut to contact you.

On your talk at RustFest in Rome, when talking about using traits to gain more expressive methods sign writing less code, i saw you were using a struct or an enum Json to tell something should become a Serializable struct. I can't find it anywhere, was something you wrote on your own?

On the same talk, I saw a line like serde_json::from_stream(request.body()). I know Hyper's Body is a stream, so it makes sense, but I can't find somethin like a "from_stream" method in serde_json, can you point me out this too?

Thank you very much and congratulations for the talk

First of all, great post, thank you! Like many of your readers, I've seen Cows, known about Cows, but never really stopped to look at them long enough to wonder why I might use them. No more! :)

One question I have is around the rationale you provided for the ?Sized trait given in Cow's declaration:

?Sized is a funny one. By default, Rust requires types to be of a known size. ... if you have a reference to [an array of bytes], the reference itself can contain the length. ... Since a Cow should be able to contain a &[u8], we need to say “we don’t require this to be Sized”

My thoughts on this are that a &[u8] is indeed sized--it's a fat pointer--always exactly 64 or 128 bits (depending on your platform), namely size_of::<*const u8> + size_of::<usize>. Further, as a fat pointer, the second element provides the size of the array, so one would think we have all the size information we could ever need...

I'll grant that the fat pointer's array size may not be known at compile time. But given that the Cow stores a &[u8] (and not a [u8]), shouldn't the fat pointer (which itself does have a known size at compile time) be all the Cow needs? I'm wondering why Cow needs more than this to work, or put another way, re-raises the question, why does Cow required ?Sized?

I hope my question makes sense. Thanks again for the excellent post.

commenting on https://deterministic.space/pascal-vs-usb-c.html:

"Arc Hub, no Ethernet, but apparently 4k @ 60Hz using Mini DisplayPort. $105 pre-order, ships early 2017"

but actually it is only support 30Hz at 4k no matter HDMI or DP (screenshot from their site below and I bought and tested one).

discussions:
  Reddit: ....
  Twitter: ....
  HN: ....

and show it as a list below the post. (Steal template from rust.cologne)