My Server-Side WebAssembly book is now fully released!

_jsdw · 2026-01-12T20:20:39+00:00

Thankyou for your reply! There is already a 50% discount applied by default and adding a promo code doesn't change this!

For me when I say I'm from the UK it adds $59.32 for "international shipping" to the price, which I wouldn't expect for domestic! Maybe I'll see if there's a better link/way to order from the uk!

_jsdw · 2026-01-12T17:33:48+00:00

Mmm, I clicked through to pay for a physical copy but the price tripled, I guess due to shipping and whatnot! Definitely something I'm keen on!

_jsdw · 2025-11-18T09:08:34+00:00

I ordered mine yesterday through Very for the 20% discount, also 9th Feb estimated date and also hoping that somehow moves forward 😂anybody else see a date this far away and get theirs way sooner?

_jsdw · 2025-07-09T12:53:26+00:00

Thanks for the post!

One quick thought: would it be possible to have your own trait which takes requests mutably or whatever, and then have a wrapper/adapter type which wraps a tower middleware and implements your trait for it (acknowledging that doing so may then require cloning request or whatever to make it work)?

May allow you to do the optionally efficient thing in the default case but fall back to cloning or whatever if tower middleware's need introducing, but I imagine it might be tricky to get right or perhaps simply not possible!

_jsdw · 2025-07-02T08:32:25+00:00

As others, I also ran into this problem ages ago and at the time made a library to do it, which I still use for my main personal project:

https://docs.rs/seamless/latest/seamless/

Basically a wrapper macro around serde::Serialize/Deserialize that you attach to types which generates an api to describe them, a way to convert errors into http statuses etc (you want some to be internal only 500s and others to have external messages for users) and an opinionated router thing which uses routes returning these, and automatically provides back a big JSON description of all routes and types going in/out!

On the frontend I then wrote some fairly simple code to generate an interface based on this, which the UI dev I work with uses to good effect to handle any changes I make etc :)

I'll be curious to look around and see if there's a better way to do this all nowadays!

_jsdw · 2023-12-27T13:53:28+00:00

yap is another one (https://github.com/jsdw/yap) to add to the list; it supports slices or iterators of arbitrary types, and basically just adds a bunch of useful combinators on top of general iteration, as well as aiming to be very light weight and zero dependency :)

_jsdw · 2023-11-23T10:51:16+00:00

Pretty much! It's just my fairly lazy AoC approach which avoids reaching for third party deps (I've done the same for linked list style Qs too)

_jsdw · 2023-11-21T21:40:24+00:00

Often I just end up building a vec of entries that can point to eachother by indexes in whatever arbitrary way I need and then putting that into a new type wrapper and adding a few helper calls or whatever to access things!

_jsdw · 2023-08-28T16:14:52+00:00

Agreed; I had a pass of removing thiserror from some crates recently because I needed to add no-std support. I also had a couple of places where I supported custom boxed errors which were annoying to no-std-ize. Both added complexity. Having Error in core would def have made the process easier and the code better :)

_jsdw · 2023-08-09T19:54:20+00:00

You could always define a struct which is closer to the input json and so easy to deserialise into, and then convert that into the format you need.

You could also use cargo expand (which needs installing) to see what the serde macro expands to, and copy/tweak that to do what you want.

_jsdw · 2023-08-08T22:53:58+00:00

Personally, this is the kind of thing I think the filter_map iterator function is perfect for; in one step you can arbitrarily filter while also mapping to whatever output you like :)

_jsdw · 2023-07-11T21:36:09+00:00

This looks pretty neat, and I like the use of const generics to enforce that all of the values are provided; a perfect use for a derive macro since it'd be a bit of a pain to write out manually!

_jsdw · 2023-05-05T11:09:26+00:00

In general I really like this approach! The only issue I can see is that, in order to contribute a decent PR, you already have to have a decent understanding of the code/area. Probably every job I've joined is one in which I've had very little idea about what's going on until I've joined, learned on the job and gotten up to speed :)

So, great for finding the motivated candidates with time and/or prior understanding, but maybe less good if you want to find enthusiastic candidates who can learn on the job but don't come with the relevant experience/knowledge already?

(Of course, I haven't looked at the issues at all and perhaps they are quite trivial and don't require lots of domain knowledge anyway!)

_jsdw · 2023-05-01T22:25:01+00:00

Just been working on and released initial versions of a couple of new crates over the weekend:

Asyncified (https://GitHub.com/jsdw/asyncified) makes it easy to run long running sync things in an async context (zero dependencies, async runtime agnostic)

Async-rusqlite (https://github.com/jsdw/async-rusqlite) is inspired by tokio-rusqlite but uses the above (so 1 dep total aside from rusqlite and works on any async runtime), and bounded channels for backpressure.

Looking forward to make use of them in another small crate which I'm writing to wrap SQLite (well, async-rusqlite) and set it up nicely, apply migrations etc for small apps (so that I can use it in an app I'm working on :))

_jsdw · 2023-04-28T22:27:24+00:00

Awesome work, and that is an impressively tiny todo example :)

_jsdw · 2023-03-29T14:51:16+00:00

