I can’t claim full understanding, but what I took away from it was that NVIDIA somehow ended up using GPL-licensed code in their proprietary drivers, possibly in a way that could incriminate the Linux kernel if not handled properly. My best guess (as someone with no kernel programming experience) is that NVIDIA sometimes contributes code directly to the Linux kernel that exists solely to support their proprietary drivers (the shims mentioned in the article). Apparently, these shims were exporting GPL-licensed code for use inside the proprietary drivers, which would be a violation of the GPL (unless NVIDIA made the source code for their proprietary drivers freely available in compliance with the GPL).

TLDR: (I think?) NVIDIA essentially infected the linux kernel with license violations to support their proprietary drivers, and the linux kernel devs are working to excise the violations and prevent anything like that going forward.

This is, in part, a correlation. To some extent, compiled Rust is fast because compiling Rust is slow. That is, Rust does a lot of work (static analysis) at compile time so that the runtime binary is as fast as possible.

This is a really neat concept. I love that they’re recognizing the tradeoffs of both tiling and floating window managers and imagining a better way.

I think the mosaic idea is interesting and has a lot of potential. I agree with their self-assessment that it’s success depends greatly on the simplicity and utility of the window preferred size API, and how willing/able app developers are to adopt it. This is unfortunately yet another place where the fragmentation of the Linux ecosystem shows it downsides.

Nonetheless, I’m really hopeful about this. I would love to see a future where mosaic window management becomes ubiquitous. But really I’d be happy as long as my desktop supports configurable workspaces.

> “the only primary difference was that one happens before the aggregation and the other happens after, and all the other implications stem from that fact.”

This is correct. The biggest implication of that difference is that, when you filter rows via a HAVING clause, the query will first select all the rows and aggregate them, and only then begin to filter them. That can be a massive performance hit if you thought that the filter would prevent filtered rows from ever being selected. Of course this makes perfect sense, there’s no logical way to filter an aggregate without first aggregating, but it’s not obvious.

> “PRQL’s simplification, rather than obscuring, seems like a more clear and reasonable way to express that distinction.”

My main point is that PRQL makes no distinction. If you didn’t inspect that SQL output and already know about the difference between WHERE and HAVING, you would have no idea, because in PRQL they’re both just “filter”. Hence, PRQL is not simplifying the complexity (you still need to learn the full SQL syntax and the specifics of how it works), but it does obscure (you have no hints that one of your filter statements will behave completely differently from the other).

As far as removing arbitrary SQL features, I agree that that is it’s main advantage. However, I think either the developers or else the users of PRQL will discover that far fewer of SQL’s complexities are arbitrary than you might first assume.

Because at the end of the day, SQL it what’s being run by the database. For example, in the Showcase on the front page, they have an “Orthogonality” example that demonstrates filtering both before and after an aggregation, which compiles to a WHERE clause and a HAVING clause respectively. WHERE and HAVING have very different impacts on SQL queries, and vastly different performance implications, but the simplification in PRQL obscures that complexity.

At the end of the day, the transpiled langauge will have to either support only a subset of SQL’s features, or else be at least as complex as SQL. It cannot support all of SQL’s features and yet be less complex, because it is just a wrapper around SQL.

I suppose for the right crowd, possibly people who run queries only once and do not care about performance implications, data integrity, etc., this could be a really useful tool. And in all fairness, they mention exactly that on their homepage:

"PRQL’s focus is analytical queries

PRQL was originally designed to serve the growing need of writing analytical queries, emphasizing data transformations, development speed, and readability. We de-emphasize other SQL features such as inserting data or transactions."

But for developers who need to maintain an application database, I don’t foresee this becoming a useful substitute for SQL.

This seems nice in theory, but the tradeoffs make me question it’s real world viability. It has to be a transpiled language, because SQL is so ubiquitous is may never die. And yet, because it’s a transpiler, I’m skeptical that it will actually be easier to write than SQL, because you’ll still need to know all the gotchas and eccentricities of SQL.

Maybe for users who already experts in SQL this would be a quaint alternative syntax. However, personally I’ve already invested so much time developing familiarity with SQL that I see no advantage in moving to a new syntax that would take more time to become deeply familiar with, and that my co-workers won’t understand.