We have collaborated with MotherDuck on streamlining the experience of launching the UI through auto-installation, but the DuckDB Foundation still remains in full control of DuckDB and the extension ecosystem. This has no impact on that.

For further clarification:

* The auto-installation mechanism is identical to that of other trusted extensions - the auto-installation is triggered when a specific function is called that does not exist in the catalog - in this case the `start_ui` function. See [1]. The query I mentioned just calls that function. The only special feature here is the addition of the CLI flag (and what that flag executes is user-configurable).

* The HTTP server is necessary for the extension to function as the extension needs to communicate with the browser. The server is open-source as part of the extension code [2]. The server (1) fetches web resources (javascript/css) from ui.duckdb.org, and (2) communicates with localhost to co-ordinate the UI with DuckDB. Outside of these the server doesn't interface with other external web services.

[1] https://github.com/duckdb/duckdb/blob/main/src/include/duckd...

[2] https://github.com/duckdb/duckdb-ui

To be specific, the work we did was:

* Add the -ui command to the shell. This executes a SQL query (CALL start_ui()). The query that gets executed can be customized by the user through the .ui_command option - e.g. by setting .ui_command my_ui_function().

* The ui extension is automatically installed and loaded when the start_ui function is executed - similar to other trusted extensions we distribute. The automatic install and load can be disabled through configuration (SET autoinstall_known_extensions=false, SET autoload_known_extensions=false) and is also disabled when SET enable_external_access=false.

[1] https://duckdb.org/docs/data/parquet/metadata

Could you perhaps open an issue [1] or share the file with us so we could investigate the problem?

[1] https://github.com/duckdb/duckdb/issues

[1] https://www.vantage.sh/blog/querying-aws-cost-data-duckdb

[1] https://www.lifehacker.com.au/2020/01/what-happened-to-googl...

[1] https://duckdblabs.com/news/2022/11/15/motherduck-partnershi...

SQL as a language is statically typed. It has variables that are statically typed [1], much like Typescript. All columns in a query have fixed types, and there is a separate compilation phase that resolves types of parameters - much like any other statically typed language.

SQL generally operates on tables - and tables model a persistent, shared data source. The Typescript equivalent to a table is JSON files on disk. There is a fundamental need to be able to change data sources as time goes on and business requirements change. That is why SQL supports modifying shared data sources, and supports operations like adding columns, changing column types and dropping columns. SQL deals with the fact that changes can be made to tables by rebinding (recompiling) queries when a data source is changed.

Any hypothetical language that will replace SQL will have to deal with the very same realities of people wanting to modify shared data sources. A different language cannot solve this problem because there is a fundamental need to change how data is stored at times.

Perhaps what you are looking for is better tooling around this problem. SQL can be used to power such tooling, because of its strong static type system that works alongside the persistent shared data source. For example - you could check if all your queries will still successfully compile after changing the type of a column.

[1] https://www.postgresql.org/docs/current/plpgsql-declarations...

If you are working in a hypothetical adversarial world where people are changing data types out from under you then that might happen. That will also happen with any other shared data source, regardless of what language you might be using. If you are sharing a set of JSON documents and people start altering documents and removing keys then your Typescript program that ingests those documents will also start failing.

That is not a problem of the language but a fundamental problem of having a shared data source - changing to a different language will not solve that problem.

I think you are conflating SQL the language with a relational database management system. A relational database management system models a shared data source - and a shared data source can be modified by others. That introduces challenges no matter what language you are using.

> What do you think "" + 42 executes to, then? The thing is, it doesn't execute because it doesn't satisfy the type constraints. It fails before execution. If it were a weakly typed language, like Javascript, then execution may be possible. Javascript produces "42".

It is fundamentally different. Given a Python program, you cannot know whether or not it will produce type errors at run-time without executing the program. Type checking is done at run-time as part of the execution of the "+" operator. In SQL, type checking is done as a separate compilation step that can be performed without requiring any data. In Python the object has a type. In SQL the variable has a type.

Given a fixed database schema and a set of queries, you can compile the queries and know whether or not the queries will provide type errors. You cannot do this with Python.

> Not at all. The benefits of something like Typescript is that the guarantees are provided during development. SQL cannot know the types ahead of time – they don't exist until the program has begun execution – and will throw errors at you in runtime after you've moved into production if you've encountered a problem. That's exactly when you don't want to be running into type programs, and why we're largely moving away from dynamically typed languages in general.

SQL can provide the same guarantees as Typescript. However, unlike Typescript in which the variables are fixed, SQL always deals with processing data from an external data source - the tables. The data sources (i.e. tables) can be changed. That is not a problem a language can solve.

