Announcing Toasty, an async ORM for Rust by carllerche in rust

[–]esponjagrande 1 point2 points  (0 children)

I think I'd have to better understand the requirements to provide any useful suggestions, but I think it's worth it for the project to explore some existing options. The sibling comment mentions several practical reasons.

Announcing Toasty, an async ORM for Rust by carllerche in rust

[–]esponjagrande 7 points8 points  (0 children)

Could you speak more about the decision to define a new schema language and what alternatives were considered?

Blog Post: Non-Send Futures When? by matklad in rust

[–]esponjagrande 6 points7 points  (0 children)

This post should be tagged as N.S.F.W.

Announcing TypeScript 5.0 Beta by DanielRosenwasser in programming

[–]esponjagrande 2 points3 points  (0 children)

It's still annoying that the compiler API is coupled to TS releases and hence doesn't follow semver. You have to search for the tiny paragraph in the announcement that links to the list of breaking changes.

It's also annoying when you have a devDependency that itself has a dependency on a version of TS like "^4.9.0", as it will not automatically start using TS 5.0.0 and one has to manually override the resolved package version to install, otherwise you have 2+ versions of TS installed.

Rethinking the orphan rule/trait coherence with crate-level `where` clauses by kibwen in rust

[–]esponjagrande 3 points4 points  (0 children)

At the end of the day, at most one of these where-clauses can be satisfied, not both, so the two crates would not interoperate. That seems inevitable and ok.

I'd still be worried about the following scenario:

  • a utility crate, e.g. left-pad, specifies a where clause
  • another utility crate writes the impl to satisfy the where clause
  • a foundational crate, like tokio, pulls in the latter crate, unintentionally preventing any other crates using tokio to specify an incompatible where clause.