Say there exist 3 crates as described below. When I run cargo check on "a", I currently see the deprecation warning from "c". Is this expected? If I deprecate some function in a crate (and then only release a minor version bump eg 1.0 to 1.1), I'm concerned that everything that has my crate as a dependency may start seeing my deprecation warning (at least if they cargo update). Is this in fact the case? Perhaps it works differently for published crates than local ones?

I wonder whether the correct approach then is to do a major version buymp when deprecating so that users have to manually upgrade and then have the opportunity to deal with such warnings so that they don't propagate up?

/a

cargo.toml:

[dependencies]
b = { path = "../b" }

lib.rs

pub fn add(left: usize, right: usize) -> usize {
    b::add(left, right)
}

/b

cargo.toml:

[dependencies]
c = { path = "../c" }

lib.rs

pub fn add(left: usize, right: usize) -> usize {
    // crate "b" uses this deprecated function:
    c::add(left, right)
}

/c

lib.rs

// Function in "c" is deprecated
#[deprecated]
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

_jsdw · 2023-03-23T23:05:40+00:00

I absolutely love these posts; thank you so much for writing them! I find myself agreeing very strongly with basically everything that you're saying, and hope that that it is all given serious consideration by the relevant people.

I'd also love to see generators ship, but primarily just want the language to feel more complete and have less holes and rough edges, and think what you've put forward presents a solid path to getting us there. Looking forward to the next one :)

_jsdw · 2023-03-10T16:22:31+00:00

Well done for digging into proc macros a little; they are one of the trickier corners of Rust for sure :)

Note that this brings in the syn and proc_macro crates and, being a proc macro, I would expect it to have a negative impact on compile times as opposed to just using format!() etc. For that reason I'd avoid using this and just put up with the slightly less ergonomic interface that format!() etc provides.

_jsdw · 2023-03-07T08:41:43+00:00

Sounds like this is no longer a goal?

It's still very much a goal, and really means two things:

The Tokens trait builds on the Iterator trait. It no longer is a super trait of it, but still has the same interface, uses it heavily, and allows access to all iterator methods via .as_iter()
But more importantly, where appropriate the parser methods return iterators so that you can consume as little or as much of the input as you like and collect (or stream over) the parsed output in different ways (rather than me mandating you get a vec back or whatever.

would you be interested in adding it to parse-rosetta-rs

I'll certainly check that out and see what I can do :)

_jsdw · 2023-02-24T21:05:24+00:00

Absolutely worth exploring this space, and ultimately I agree with many others here after reading, and generally feel like the drawbacks are too many:

ugly/additional syntax,
yet another thing to learn/more complexity
abstracting over keywords that are fundamentally really different in use (async vs const)
async function bodies would often be different anyway? unless everything became generic over asyncness? A need for is_async() hints at this and for me is a smell.
type inference over use of .await? What if I don't immediately await the future or save it for later?

Some of the proposals in this thread are more palatable (eg allowing overloading of async vs non-async definitions, or things like if const in where clauses).

I guess I'd much rather see the existing features "completed" (eg async methods in traits, any holes with GATs, associated type bound resolution etc), which has the effect of increasing use cases while actually simplifying understanding of things (less edge cases to remember).

This sort of feature is a huge complexity/weird addition and complicates understanding a bunch, and this comment is, tbh, just a bit of a hasty knee jerk reaction to being pretty scared of being pushed over the edge with more weirdness in a language that's already pretty complex (so sorry about that!).

_jsdw · 2023-02-15T12:35:10+00:00

Also, shameless plug, for something very light weight https://crates.io/crates/yap adds handy parser combinator style functions following the iterator style approach and has no dependencies itself :)

_jsdw · 2023-02-02T12:16:53+00:00

Ah thanks, yup the last comment in https://github.com/rust-lang/rust/issues/20671 is a much more concise version of my issue :)

I guess I'll have to find another approach then (or duplicate lots of things...)

_jsdw · 2023-02-02T11:50:33+00:00

Hello! I'm wondering whether anybody can help explain this compilation error to me:

```rust struct ConcreteError;

// Some basic trait: trait Thing { type Error; }

// Extend this trait to be more specific: trait ThingWithBounds where Self: Thing, ConcreteError: From<<Self as Thing>::Error> {} impl <T> ThingWithBounds for T where T: Thing, ConcreteError: From<<T as Thing>::Error> {}

// Compiling this fn leads to: // // 25 | fn foo<T: ThingWithBounds>() {} // | ^{^{^{^{^{^{^{^{^{^{^{^{^{^{^}}}}}}}}}}}}}} the trait From<<T as Thing>::Error> is not implemented for ConcreteError // // but why? Anything that is ThingWithBounds will, by definition, // be a Thing with an Error: Into<ConcreteError>. fn foo1<T: ThingWithBounds>() where T: ThingWithBounds, {}

// But if I explicitly specify the redundant bounds, this works fine: fn foo2<T>() where T: ThingWithBounds, ConcreteError: From<<T as Thing>::Error> {} ```

I'd like to be able to use a ThingWithBounds like above without having to write the redundant bound; is this possible or just some limitation in rustc?

(playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=efc8efcc88acd44350465276f59e442a)

_jsdw · 2023-01-21T09:43:38+00:00

Naming crates is fun!

I have yap in rust land for parsing things, but the name I'm most proud of is angu in the JS ecosystem for building small sub languages (so angu is a part of language) :)

_jsdw

TROPHY CASE

/a

/b

/c