Hacker News Reader

Comment by Scarbutt | Hacker News Reader

Thanks for clarifying. A subjective note, the executed SQL is way more beautiful than the Rust code ;) and to me, defines the intention better, a nicer approach to me would be if the syntax/grammar would have been more SQLish.

View on HN

Ironically, I was actually originally planning on having Diesel primarily built around parsing actual SQL. (See the commit message of https://github.com/diesel-rs/diesel/commit/2ba8bf481c3d21d8b..., which is like commit number 4)

I agree that if you're just writing a single self-contained query, SQL is a great DSL for that. I've been trying to improve our story for working with raw SQL (one tradeoff will be that it isn't type checked).

However, there are major benefits to an in-language DSL as well. If you are wanting to re-use fragments of queries, or conditionally construct a different query, that's a pain to do with SQL strings.

You don't need to work with SQL strings though, you can work with ASTs or other higher level abstractions, and with Rust's macros and the infer_schema! machinery you can probably find a way to project the SQL types into Rust's type systems to keep things more or less type-safe. But then again, I've never tried to write such a thing, so maybe it's not quite as easy as that. I've definitely used a similar query-builder library in the past though and while it definitely had its benefits over raw SQL, it also led to some abuses where bits and pieces were used to compose gargantuan queries that nobody would have ever thought to write by hand.

One benefit of the diesel approach is that it's type safe, whereas the pure SQL approach isn't.

There is no technical reason why you couldn't create a fully typesafe pure SQL interface in Rust, the same way Rust's format language is typesafe.

This is true, but to do that, you need procedural macros, which are not yet stable.

Reply on news.ycombinator.com