colinmcd

We're working on a more comprehensive explanation of why EdgeDB isn't an ORM. Does EdgeDB do "object-relational mapping" under the hood — absolutely. The reason we try to distance ourselves from the category of ORMs is that the term "ORM" comes with a big bag of preconceptions that don't apply here. EdgeDB has:

- Full schema model with indexing, constraints, defaults, computed properties, stored procedures

- A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug. Most ORMS provide some sort of language-specific API for writing queries and generating SQL under the hood—that's dramatically different than providing a new query language.

- A full type system, grammar, set of functions and operators, etc. A set theoretic basis for all expressions in EdgeQL. https://www.edgedb.com/docs/edgeql/sets

- A set of drivers for different languages that implement our binary protocol.

EdgeDB is a new abstraction built on a lower-level abstraction: Postgres. Both indubitably fit any reasonable definition of "database".

We're working on a more comprehensive explanation of why EdgeDB isn't an ORM. Does EdgeDB do "object-relational mapping" under the hood — absolutely. The reason we try to distance ourselves from the category of ORMs is that the term "ORM" comes with a big bag of preconceptions that don't apply here.

EdgeDB has:

- Full schema model with indexing, constraints, defaults, computed properties, stored procedures

- A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug.

- The query language is backed by a full type system, grammar, set of functions and operators, etc.

- A set of drivers for different languages that implement our binary protocol.

By any definition, EdgeDB is a database. It's a new abstraction built on a lower-level abstraction: Postgres's query engine. Both abstractions indubitably fit any reasonable definition of "database".

Basically: just because there's a declarative object-oriented schema doesn't mean this "is just an ORM" (unless your definition is quite pedantic).

Will do.

EdgeDB employee here. We're beyond excited to finally publish a stable release of EdgeDB after 4 years of active development and 15 pre-releases. Happy to answer any questions on here!

The performance sensitive stuff (e.g. I/O, etc) written in Cython and Rust. Under the hood all EdgeQL queries are compiled to an equivalent Postgres query.

Thanks!

EdgeDB employee here. The proactivity is appreciated, but EdgeDB 1.0 isn't actually available yet. We do have a launch event coming in a couple weeks however [0].

[0] https://lu.ma/edgedb

We have big plans for something quite similar to this. Stay tuned.

Co-creator here. Perhaps the most interesting part of this project is how the traffic to the site seems to correspond to the number of students slacking off. Traffic increases monotonically Monday to Friday (though occasionally Thursday beats out Friday), and drops off big over the summer and weekend. Guess we found a niche.

This is the strongest validation signal I've seen for Deno in some time. I had the impression it was withering on the vine, but hopefully this puts some wind in its sails.

EdgeDB employee here - happy to answer any questions. This is the second of three release candidates, followed by 1.0 in roughly a month.

Some previous HN discussions about EdgeDB and EdgeQL:

[0] We can do better than SQL https://news.ycombinator.com/item?id=24106608

[1] EdgeQL https://news.ycombinator.com/item?id=27793398

I have two projects with a total of almost 7k stars. [0]

It’s worth noting that GitHub stars truly don’t translate into anything worthwhile in the vast majority of cases. You can have a massively popular project, but it doesn’t automatically translate into Twitter followers or newsletter subscribers. And those things don’t directly translate into wealth or happiness either.

Just get a job and make friends and have a life. That route has the highest expected value. I have been chasing GitHub stars for a long time, and it has never been fulfilling. I wouldn’t recommend it.

[0] https://github.com/colinhacks/zod

Predicate order in SQL is pretty dodgy all around and makes it hard to build intuition around SQL queries. In select, the actual SELECT clause (field selection) can usually be conceptualized as “happening” after all other clauses, but of course it comes first in the query.

This problem is fixed in query languages like EdgeQL.[0]

[0] https://www.edgedb.com/docs/edgeql/commands/update

Colin (EdgeDB employee) here. We're happy to announce the first release candidate of EdgeDB 1.0! We'll be releasing RC2 in a couple weeks, followed by a stable release shortly thereafter.

Quick TLDR of what we're trying to build: we think some of the design choices in SQL are holding back relational DBs from providing the best possible developer experience. Namely: non-composable syntax, OOP-incompatible (and ultimately unnecessary) concepts like foreign keys and JOINs, and the lack of first-party migrations. The lack of these things is what drives developers to ORMs and other non-optimal abstractions. See a previous HN discussion of EdgeDB and our query language EdgeQL here [0].

We’ve received a lot of great feedback on HN over the years. Feel free to check out some recent threads about the design of EdgeQL[1] and the limitations of SQL[2].

[0] https://www.edgedb.com/blog/we-can-do-better-than-sql

[1] https://news.ycombinator.com/item?id=27793398

[2] https://news.ycombinator.com/item?id=24106608

