colinmcd

This video is definitely corny. (I'm in it.) This is intended as an extremely accessible introduction to Bun, definitely not targeted at the HN crowd. I think we really just wanted to make something with some production value to reflect the fact that Bun itself is post-1.0 and more stable/polished.

The two camera thing is a classic trick that lets you add some visual interest. Basically you're cutting between two angles. And you can only be looking directly at one camera at a time so you won't be looking into the lens for one of the two shots.

Colin here, I work on Bun.

Bun 1.0 is actually still compiling but we decided not to delay the premiere of this announcement video since it was already on calendars. We'll be publishing a full announcement post later today that's more detailed than this video.

Something like typebox (that's designed to map one-to-one onto JSON Schema) may be better if codegen is a priority.

This is mentioned under "Limitations"

> The result of the macro must be serializable!

> Functions and instances of most classes (except those mentioned above) are not serializable.

Perhaps this one?

https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with...

We already have a Go driver as well[0] and you can get pretty far by executing queries over HTTP[1] though that's not as capable as a full client. As you said, the roadmap needs some freshening up.

[0] https://github.com/edgedb/edgedb-go

[1] https://www.edgedb.com/docs/clients/http/index#edgeql-over-h...

We're still working out the kinks, but some form of this will definitely be possible.

You can already hack this by defining access policies and writing an EdgeQL proxy server that authenticates incoming requests, sets the appropriate global, and forwards the query to the database. There's a Python/Flask implementation of this pattern here[0].

We also have a JavaScript example app demonstrating access policies to simplify authorization logic using Next.js/getServerSideProps[1] and a user management platform you may have heard of called Clerk[2] :)

[0] https://github.com/edgedb/edgedb-examples/tree/main/flask-pr...

[1] https://github.com/edgedb/edgedb-examples/blob/main/nextjs-a...

[2] https://clerk.dev/

EdgeDB is a long-term effort for a DB/query language that's as intuitive as possible for the greatest number of people. The early adopters are primarily those who are frustrated by ORMs and/or SQL, as you'd expect. But you should pick whatever makes you most productive—if you're already productive and happy with SQL, then that's definitely the right choice! Good luck with PureORM, looks very cool.

I think that's a good characterization!

TypeScript's type system is unsound in a mathematical sense: https://effectivetypescript.com/2021/05/06/unsoundness/ Though this has little bearing on practicality which is probably why the original comment is at the bottom of the pile.

He's also using a stricter mathematical definition of "type safety" whereas tRPC means it in the colloquial way it's used in the TypeScript ecosystem (that is, a fully typed interface between client and server, ideally that's non-duplicative and inferred directly from your code instead of being manually defined).

Basically tRPC lets you define a router containing all your endpoints in a single structure. Then you can import the type definition of your router and make typed API calls without needing to wire everything together with types.

Exactly. But with faster iteration speed, more type inference, less overhead, and a TypeScript-native DX.

I wrote the initial proof of concept for tRPC a little over a year ago (though I'm no longer involved in the project). Seems like there's some confusion about how this works. A more complete description is available here[0] below but I'll put a brief explanation below as well.

- It's designed specifically for a full-stack TypeScript app. Your API is implemented as strongly typed server-side functions.

- The input type is specified using a schema library like Zod or io-ts.

- TypeScript infers the return type of these functions.

- You can then import the type signatures of your functions into your client. Just types, no runtime code! This is safe in typescript with the `import type` syntax. tRPC uses those type signatures to provide a typesafe client API, basically an SDK for your API. There's no codegen happening - the client uses TypeScript generics to provide a set of strongly typed "proxy functions" that can be "called" on the client. These proxy functions execute HTTPs requests under the hood: https://trpc.io/docs/rpc

The point is to avoid the boilerplate, codegen, and lack of DRYness associated with building a strongly typed API in TypeScript. You can do this with GraphQL but it relies on code-generation, requires complete buy-in, and (IMO) doesn't provide a great developer experience. TypeScript has a native way of representing types, so the goal is to avoid an intermediate representation (in the form of an OpenAPI spec or GraphQL schema) entirely. As you update your server code, the client's type signatures update instantaneously.

Another important goal is to make it easy to write DRY code when building APIs. Without tRPC, it's common to manually provide type definitions for the results of API calls. But those definitions can easily get out of sync with your actual server code. tRPC infers types from your code itself and provides a typed interface for your API thats doesn't require any manual type annotations.

[0] https://colinhacks.com/essays/painless-typesafety

Seems like a lot of similar ideas! Database-first, typesafety, code generation. Though ultimately SQL has some core incompatibilies with object-orintation, and the active record pattern has some fundamental issues that Neward touches on in his power. Though there's not really any other option in Java.

Author here - happy to answer questions about our methodology with IMDBench [0]. Definitely encourage everyone to try running the suite locally too. [1]

[0] https://github.com/edgedb/imdbench

[1] https://github.com/edgedb/imdbench/blob/master/DEVELOP.rst

Most of the "killer features" are in EdgeQL, SDL, and the tooling surrounding EdgeDB. But the goal of this post is just to describe the graph-relational model of data persistence at a high-level—how graph-relational databases "think" about data. We intentionally defined the term in a way such that it isn't strongly coupled to EdgeDB — EdgeDB is just one possible implementation of the model. And there's a lot more to EdgeDB beyond that fact that it's graph-relational.

I’ve been working on the EdgeQL query builder for TypeScript for around 6 months. This is part of my day job, but the prospect of taking point on this project is what first attracted me to EdgeDB.

The goal is to provide a library that’s autogenerated from your DB schema that can express any EdgeQL query and statically infer the result type.

I’ve done a lot of digging into various SQL query builders for TypeScript, and while some noble efforts have been made, there are structural issues with SQL-notably the fact that it’s tricky to write queries that return nicely structured results-that kneecap those efforts.

By starting with EdgeQL as our target query language, The problem gets more tractable. It still required some truly nextlevel TS wizardry. I’m the developer of Zod and tRPC too, so it’s not my first rodeo, but this is the thing I’m most proud of. Not to sound too grandiose, but this really does represent a “3rd Way“ beyond the usual “raw SQL vs ORM” debate.

[0] https://www.edgedb.com/docs/clients/01_js/expressions

The goal is to never drop down to SQL. If there's something you can express in SQL but can't express in EdgeQL, it's a bug.

We're working on proper query profiling now, but in the meantime the "slow query" problem you see with ORMs happens quite rarely with EdgeQL. For starters a lot of ORM performance issues are causes by the fact that they secretly do a bunch of roundtrips under the hood. EdgeQL queries compile to a single SQL query always. Also, since we target Postgres exclusively, we can produce queries that take full advantage of its (rather preposterous) power and performance. We extensively test the performance of things like extremely deep/wide fetching, lots of nested & complex filter expressions, computed properties, subqueries, polymorphics, etc. Obviously nothing is 100% but we're pretty confident in saying that EdgeQL performance is good.

In the sense that "object-relational mapping" is happening, then sure. The problem with the "ORM" term is that it comes loaded with a bunch of preconceptions that don't apply to EdgeDB. EdgeQL is a full query language with a standard library, grammar, and feature parity with SQL (almost). We've got a binary protocol. You use EdgeDB without ever needing to think about the layer beneath it—totally non-leaky. It's also not a library, which most people assume when you say "ORM".

Hey, I used to go to that AMC theater!

NeRF is one of the big "holy sh*t" moments for me in recent years. I've always thought using polygons as our only way to represent non-trivial 3d shapes felt awfully inelegant, like using raster images instead of vector graphics.

Definitely recommend checking out the HN discussion of the original NeRF paper[0]

[0] https://news.ycombinator.com/item?id=22637721

Unfortunately DGraph is having some serious troubles as a company: https://discuss.dgraph.io/t/quitting-dgraph-labs/16702

Technically speaking though, using GraphQL as a data model is quite limiting: just basic scalar types and a handful of custom types implemented by DGraph (Polygon, etc). By contrast EdgeDB schemas support a much wider range of granular types, constraints, computed properties, link properties, etc.

Perhaps more importantly EdgeQL is a full query language with composable syntax, a standard library of functions and operators, for loops, primitive literal manipulations (e.g. string indexing and slicing), the ability to cast values to different types, subqueries, etc. Basically it's a complete query language contrast GraphQL is closer to an ORM in that it really only supports CRUD.

I think DQL is marginally more powerful though admittedly I'm not very familiar with it: https://dgraph.io/docs/get-started/

Exactly, implementation coupling vs interface coupling.

Yep, you understand correctly!

  with tag_names := {"angular", "nestjs", "cypress", "nx"},
  select BlogPost {
    title,
    tag_names := .tags.name,
    match_count := count((select .tags filter .name in tag_names))
  }
  filter .match_count > 0
  order by .match_count desc;

  \q or \quit

If you get stuck, run \help for a list of commands.

Thanks! Point taken re: Terraform, we'll give that some thought.

A lot to unpack here.

1. If other clouds want to offer a hosted EdgeDB offering, they can do so. We'll have a tight integration with the `edgedb` CLI and we're confident we can beat them on the developer experience which is our #1 priority.

2. We'll likely use GitHub for auth though this isn't set in stone yet. We're still planning out the workflows surrounding EdgeDB Cloud.

3. As for the explosion of cloud silos—that's a very real phenomenon with a boring reason: hosting is one of the few ways to make money building OSS software. There are preposterously valuable OSS frameworks + libraries that haven't made anyone a cent. We implemented "one-click" deploy buttons for the major clouds to the extent it was possible to do, but for fully open-source companies like EdgeDB there's aren't many routes to sustainability outside of paid hosting.

That's correct! Though that's true for most ORMs as well, and we try not to get lumped into the ORM bucket...too much bad blood.

I've dabbled with CoreData myself and it's a phenomenal API. Apple comes up with a lot of great stuff. In fact, given how much server-side Swift there is these days, we'll have to look into building a Swift client library at some point.

EdgeDB employee here. I couldn't have asked for a better question to demonstrate the power of subqueries! Here's how I'd do this in EdgeQL:

  with tag_names := {"angular", "nestjs", "cypress", "nx"},
  select BlogPost {
    title,
    tag_names := .tags.name,
    match_count := count((select .tags filter .name in tag_names))
  }
  order by .match_count desc;

Which would give you a result like this:

  [
    {
      title: 'All the frameworks!',
      tag_names: ['angular', 'nestjs', 'cypress', 'nx'],
      match_count: 4,
    },
    {
      title: 'Nest + Cypress',
      tag_names: ['nestjs', 'cypress'],
      match_count: 2,
    },
    {
      title: 'NX is cool',
      tag_names: ['nx'],
      match_count: 1,
    },
  ];

Everything is fully OSS: the database, our client libraries, our CLI. There's a company behind it (I'm an employee) which will make money with a cloud hosting platform, similar to Mongo. We're calling that EdgeDB Cloud and it's still under development. Though you can self-host too on any major cloud. [0]

[0] https://www.edgedb.com/docs/guides/deployment/index

Prisma did a lot of things right, and we have a ton of respect for the team over there! At the end of the day, building a good, idiomatic API for doing CRUD operations is a hard problem. But building an entirely new query language that fundamentally solves some underlying design flaws and usability issues with SQL is a whole other level of hard.

With EdgeQL, we conclusively solved a lot of these fundamental issues. Now, we're able to use EdgeQL as the foundation of our query builders, which is a huge advantage. We built the first version of the TypeScript QB in ~4 months) and it immediately leapfrogs all the major ORMs in power & expressiveness. But that's only possible because the hard work of designing EdgeQL was already done.

We'll be working on communicating how our query builder works and how it compares to ORMs in some of upcoming posts, stay tuned.