I was surprised to read this uses a separate source code generator and with a custom DSL rather than a macro-based approach. I assume to integrate it with a Cargo-based build one would have to write build.rs?
There seem to be opposite dynamics playing out in Rust and C++ in this respect: C++ has a lot of source code generators like this (ORM, Qt moc, etc) and the community hopes that the upcoming compile-time reflection will make them unnecessary. And in Rust it seems the macro honeymoon is getting over and the community realizes that, at least for more complex cases, a separate source code generator is a better approach?
Yes, another project experimenting with codegen is pavex, a web framework. The toasty post talks about being able to inspect the generated code, but there are other advantages such as better compile time error messages, and optionally using precompiled binaries for codegen (which sparked a controversial discussion in a macro-based crate recently).
I’m really not a fan of code-gen crates, especially ones that require external tools to work, it’s why I never have fun using SeaORM. At least I hope it only wants you to use a single crate for your entire database instead of the two crates that SeaORM suggest. I at least do like that schema format, I feel like that’s better than the data-first approach SeaORM uses.
That said, I’ll definitely be trying it out at some point. I’m not entirely sure if I’ll ever use it, I’m pretty happy with my choices of SurrealDB for heavy-duty work and CozoDB for more lightweight analytical work. But I’ll definitely want to experiment with it. The Tokio team basically runs the Rust ecosystem, so a first-party ORM from them is pretty exciting.
About a year ago, I was making a backend for a friend’s project’s prototype, and she was like “no, I absolutely will not let you use OCaml for that”. So I offered her to use Rust and she agreed because it was more popular, but working with MongoDB was a huge pain point, and libs for relational databases were no easier. From the docs, Toasty looks like something that may change the situation a lot for those want to try Rust in that role.
I want to joke, “Why didn’t you just use Haskell? /s”, but I’m genuinely not sure which of Haskell or OCaml is more widely used in industry right now. I was thinking I’d just glance at the TIOBE index for an answer but then I looked at their top 20 and it’s absolutely silly so I definitely don’t trust that as a measure of anything.
I was surprised to read this uses a separate source code generator and with a custom DSL rather than a macro-based approach. I assume to integrate it with a Cargo-based build one would have to write
build.rs?There seem to be opposite dynamics playing out in Rust and C++ in this respect: C++ has a lot of source code generators like this (ORM, Qt moc, etc) and the community hopes that the upcoming compile-time reflection will make them unnecessary. And in Rust it seems the macro honeymoon is getting over and the community realizes that, at least for more complex cases, a separate source code generator is a better approach?
Compile-time reflection is exactly what Rust should have, instead of more code generation, macro-based or otherwise.
Yes, another project experimenting with codegen is pavex, a web framework. The toasty post talks about being able to inspect the generated code, but there are other advantages such as better compile time error messages, and optionally using precompiled binaries for codegen (which sparked a controversial discussion in a macro-based crate recently).
I think this is a pretty important feature. I never have a good time using anything that’s macro heavy.
I wonder how this will stack up to sea-orm and diesel. I don’t especially like the fact that I have to learn a new DSL to define my data model.
I’m really not a fan of code-gen crates, especially ones that require external tools to work, it’s why I never have fun using SeaORM. At least I hope it only wants you to use a single crate for your entire database instead of the two crates that SeaORM suggest. I at least do like that schema format, I feel like that’s better than the data-first approach SeaORM uses.
That said, I’ll definitely be trying it out at some point. I’m not entirely sure if I’ll ever use it, I’m pretty happy with my choices of SurrealDB for heavy-duty work and CozoDB for more lightweight analytical work. But I’ll definitely want to experiment with it. The Tokio team basically runs the Rust ecosystem, so a first-party ORM from them is pretty exciting.
I’m going to give it a try.
About a year ago, I was making a backend for a friend’s project’s prototype, and she was like “no, I absolutely will not let you use OCaml for that”. So I offered her to use Rust and she agreed because it was more popular, but working with MongoDB was a huge pain point, and libs for relational databases were no easier. From the docs, Toasty looks like something that may change the situation a lot for those want to try Rust in that role.
I want to joke, “Why didn’t you just use Haskell? /s”, but I’m genuinely not sure which of Haskell or OCaml is more widely used in industry right now. I was thinking I’d just glance at the TIOBE index for an answer but then I looked at their top 20 and it’s absolutely silly so I definitely don’t trust that as a measure of anything.
Looks like still Haskell but it’s on the decline