It is distinct from Python because in Python individual objects have types - and type resolution is done strictly at run-time. There is no compile time type checking because types do not exist at compile time at all. Note how in my example I am preparing (i.e. compiling) a query, whereas in your example you are executing the statement.

If you refrain from changing the types of columns in a database and prepare your queries you can detect all type errors before having to process a single row. That is not possible in a dynamically typed language like Python, and is very comparable to the guarantees that a language like Typescript offers you.

For example - this query throws a type error when run in Postgres during query compilation without executing anything or reading a row of the input data:

   CREATE TABLE varchars(v VARCHAR);
   PREPARE v1 AS SELECT v + 42 FROM varchars;

   ERROR:  operator does not exist: character varying + integer
   LINE 1: PREPARE v1 AS SELECT v + 42 FROM varchars;
                               ^
   HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.

To get an impression of the performance penalty, just run the following query:

  SELECT SUM(i) FROM generate_series(0, 1000000, 1) tbl(i);

Now that is not WASM's fault - when running the same query in duckdb-wasm [1] on my laptop the query takes 10ms using WASM, and 5ms when run locally, with a slow-down of only a factor of 2. But in order to achieve those results we did have to adapt the DuckDB codebase to compile natively to WASM. That is absolutely possible but it does take engineering effort - particularly when it comes to larger older projects that are not designed from the ground up with this in mind.

[1] https://shell.duckdb.org

[1] https://en.wikipedia.org/wiki/ACID

  D CREATE TABLE passwords (hash TEXT, count INT);
  D COPY passwords FROM '~/Downloads/pwned-passwords-sha1-ordered-by-hash-v8.txt' (SEPARATOR ':');
  D .timer on
  D SELECT \* FROM passwords WHERE hash=upper('5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8');
  ┌──────────────────────────────────────────┬─────────┐
  │                   hash                   │  count  │
  │                 varchar                  │  int32  │
  ├──────────────────────────────────────────┼─────────┤
  │ 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 │ 9545824 │
  └──────────────────────────────────────────┴─────────┘
  Run Time (s): real 0.005 user 0.007455 sys 0.000584

The only real way out is to make Python 4 - but given the immense pain of the Python 2 -> 3 transition that seems unlikely.

[1] https://www.pypy.org

Nobody in the Netherlands bikes with a helmet, and it is incredibly safe to bike here (around 10X fewer fatalities per KM ridden than in the US). If you want evidence that biking without a helmet is perfectly safe - there you go. A case study done by an entire country with 18 million inhabitants for a period of 100+ years.

Bike safety is an infrastructure problem. Nothing else.

Wearing a helmet will not make up for bad infrastructure - biking with bad infrastructure and a helmet is still incredibly dangerous. After you have good infrastructure, biking is already safe, especially when you use a Dutch bike that forces you to sit upright [1] making it far less likely you will fall on your head.

Wearing a helmet might improve safety by a marginal amount beyond that - but so would wearing a helmet while walking, or wearing a helmet while in a car.

Comparing helmets to seat belts is nonsensical. A seat belt is attached to your car. A helmet has to be carried with you after you leave your bike. Once you use a bike for everything that means you must carry a large helmet with you everywhere you go. It is very inconvenient for people that actually use bikes as their daily mode of transportation, from going to work to going grocery shopping to going to the gym.

[1] https://www.youtube.com/watch?v=aESqrP3hfi8

Having a seat belt in a car is far less of an inconvenience than carrying around a helmet. If mandatory helmet laws cause people to take a car to the supermarket instead of biking then *more* people will die. Not to mention the immense congestion and destruction of the planet this will cause.

> Cars have tons of safety regulations built into them and seat belt laws are pervasive. I don’t expect them to relax over time either, cars are much safer than they ever have been and I expect their safety will continue to improve year over year.

Cars have safety features for their passengers - meanwhile they are by far the most lethal mode of transportation worldwide. Should we only care about people inside a car, or should we perhaps start caring about *all people*?

> Can you say the same thing about the bicycle? What safety features do they have? The helmet is the only one I can think of.

How about not going at very fast speeds? What safety features does "walking" have? Should we now start wearing a helmet while walking?

Universities and schools need to accept that writing essays without AI support will simply not be a useful skill anymore, much like doing complex arithmetic without a calculator is not a useful skill anymore. Instead, they should focus on teaching students how to use AI support as a tool to write better, more comprehensive texts, rather than try and force students to write without it. That will ultimately make the students more productive members of a society in which AI supported writing is ubiquitous.

This compiles:

  struct BigStruct {
    int my_array[4];
  };
  int main() {
    struct BigStruct a;
    struct BigStruct b;
    b = a;
  }

  int main() {
    int a[4];
    int b[4];
    b = a;
  }