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.
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).
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:
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:
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.
The trouble with these sorts of approaches is that they solve temporality the same way we did in the 90s: Add an `entity_history` table, timestamp your tx-time and valid-time, and add a trigger to version your entities. This must be done for each entity you want to version across your temporal plane.
It would appear that `temporal_tables` doesn't support bitemporality yet. It only has tx-time (system time). But even if it did, this approach doesn't help you with live data. Because the `entity` table corresponding to the `entity_history` table still permits destructive updates, temporal queries are always in the realm of audits and can't answer questions about the application data directly. Add to that a completely manual system of querying the temporal information, and the resulting systems tend to get quite hairy, which is why Martin recommends avoiding bitemporality whenever you can. Unfortunately, that recommendation (while sound, for relational databases) means that bitemporality is expensive and manual if and when it's implemented.
A bitemporal database like Crux encodes the temporal plane into all the data stored in it, making it transparent to the user. There's no up-front setup cost to bitemporality and a query's default time on both time axes is "now", allowing the user to ignore temporality entirely except in those few instances where it is required -- but when it is required, it is global.
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.