4 ms·

Many comments (probably correctly) point out that SQL can't be displaced because it is ubiquitous and "good enough". I wonder if there is room for a "TypeScrip

by jpobst 7y ago

Many comments (probably correctly) point out that SQL can't be displaced because it is ubiquitous and "good enough". I wonder if there is room for a "TypeScript" of SQL that would allow developers to opt-in to whatever new language features or paradigms we feel SQL is missing. It would then transpile down to regular SQL to be executed.

Svip 7y ago
I was wondering the same thing. Why not rather than build a new database engine, write a library like an ORM that transpiles a language - like EdgeQL - to SQL, so you can attempt to use it, without switching underlying database engine, and still use your old SQL code?
- RedCrowbar 7y ago
  EdgeDB is built on Postgres, it's not from scratch.
- deleted 7y ago
  [deleted]
rockostrich 7y ago
Isn't this what an ORM is? Or at least an ORM covers some new features that users can opt-in to without losing the ability to write raw SQL. I guess it's not the perfect analogy to TypeScript, but I think it's a pretty good comparison. The other thing I can think of are things like GraphQL which can be used as an abstraction on top of a SQL DB.
- ben509 7y ago
  Some ORMs like Hibernate have their own QL, but they typically preserve the SQL data model. This isn't just replacing SQL, they're trying to implement a new data model that is backed by Postgres.
wendyshu 7y ago
Yeah then we get the best of both worlds. I might use that if it existed. All else being equal, EdgeQL the language looks great compared to SQL.
ken 7y ago
My Mac app, Strukt, does a bit of this. The main problem is that the basics of the various databases don't align very well. The functionality that's common to all databases is quite weak. Even such things as case sensitivity are drastically different. And for many of the differences, there's simply no way to emulate the other's functionality, correctly and efficiently. C compiles to assembly or machine code, and TypeScript compiles to JavaScript, and in both cases you have the full power of the level you're targeting, so it's fine. An RDBMS has very specific fast-paths that you really need to hit, or the whole exercise becomes pointless. It's like trying to write a 3D game in JavaScript without any way to access the GPU or even SIMD ops. We can do 3D games in JS today, but that's really only feasible because the browser vendors went and exposed the basic fast paths.

by jpobst 7y ago

Svip 7y ago

I was wondering the same thing. Why not rather than build a new database engine, write a library like an ORM that transpiles a language - like EdgeQL - to SQL, so you can attempt to use it, without switching underlying database engine, and still use your old SQL code?

RedCrowbar 7y ago
EdgeDB is built on Postgres, it's not from scratch.
deleted 7y ago
[deleted]

rockostrich 7y ago

Isn't this what an ORM is? Or at least an ORM covers some new features that users can opt-in to without losing the ability to write raw SQL. I guess it's not the perfect analogy to TypeScript, but I think it's a pretty good comparison. The other thing I can think of are things like GraphQL which can be used as an abstraction on top of a SQL DB.

ben509 7y ago
Some ORMs like Hibernate have their own QL, but they typically preserve the SQL data model. This isn't just replacing SQL, they're trying to implement a new data model that is backed by Postgres.

wendyshu 7y ago

Yeah then we get the best of both worlds. I might use that if it existed. All else being equal, EdgeQL the language looks great compared to SQL.

ken 7y ago

My Mac app, Strukt, does a bit of this. The main problem is that the basics of the various databases don't align very well. The functionality that's common to all databases is quite weak. Even such things as case sensitivity are drastically different. And for many of the differences, there's simply no way to emulate the other's functionality, correctly and efficiently. C compiles to assembly or machine code, and TypeScript compiles to JavaScript, and in both cases you have the full power of the level you're targeting, so it's fine. An RDBMS has very specific fast-paths that you really need to hit, or the whole exercise becomes pointless. It's like trying to write a 3D game in JavaScript without any way to access the GPU or even SIMD ops. We can do 3D games in JS today, but that's really only feasible because the browser vendors went and exposed the basic fast paths.