n_e

Unless things have improved it's also hideously slow, like trivial queries on a small table taking tens of milliseconds. Though I guess that if the alternative is google sheets that's not really a concern.

Worker threads can be more convenient than FFI, as you don't need to compile anything, you can reuse the main application's functions, etc.

For example PTFE is a large molecule with strong bonds, and as a consequence isn't very reactive and likely safe.

On the other hand, perfluoroalkyls such as PFOA have the same shape as fatty acids, so they bind to the same places such as in the liver, which makes them grave health hazards.

Many precursors used for making PFAS are also toxic, so for example, even if PTFE is safe, manufacturing it isn't.

I don't agree at all. With tools like Zod, it is much more pleasant to write schemas and validate the file than with XML. If you want comments, you can use JSON5 or YAML, that can be validated the same way.

  const totalEstimatedTaxesPaid = writable("totalEstimatedTaxesPaid", {
    type: "dollar",
  });
  
  const totalPayments = fact(
    "totalPayments",
    sum([
      totalEstimatedTaxesPaid,
      totalTaxesPaidOnSocialSecurityIncome,
      totalRefundableCredits,
    ]),
  );
  
  const totalOwed = fact("totalOwed", diff(totalTax, totalPayments));

The code that processes the graph will also be simpler as you don't have to parse the XML graph and turn it into something that can be executed.

And if you still need XML, you can generate it easily.

  (c) The contribution was provided directly to me by some other
      person who certified (a), (b) or (c) and I have not modified
      it.

It doesn't really matter what tools are used if the result is good

Performance-wise, I get about half the throughput I had with the same processsing done it rust, which doesn't change anything for my use-case.

However that's not really relevant to the context of the post as I'm using node.js streams which are both saner and fast. I'm guessing that the post is relevant to people using server-side runtimes that only implement web streams.

In fact, stockfish's WDL is very rudimentary: it is a function of the centipawn evaluation of the position and the value of the remaining material.

See https://github.com/official-stockfish/Stockfish/blob/a6d055d...

Regarding the nominal/branded types, the typegen is configurable, so instead of e.g. mapping oid 20 to a bigint, you could map the field id of table foo to Foo["id"] from kanel.

see this example https://github.com/n-e/pg-typesafe?tab=readme-ov-file#type-j...

For now, I type these manually, which is acceptable for my usage as they are pretty rare compared to static queries.

In another style, postgres.js uses calls such as sql`select * from t where id = ${variable}` (which is safe because it's a tagged template, not string interpolation).

It would be quite easy to extract the queries to compute the types, but TypeScript doesn't handle tagged template literals well enough to link the query passed to the sql`` template to the return type.

I see they use the same global approach as pg-typed (asking for a ParameterDescription / RowDescription, which aren't usually exposed by the PG drivers), but there are interesting differences in the details. Also this made me realise that I could also type enums automatically.

Regarding sqlc in general, it is focused on having the SQL queries in .sql files, while pg-typed is focused on having the queries inline (though I plan to add .sql file support). I like the latter approach better, as for small queries used in only one place, it is a little cumbersome to add them to a different file and find a name for them.

I've used kysely before creating pg-typesafe, and came to the conclusion that writing SQL directly is more convenient.

A query builder works well for simple cases (db.selectFrom("t").where("id","=","1") looks a lot like the equivalent SQL), however, for more complicated queries it all falls apart. I often had to look at the docs to find how to translate some predicate from SQL to the required idiom. Also, I don't think kysely can automatically infer the return type of PostgreSQL functions, while pg-typed does (it asks PostgreSQL for it).

For example, in one project, PRs have to be submitted to the "next" branch and not the default branch. This is written in the CONTRIBUTING.md file, which is linked in the PR template, with the mention that PRs that don't respect that will be close. Most if not all submitters of low-quality PRs don't do anything once their initial PR is closed.

Pretty bummed about that as I just submitted a show HN I'm pretty happy about (it solves an annoying problem I had for years, which I know many people have) and I was looking forward to talk about it (https://news.ycombinator.com/item?id=47050872)

I have one job that runs a shell script that runs tests, a second one that builds and pushes the docker image, and a third one that triggers CD.

Could it be faster? Yes. Could the log viewer be better? Yes. Could the configuration file format be better? Yes. Could the credentials work better? Yes.

However they're well integrated with GitHub (including GHCR), work well and are affordable.

Equivalent delete queries in rest / graphql would be

  curl -X DELETE 'https://api.example.com/users/123'

  curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'