EdgeDB employee here. This is our final beta release, which will be followed swiftly by a release candidate in a couple weeks, then a stable 1.0 shortly thereafter. (Finally!)

A brief overview of what we're trying to do: we think some of the design choices in SQL are holding back relational DBs from providing the best possible developer experience. Namely: non-composable syntax[0], the lack of a standardized mechanism for declarative schema modeling, and the lack of a first-party migrations system. The lack of these things is deeply felt, as evidenced by the popularity of ORMs (despite their tradeoffs).

We're aiming for a unified DX, with first-party tooling/syntax for declaratively defining your schema[1], generating and applying migrations[2], and writing queries with EdgeQL. EdgeQL is a spiritual successor to SQL that’s composable, compact, and eliminates the need for foreign keys/JOINs (as it’s deeply integrated with our graph-like schema modeling system). A quick overview of the syntax is here[3].

We’ve received a lot of great feedback on HN over the years. Feel free to check out some recent threads about the design of EdgeQL[4] and the limitations of SQL[5].

[0] https://www.edgedb.com/blog/we-can-do-better-than-sql

[1] https://www.edgedb.com/showcase/data-modeling

[2] https://www.edgedb.com/showcase/migrations

[3] https://www.edgedb.com/showcase/edgeql

[4] https://news.ycombinator.com/item?id=27793398

[5] https://news.ycombinator.com/item?id=24106608

They're announcing these in anticipation for Stripe Sessions, a two-week developer conference of sorts. [0]

[0] https://sessions.stripe.com/

Author here. Most build tools for end-to-end typesafe APIs rely on code generation, notably OpenAPI and GraphQL. Codegen works, but it inevitably introduces lag and friction into the developer workflow. The fact that modern TypeScript makes it easy and safe to share type signatures between any two TypeScript projects is majorly underdiscussed and underutilized. I think some sort of "TypeScript-native" typesafe API library[0] is inevitable as a growing fraction of web projects are fullstack TypeScript. Excited to see how this all pans out!

[0] https://trpc.io/

I'm no biologist, but mRNA is ephemeral by design - it's constantly being broken down in the body. The fact that mRNA is converted to proteins by ribosomes is one of the best understood processes in cellular biology, and synthesizing the mRNA for a new protein is not a new idea. Getting actual viral vectors injected into my arm seems much more concerning on the surface (though it's obviously also very safe).

I'd love to get in touch - we offer a similar service to Axle Health. My email is in my bio.

Or just plain zod

Hey HN —

We were sick of doom scrolling and instant gratification on Twitter, so we made a site where you can journal with friends.

It's meant for longer form writing, and it only updates once a day.

It also has no ads, no trackers/analytics, very minimal Javascript. Loads really fast. All that jazz.

We'd love to hear any feedback you have!

Yes

I added a footnote to address this. I admit I hadn't thought this bit out fully.

Basically there needs to be a mechanism by which the set of maintainers divvy up the money.

A pattern I expect will arise (actually it probably already exists): there can be different "contribution tiers", a fixed percentage of the proceeds go to each tier, for each tier the allocated percentage is be distributed evenly.

Agreed this would be nice, though this layer of complexity introduces a bigger attack surface for bad actors. They could try to get their modules listed as dependencies of popular projects to piggyback on their downloads. On the flip side there are some low-level tools (say, the `stylis` CSS autoprefixer) that are almost never used in their "raw form" but are the backbone of several massively popular projects. It's a tricky balance.

Author here - 100% agree on all fronts! I was dancing around this conclusion but it really does need to be GitHub.

And I agree people would be fine paying their own fees if it came to that. Also, in that case, if someone is donating a non-trivial amount, they're incentivized to fund their wallet with a cheaper payment method like an ACH transfer.

Good point, that characterization isn't exactly accurate. Though the first-order point is that you have to go through a separate "checkout process" each time you want to sponsor a new thing.

I actually think it's important that the pools themselves contain projects not users/organizations. There are definitely complications I hadn't considered if multiple entities/organizations are listed as maintainers of a particular project. Presumably the set of maintainers would have a way to "split" the incoming donations among themselves as they see fit.

[edit] I added a footnote to address this.

Fair enough.

Though the ability to curate your personal pool is an important piece of the puzzle.

Great stuff here. Do you think these are fundamental dealbreakers? Put another way, could an entity like GitHub build satisfactory solutions to these?

Forcing donors to fund their wallets with ACH transfers seems like an easy way to sidestep a lot of this (except the trustee issues).

I like that idea too. Though it definitely may lead to some troubling scenarios where bad actors try to get their modules listed as dependencies of popular projects to piggyback on their downloads. You could alleviate this by not funding dependencies of dependencies but there are some low-level tools (say, CSS autoprefixers) that are rarely used in their "raw form". It's tricky.

You don't get paid unless someone adds you to their sponsor pool. If no one knows about your thing, you don't get paid. Am I misunderstanding your question?