3 ms·

There is some trade-off in development speed, but I think it's outweighed by the productivity gains from a great static type system and language that is relativ

There is some trade-off in development speed, but I think it's outweighed by the productivity gains from a great static type system and language that is relatively free of footguns. I have built several APIs with Rust + Axum + Sqlx. I get statically typed SQL queries, rock-solid performance, easy to deploy. Most of these APIs also interface with AWS stuff at some point, and the Rust SDK is just phenomenal to use. But I also love Rust. I've been writing it for 6 years now, and I am more productive in Rust than any other language (for non-trivial projects). I can write up an API faster in Rust than in Django, because I don't have to spend time digging through configuration files or installing plugins and reading arcane documentation to do what I want. The above stack in Rust is incredibly simple.

Dowwie 3y ago
What are you doing for partially updated resources? Also, have you written your own dynamic query building logic yet? That's the path one eventually winds up taking with parameterized sql libraries.
- shpongled 3y ago
  Either do a patch with a new struct, or do full updates (what I typically do). I have a few dynamic queries, but for the most what I'm doing is relatively straightforward. I still prefer this over using an ORM, personally.
  - Dowwie 3y ago
    When you partially update a table record, you need to determine which columns you want to update and prepare them as parameters, only including those that need to be changed. This is straightforward work for an ORM and/or query builder but not parameterized SQL. What does your implementation look like, as I can't follow your explanation. I found that both the parameterized SQL and ORM/QB have an important role to play due to the partial updates and occasionally query building exercise. None is ideal for every situation.
    - shpongled 3y ago
      Yeah, sorry that wasn't very clear. One option for a partial update is do define a new `Update` struct: struct Bar { id: Uuid, column_1: i64, column_2: i64, column_3: String, column_4: Uuid, } struct UpdateBar { column_1: Option<i64>, column_2: Option<i64>, column_3: Option<String>, column_4: Option<Uuid>, } UPDATE some_table SET column_1 = COALESCE($1, column_1), column_2 = COALESCE($2, column_2), column_3 = COALESCE($3, column_3), column_4 = COALESCE($4, column_4), WHERE id = some_id; Or, you just never do partial updates :)

Dowwie 3y ago

What are you doing for partially updated resources? Also, have you written your own dynamic query building logic yet? That's the path one eventually winds up taking with parameterized sql libraries.

shpongled 3y ago
Either do a patch with a new struct, or do full updates (what I typically do). I have a few dynamic queries, but for the most what I'm doing is relatively straightforward. I still prefer this over using an ORM, personally.
- Dowwie 3y ago
  When you partially update a table record, you need to determine which columns you want to update and prepare them as parameters, only including those that need to be changed. This is straightforward work for an ORM and/or query builder but not parameterized SQL. What does your implementation look like, as I can't follow your explanation. I found that both the parameterized SQL and ORM/QB have an important role to play due to the partial updates and occasionally query building exercise. None is ideal for every situation.
  - shpongled 3y ago
    Yeah, sorry that wasn't very clear. One option for a partial update is do define a new `Update` struct: struct Bar { id: Uuid, column_1: i64, column_2: i64, column_3: String, column_4: Uuid, } struct UpdateBar { column_1: Option<i64>, column_2: Option<i64>, column_3: Option<String>, column_4: Option<Uuid>, } UPDATE some_table SET column_1 = COALESCE($1, column_1), column_2 = COALESCE($2, column_2), column_3 = COALESCE($3, column_3), column_4 = COALESCE($4, column_4), WHERE id = some_id; Or, you just never do partial updates :)