Paul Colomiets

@vpetrovykh I agree with what you're saying. But I'm not sure that "patch" as a software update makes a lot of sense for developers who recently joined the field.

My major concern would be using `==` operator rather than full-blown pattern matching: 1. We mentioned somewhere that we probably want to implement algebraic types somehow at some point 2....

> decoding of links If you mean "decoding of link properties", they are the same as normal properties, except for a flag. We probably have to make a Rust attribute,...

> (though I think I would have it as `#[edgedb(link)]` as it's just as clear IMO and shorter). Some of the fields in the structure are an actual links. We...

> And even before query builders we can create a driver-level API Can you elaborate? Anything I can come up with, doesn't work with anything a little more complex than...

> Lastly, your opening example can be simplified: > > ```python > db.fetchone(""" > INSERT User { > first_name := $first_name, > last_name := $last_name, > birth_date := $birth_date, >...

> Hm, can we actually call the top module 'schema' and then nest 'std' and 'cal' into it? So `schema::std::int64` and `schema::cal::local_date`? Kind of reflecting the actual layout of EdgeDB...

> > It's a very long name: edgedb_protocol::schema::std::int64. > > Speaking of long names, I'd very much prefer the Rust crate/namespace for the EdgeDB driver to be simply named `edgedb::`,...

> edgedb-derive causes some complications with that. It has to choose the path from which to import types used by the derived code. > We'll see. It's not obviously we...

Okay. That's fine for linux if we don't fallback to docker or tarball implicitly, right? For windows both docker or WSL(2) aren't good defaults, right? For macos: for me it's...