alde

Thanks! A grouping feature will definitely be useful, I have been thinking about a good way to add it to pgtyped.

Will grouping fields by tables they belong to good enough? Or is there some different grouping logic you have in mind?

Sqlx looks nice! I had some ideas about porting pgtyped to rust and utilizing macros to do query type inference at build time, but was worried that such db-connected macros will slow down the build process. Nice to see that it worked out for sqlx.

I think you misunderstood my point. You mentioned that "SQL isn't type-safe", which is NOT true. Any decent RDB engine allows to perform typechecking and validation of your query without executing it. This means that SQL is typesafe at compile time.

Well, all I am saying is that PostgreSQL provides you with compile-time type-safety when your write your queries.

Bringing this type information at "compile-time" into your language of choice where you embed your queries can also be done but is a harder problem. There is good progress in that sphere but it is still in it is infancy.

The GraphQL eco-system for example, has this figured out using code generators. A similar thing can be done with DBs.

This looks great and should surely cover most of the CRUD needs of simpler apps and hopefully even more. On the other hand, in my experience such complicated abstractions eventually leak, especially due to the complicated nature of the relational model and modern SQL.

For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1].

In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has:

1) Realtime parameter/result type inference in their language of choice.

2) Has autocomplete and validation in their IDE

3) Is composable, allowing to join queries/sub-queries..

So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way.

[1]: https://github.com/adelsz/pgtyped

SQL is as type-safe as the DB engine allows it to be. PostgreSQL is type-safe. Extracting these types and making them available and usable in your lang-of-choice at compile time is a different problem though.

I'm working on PgTyped, a code generator that makes it possible to use inline SQL in TypeScript code with guaranteed type-safety. https://github.com/adelsz/pgtyped

Imo, engineering types usually think about technical differentiation because they can potentially be good in it. Usually marketing/branding is very expensive and not very accessible for the average bright founder+engineer type.

PgTyped doesn't include a query executor. It transforms a query and its parameters into a format of parametrized query+parameter bindings, which are then sent into a Postgres DB driver of your choice. A proper DB driver sends the query+parameter bindings pair to the DB. This means that the actual parameter substitution is done on the Postgres server and so SQL injections are prevented on the DB server side. The driver we recommend and use is node-postgres. It does support parametrized query passing.

Yes, so true. Wish Facebook stated this explicitly on their projects readmes.

CL has some type checking features in some of its compilers, but this doesnt mean it is a typed language. Quicklisp is still in beta and is in no way even close to package managers like cargo or npm.

Hmm, interesting GQL endpoint name choice by NYT devs. https://en.wikipedia.org/wiki/Samizdat

For me Lisp was a lot of fun to learn and play with, but I dont think it had a chance to survive in modern production environment because: 1. Not typed 2. Absence of a proper package mechanism and package managers like cargo or npm

A cool fact is that mpv can hook into youtube-dl to play videos by youtube url. I use this a lot for music and 4k videos (mpv unlike browsers has good gpu decoding support on linux).

Isn't OCAML garbage collected, which should be too slow and memory hungry for system drivers.

Here is a service I know of: https://reconfigure.io/

I think this is a valid point. I can't imagine effectively managing side effects without global state like in Redux.

WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.

I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".

Yo, I heard you like browsers, so we put a browser in your browser, so you can surf while you surf.

Yes, FFs devtools are slow to the point of being unusable for me. I still use Firefox for general web surfing, but need to switch to Chrome for debugging/inspection.

You have almost formulated the no-hair theorem. https://en.wikipedia.org/wiki/No-hair_theorem

>"Please upload a photo of yourself that clearly shows your face. We’ll check it and then permanently delete it from our servers."

>"To determine if the account is authentic, Facebook looks at whether the photo is unique."

The two statements are a bit contradictory. They might delete the photo but they won't delete its signature/fingerprint, because they need the later to check for uniqueness of other accounts.

Looks like the part about translational invariance is wrong. Translational invariance is an invariance to translations, not rotations. If a model detects a rotated cat as a cat, then it is rotationally invariant.

A flat torus can be isometrically embedded in 3D space with a continuously differentiable embedding. Visualising this embedding using computer graphics was the aim of a French project, completed in 2012. Turned out a flat torus in 3D has cool looking fractal structure. http://www2.cnrs.fr/en/2027.htm

"Pound Sterling Made Smart People Feel Dumb" (Black Wednesday).

Nowadays, most JS is uglified/minified on build anyway. I believe that times when after-build JS code was readable for the end user are long gone.

Haha, this is hard to play with cVim bindings on Chrome. An insert mode inside an insert mode.