OP seems not broadly applicative to corporate software development.
Rather, it's directed at the kind of niche, mission-critical things, that not all of which are getting the formal verification solution that is needed for them and/or that don't get considered due to high costs (due to specialization skill).
I read OP as a realization that the costs have fallen, and thus we should see formal verification more than before.
By "JSDoc is TypeScript", culi means "JSDoc syntax and TypeScript syntax are two alternative ways to describe types to the TypeScript compiler/language services, and the two syntaxes have nearly-identical expressive power".
I understood it that way too. Only that it fails in that interpretation.
Just because currently the most popular method for parsing JSDoc utilizes TypeScript-related tooling doesn't mean we should associate them with each other.
To my previous example, an ISO C++ can be compiled by GCC but also can be compiled by Clang (and many other compilers).
Perhaps I should've expanded further to "the specific JSDoc dialect supported by the TypeScript compiler and TypeScript syntax are two alternative ways to …".
Unlike ISO C++ I'm not aware of any standard for what JSDoc is outside of specific implementations. There's a bunch of stuff documented on https://jsdoc.app/ but it only partially overlaps with the JSDoc syntax that TypeScript uses, and is not what the article is talking about.
The situation is not unlike Markdown before the CommonMark standard (except with less pressure to standardize, because most codebases are written with specific tooling in mind). Maybe we should refer to it as "TypeScript-flavored JSDoc".
Already-established top-of-the-market apps will not be dethroned overnight.
For them, it will be a slow death (e.g. similar to how Figma unseated Adobe in the digital design art space).
As for new app markets, you will surely see (compared to past generations) smaller organizations being able to achieve market dominance, often against much more endowed competitors. And this will be the new normal.
libSQL is our fork of SQLite. It adds new features on top of SQLite, such as vector search, replication, server mode, and more. libSQL is open source (MIT license).
The Turso SaaS platform, which provides hosted databases, is not open source.
Limbo (which will be renamed to Turso in the future) is our Rust rewrite of SQLite. It is also open source (MIT license) - https://github.com/tursodatabase/limbo
Seems not really or only partially anyway; I cannot see, with disasters like Fauna, that anyone would trust their core stuff with something not open source. But maybe it's just me. I need to be able to switch and sure, I can switch to the open source fork libSQL (open core I think, so nope) (which they are rewriting to Rust for some bizarre reason; sqlite is one of the most readable, robust and well tested codebases in the business so it looks like burning vc money, but whatever), but once my business depends on their offline / replication / etc, then I cannot switch to anything, so never going to happen.
Again, opinion. It's core infra, in my opinion at least that should never depend on others or, if the others inevitably screw you over for a few $, you need to be able to move without possibly bankrupting your company.
They are open-core. The offline-write feature (libsql::Builder::new_synced_database) basically does not work with the bare `sqld` server on their `libsql` github repository.
In fairness though their `libsql::Builder::new_remote_replica` works with the bare `sqld`
Technically the project name remain being Limbo until the milestone[1] be reached. AFAIK the platform continue to use libSQL, given the early stage of Limbo.
That’s a tall order; by SQLite’s own estimates, SQLite is used more than all other databases combined and may even be the most widely deployed software component, ever: https://www.sqlite.org/mostdeployed.html
It is very interesting that there is no “code of conduct” in the Limbo project, given that there is one in libsql [0]—I wonder if they realized that playing the whole “the SQLite Code of Ethics is bad and wrong, actually” card [1] wasn't turning out to be as popular of a move as they thought it would be. Or, at the very least, they realized that if you're going to shit on SQLite for having a “code of ethics”, then it's better to not provide a “code of conduct” rather than to provide one (even though the entire impetus for SQLite writing their Code of Ethics was some projects required they have some sort of “code of conduct” in order to use SQLite…)
I know it's super lame to regurgitate LLM output in comments, but I found it interesting that Grok was able to infer [2] what I was talking about when I made this accusation on X some months ago, and it absolutely nailed basically everything I had in mind:
---
Q: Why might Adam think Limbo is an example of "EEE" so "brazen" as to resemble Microsoft in the 90s?
A: Adam Rezich's comment suggests that Pekka Enberg's project, Limbo, could be seen as an example of "Embrace, Extend, Extinguish" (EEE) tactics, which were notably used by Microsoft in the 1990s. Here's a breakdown of why Adam might think this:
1. Embrace: Limbo starts by embracing SQLite, a widely used, open-source database engine. By aiming for full compatibility with SQLite, Limbo acknowledges and adopts the existing technology, similar to how Microsoft would integrate or support existing standards or technologies in their products.
2. Extend: Limbo extends SQLite by rewriting it in Rust, adding new features like built-in vector search and asynchronous I/O, which are not part of the original SQLite. This extension phase is where Microsoft historically added proprietary features or extensions to standards, making their versions more appealing or functional in certain ways.
3. Extinguish: Although Limbo hasn't reached this phase yet, the potential for extinguishing could arise if Limbo becomes superior enough to make SQLite less relevant or if it leads to a market shift where SQLite users migrate to Limbo due to its enhanced capabilities. Microsoft in the 90s would often extend standards in such a way that their versions became the de facto standard, overshadowing or making competitors' versions obsolete.
The "brazen" aspect comes from the transparency and public nature of the project. Unlike Microsoft's more secretive and strategic approach in the past, Limbo's development is open, with Enberg sharing his plans and progress publicly. This openness, combined with the ambitious goal of completely rewriting a foundational piece of software like SQLite, might seem bold or even audacious, reminiscent of Microsoft's aggressive market strategies but done in a more transparent and community-driven manner.
---
The only thing Grok didn't mention was the overt emphasis on the “community” aspect of this project, which is being promoted as being strictly, even obviously better than sqlite3's way of doing things. For me personally, sqlite3 not being a “community”-focused project is actually a huge advantage—modern programming “communities”, while being good for building hype and allegiance for one's project, generally result in very unpleasant nth-order social effects which have nothing to do with the quality of software.
Neither you nor the linked comment provide any context for that. Is it not possible that Israel blocked because of a request by the Israeli government, and not because of a political statement?
I guess, good on them for at least blocking the country outright and being honest about it, and not sneakily distributing malware like some very good people did to Russians back in 2022.
I don't think your use of "surely" was very cordial, but I'll indulge your point, thanks for taking the time to respond. If I were a lawyer, I would label those points circumstancial at best:
(1) I'm not sure to which organisation you were referring, but on its own I don't think a link contitutes endorsement, especially when the context is the open source project and not political in nature. It's worth noting that there are a lot of external links in the readme, none looked at the surface level to be linked because of any reference to BDS therewithin. That said, I don't think we should argue this further, it's already innapropriate to comment on political topics such as Israel and BDS here on HN.
(2) Again, the exact cause for this is not clear. There are possible explanations which suppose good faith, and others, bad faith.
(3) While personally I'd lean towards your interpretation (especially considering the use of quotation marks by the poster), it's still not explicit and could be a communication failure.
> I'm not sure to which organisation you were referring [...] It's worth noting that there are a lot of external links [...] none looked at the surface level to be linked
Literally the first link in the README.
website -> Incubator -> "list of projects we’d love to get started!":
> ### Built with Israel
> Many companies and NGOs unwittingly use tools created by Israel
> ### BDS in your bank account
> Build an app that can apply BDS to your bank account.
or
website -> Blog -> "T4P Incubator Alum Boycat Is Teaming Up With BDS"
If you can't figure out what the first website link is in the README that's on you. I'm not gonna promote that hateful organization's website.
> expect users to connect to the service using multiple devices (clients).
But probably using only one device at a time by a single user?
My thought, and it is just a thought, here is that instead of trying to provide a GENERAL solution for all kinds of data-update patterns, it is often possible to think in terms of what my current application specifically needs. It is easier to come up with such a solution with SQLite per app because SQLite is so "lite".
I can't speak for the "general solution" except to say that many times you don't need an all-encompassing general solution, just a solution for your current app.
> But probably using only one device at a time by a single user?
It depends on your expectations of concurrent use. Computer + tablet + phone means many users may use different devices within seconds of each other. If you want to support offline-first usage, concurrent updates from different clients for the same user becomes more likely.
