deobald

Thanks for this! I'd like to drop a note of explanation here, for future readers:

Yes, anyone can "just create a LinkedIn account." However, quite a few people across the globe are trying to decrease their online surface area. While many of us (myself included) just have a password manager filled with thousands of entries and 32-character passwords, some folks are not comfortable living that way. I also find myself unsubscribing from or filtering emails from these services at least once a day, so I can appreciate why many folks are increasingly trying to simplify their lives by eliminating SaaS logins.

Even without creating a LinkedIn account, one could fill in a dummy URL to satisfy the JavaScript validation and submit the application. However, we chose not to do this because of how the YC application itself is structured. The submission requirements are intentionally strict (60 second founder video, <3mins demo, very specific questions, etc.) and subverting the application process feels antithetical.

Having the option to opt out of the LinkedIn field is greatly appreciated.

We did try to get WASI to work, but ECL itself doesn't yet target it. It fell down on missing set/longjmp support in wasi-libc. We haven't tried WASIX yet.

There are other approaches than the one we've taken so far, and we're still experimenting. But for the current demo, we're quite happy with Emscripten. The entire Wasm ecosystem feels pretty darn magical. :)

Endatabas team here. Thanks for clarifying why this post was marked as a dupe.

We recently released our Beta, including a live in-browser demo built on Wasm. It seems the OP noticed our release somewhere, but didn't mention the Beta or the Wasm build in their new post.

Take care, -steven

This is really handy and, frankly, less confusing than doing all of this with GUI tools on MacOS. ;) Thanks for publishing this!

As mentioned in another branch, I took a stab at writing up a "What?" page to pair with the "Why?" page: https://docs.endatabas.com/appendix/what.html

It tries to be less wordy. :)

Same as above, I'd love your feedback, if you have any. Our Discord is on the homepage, if that's easier than email.

I took a stab at writing up a "What?" page to pair with this: https://docs.endatabas.com/appendix/what.html

It tries to be more concise. :) Would love your feedback, if you have any. Our Discord is on the homepage, if that's easier than email.

I think the documentation you're looking for is here:

https://docs.endatabas.com/sql/path_navigation.html

I've just pushed a change mentioning that paths can be used in both SELECT and WHERE clauses. Sorry for the ambiguity.

For example:

`select * from stores where addresses[0].city = 'New Jersey';`

...can be used on the demo data, found here:

https://www.youtube.com/watch?v=oDHGjUMqPvI&t=140s - demo

https://github.com/endatabas/marketing/tree/main/2023-09-dem... - code

HTH!

txtai looks cool! It's not obvious from the title of the post, but Endatabas isn't really comparable to SQLite in this way. Endb is a cloud-native columnar immutable database with separated storage and compute. Only the SQL grammar is SQLite-inspired.

That said, the significant dialect difference is that Endb's JSON-like documents are strongly-typed. One of the places the Endb SQL dialect diverges from SQLite's is typing. In this respect, SQLite is "more schemaless"... at least at the level of weakly-typed scalars and nested JSON (since JSON supports a diminutive set of types).

Endb's data types, their exposed JSON-LD types, and internals: https://docs.endatabas.com/reference/data_types.html

Endb's SQL data types: https://docs.endatabas.com/sql/data_types.html

...all of these can be used at any nesting level, which makes nested data in Endb quite different from JSON.

Hope that helps explain the difference!

(I'm involved in the Endatabas project and happy to answer other questions or clarify this.)

While acknowledging you're only addressing the Copeland paper (and not Endatabas, where the OP found it), here's the Endatabas solution to this problem:

https://www.youtube.com/watch?v=oDHGjUMqPvI&t=129s

Apologies for the hijack. :)

I'm involved in the project.

The temporal columns are intrinsic to Endb, but they are completely optional. By default, Endb queries run as-of-now, which then return the same results one would expect from a regular Postgres database.

Postgres temporal tables can't make Postgres natively aware of time, so temporal queries tend to be awkward, even if you want the default as-of-now result.

There are temporally-aware databases (SAP HANA, MySQL, SQL Server), but they all treat time as an additional concept layered on top of SQL-92 via SQL:2011. It's difficult for a mutable database to assume immutability or a timeline without becoming another product.

`entity_history` and similar audit tables aren't comparable at all, since they don't even involve the same entity/table, which means all querying of history is manual. Indexing of audit tables is at least a bit easier than the SQL:2011 temporal solutions mentioned above, though.

In all these cases, schema is still an issue that needs to be resolved somehow, since (again) incumbent relational databases assume a Schema First approach to table layout. Endb is Schema Last and allows strongly-typed nested data by default.

The Endb demo is pretty recent, and explains all of this in more detail, with examples:

https://www.youtube.com/watch?v=oDHGjUMqPvI

I get the impression this was discovered in the Endatabas bibliography, since the same user just posted a link to the quickstart.

https://www.endatabas.com/bibliography.html

...Copeland's paper is a fun and inspirational read. If you enjoy that, you'll probably enjoy other papers from this list.

I'm a huge fan of Luis Villa's "Open(ish) Machine Learning News":

https://www.openml.fyi/

There's a heavy focus on the intersection of AI and law ... but that's definitely an interesting space right now (and for the foreseeable future).

The argument for pure functions holds in a real system; these particular signatures will be familiar to anyone who's built a few Clojure web services. In reality, some of the functions listed (say, `get-article`) would disappear entirely into a system-specific convention. There's a balance to be had between the number of seams the team is managing directly and those which, by their creation, mean less cognitive overhead. The seams then exist only if they are required, as certain handlers might choose to diverge from the conventional functions used in a generic way.

It's of course not easy to see that next step from the article, since it doesn't eliminate any code by creating pure functions. But even in a toy example, there is value of creating pure functional abstractions. In some codebases, you might even see the team lead segregate pure functions by namespace: "Pure stuff over here, tainted stuff over there." In those situations, teams try to reduce impure surface area -- in this case, anything that touches the `db` namespace.