antender

In case of client-server databases one alternative that works great is to open an ssh tunnel using "ssh -L" and just connect using gui tool to it.

Yep, in Russian xerring (ксерить) sounds way better because "ox" part is rarely used in native words.

We already had serverless db for ages and it's called ... Google Sheets. You can even query it with simple SQL-like language.

The problem with most other "serverless" databases is that they don't offer HTTP API to query them from restricted environments like serverless functions.

Good job, Mastercard (and Visa)! Now all people opposing Putin and trying to gather money for leaflets will have to use state-created MIR instead. Putin will be pleased!

Basically I think this syntax addition is nonorthogonal, isn't making SQL any more powerful, but isn't solving the main usability problem, which is composability of queries in any way. Like writing JOIN's is not complicated if somewhat wordy already.

The issue, as i see it, is that adding this feature complicates the language parser even more for not that much actual gains.

1) Implementation has to do some nontrivual rewriting into actual JOIN's which uses indexes, previous special cases like NATURAL were purely syntax sugar 2) All of the tooling that depends on parsing SQL need to add sensible support or else noone will even recommend to use this 3) It is useless for anyone using ORMs in the first place, they will continue to generate normal JOIN's (less actual impact) 4) For anyone using prepared statements it automatically goes to "is not recommended to use" list because it makes your JOIN's depend on existence of foreign keys and corresponding indexes, which are an optional feature DB still should work without. I've had tasks in my career when my team added or removed foreign keys, so this type of JOIN's would make migrations even harder to do. 5) So considering all of the above this is feature designed purely for REPL and for this purpose it is also kind of useless. I can imagine remembering and typing column names in normal JOIN's, but foreign keys usually have some long unintelligeble autogenerated name.

I, personally, feel like this is a rather pointless addition to an already somewhat bloated language. It it isn't saving that much typing (we have NATURAL JOIN's already, nobody is using them), is kind of inconsistent with other language principles (we should be able to join anything to anything if we need to, see SQL-89) and limits JOIN flexibility (you don't have to join with "=" operator, JOIN's supports different types of conditions and are equivalent to WHERE clause)

Java is for pussies, in Javascript you don't even give ***** if it is literally "null" or "undefined".

Yeah, and it's not even the funniest one of a bunch of different phrases. I really prefer adding dogs instead of horseraddishes: "да и пёс с ним".

Basically, the site is rebranding as OnlyBans :)

You mean something like Hyperdrive (formerly Dat) + Beaker browser?

This article is like reading Gulliver's Travels Part III: A Voyage to Laputa, but as a real-life thing. Can't stop laughing!