That's surprising, given that SQLite itself supports binding and sanitizing query parameters via sqlite_bind_*(). Is SQLx just blindly calling sqlite3_exec() instead of doing the prepare→bind→step→finalize sequence itself?

> Note: query parameters are not supported.

> Query parameters require the use of prepared statements which this API does support.

> If you require dynamic input data in your SQL, you can use format!() but be very careful doing this with user input. SQLx does not provide escaping or sanitization for inserting dynamic input into queries this way.

> See query() for details.

    <a href="/?page=2" hx-target="#dashboard-content" hx-boost="true">
      Next Page
    </a>

Also the article seems to be full of errors. Eg

> In HTMX, if the server returns a 500 error, the browser might swap the entire stack trace or the generic error page into the middle of a table by default. This is a poor user experience.

This is simply incorrect. By default htmx does not swap 4xx/5xx responses. Instead it triggers an error event in the DOM. Developers can choose to handle that event or they can choose to override the default behaviour and do a swap.

If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/

One of the options on that page is MSYS2, which I specifically listed above alongside MinGW-w64. And that download page is much smoother sailing: https://www.msys2.org/

There are other options on the MinGW-w64 page, but most of those are for cross-compiling from non-Windows operating systems (which conceivably could include something running on WSL these days), and of the Windows-host options, the only two with “many” packages are Cygwin and MSYS2 (though WinLibs looks interesting).

Supporting Windows without MinGW garbage is really really easy. Only supporting MinGW is saying “I don’t take this platform seriously so you should probably just ignore this project”.

I bet it would burn a lot of money very fast and not just on tokens.

Re: pipe tracing, half a decade or so ago I made a little language called OTPCL, which has user-definable pipeline operators; combined with the ability to redefine any command in a given interpreter state, it'd be straightforward for a user to shove something like (pardon the possibly-incorrect syntax; haven't touched Erlang in awhile)

    'CMD_|'(Args, State) ->
        io:print("something something log something something"),
        otpcl_core:'CMD_|'(Args, State).

Downside is that you'd have to do this for every command defining a pipe operator (i.e. every command with a name starting with "|"); alternate user-facing approach would be to get the AST from otpcl:parse/1, inject log/trace commands before or after every command, and pass the modified tree to otpcl:interpret/2 (alongside an interpreter state with those log/trace commands defined). Or do the logging outside of the interpreter between manual calls to otpcl:interpret/2 for each command; something like

    trace_and_interpret([], State) ->
        {ok, State};
    trace_and_interpret([Cmd|Tree], State) ->
        io:print("something something log something something"),
        {_, NewState} = otpcl:interpret([Cmd], State),
        trace_and_interpret(Tree, NewState).

https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuc...

Yes, there was: becoming the primary contributor by volume to Scots Wikipedia (which probably doesn't have many contributors to begin with, but there you are). Some people just have to have attention, no matter how.