TursoDB aims to be fully compatible with sqlite, so files you create with tursodb can be read by sqlite and vice-versa. Like sqlite, turso is in-process, so it runs alongside your application, which is quite different from postgres' client-server architecture.
The only think turso has in common with postgres is mvcc, which is a rather standard concurrency control model across modern databases. Idk if I answered your question :)
It's because Tcl, like SQLite, operates on a peculiar metaphysical principle: everything is a string until proven otherwise, and even then, it's probably still a string.
Also, D. Richard Happ, who we owe thanks for SQLite, was and perhaps still sits on the TCL Board (I may be wrong about that, but Happ holds significance in the TCL community).
In my mind:
Tcl is the quietly supportive roommate who keeps making coffee and feeding LISP-like functionality until the world finally notices its genius.
Lua sits across the table, sipping espresso with a faintly amused expression, wondering how everyone got so emotionally entangled with their configuration files.
Lua is one of the easiest configuration file formats I've had the pleasure of working with. Readable. Has comments. Variables. Conditionals.
Everyone (including me): "oh no, no, you don't want a full Turing complete language in your configuration file format"
Also Everyone: generating their configuration files with every bespoke templating language dreamed of by gods and men, with other Turing complete languages.
You could solve this with a capabilities permissions system. That way the config files can be written in the same language but have configured permissions that are different from the rest of the programming language. So you could restrict the config files from resources like threads, evaling source, making network requests and whatnot. Come to think of it you could even probably section off parts of the language behind capabilties such that the config files could be configured to be a not-Turing complete subset of the language.
TCL 9 brought some welcome string improvements, and things run faster overall. But in my case, it's hard to say how well that's actually played out, partly because I haven't done the work to find out. My TCL scripts and apps work well enough to allow me to be lazy about them.
Performance is up, but so is my inertia. So while TCL 9 could be transformative, for now it remains a white paper I've skimmed, not a revolution I've implemented.
I think TCL does an opaque thing, everything "is" a string, but if you don't use it as a string, it's actually stored in some optimized format. Then it converts back to a string on demand
I still prefer Lua personally. Their type system is easy for me to understand
Lua is simple and elegant, and I much prefer it to Tcl.
Lua is in games and in LuaTeX, and when you have the choice of embedding a LISP, a FORTH or Lua in a larger application, it is often the most maintainable, runtime-efficient and low-memory footprint option of all.
I enjoy Lua and use it professionally, but when bash (and AWK) don't suffice, the glue is Perl. Because it has pipes which you can use to connect the output of one command to the input of another, or to a file.
What would be the SQLite's equivalent to indexing starting from 1, not 0? Off the top of my head I can't think of anything that would go so much against the grain.
Pretty much agree, I honestly think that TB team should invest some more effort on evangelizing the double-entry model for non-financial scenarios, like managing stocks, booking a show ticket etc. The 1000x API improvement has been done, now people must know how to use it
It sounds awesome. I'm an a analytics guy using a lot of SQL - not a coder. Though I understand the OP writeup and the purported performance advantages. Can someone explain:
a) what Tigerbeetle data looks like in practice? Assuming it doesn't look like a regular table
b) how you use it, if you can't write sql queries?
c) separately, curious what double-entry would look like for stocks, tickets etc. E.g. I'm a venue and I have 1000 tickets in inventory & deferred revenue.. each time I sell a ticket I turn that inventory to cash and the deferred into a performance liability? Or no entries at all until a ticket is sold? Something else?
Similar, yes. But not near the same performance, TB is entirely built around this concept so they became pretty good at it. It's like comparing a lambo and a beetle (no pun intended).
But honestly, if double-entry really become a thing I foresee traditional DBMS agglutinating it just like they did with vector and object databases, getting the long tail of the market.
You could, but TB brings a whole lot of debit/credit primitives out of the box (making it dead simple for e.g. 2PC money movement across third party systems, or transactions of thousands of transactions, to express complex financial contracts)… that are Jepsen-tested, which run multi-AZ, and which would probably take months if not years to replicate on PG. Even then, the internal concurrency control of PG’s storage engine would just get hammered by the contention, and would struggle to approach TB’s replicated performance, even if PG were single node.
Nothing takes “months or years” anymore, if you really wanted this it could be done fairly quick by someone who knows what they’re doing and you don’t layer it in bureaucracy.
It would be nice. I can think of things for which I want to process a financial transaction and something else in one atomic transaction (e.g. selling a ticket - something I am working on right now) and have both content (e.g. product descriptions) and finance in a single store.
I first tried to expose the VDBE to public usage, so it could be easier to right hand-made bytecodes, but it would require an effort that I'm not quite have to a side project. So instead I'm extending SQLite's parser to accept things like `let <var> = <expr>`, and functions. Alongside, I'm doing a "standard library" so you could build web servers and stuff.
The thing I'm struggling with is managing execution state. I have the idea of doing transactional functions using function coloring (e.g async functions), so each function call opens a new savepoint, and the user could rollback a particular function call in case it got wrong. I put the deadline to be 31 October, if I manage to get this on time I'll post here on HN :)
One thing that stood out when I tried to learn and play Go was the tempo.
I'm a chess guy, and I like to play blitz with 5+0 and bullet (format equivalent to tik tok) so games tend to be frenetic, but it's quite rare to find a Go game on those formats, they tend to have 40+ min in time. And honestly, this is a big W for Go.
Blitz format is reasonably popular on KGS (once you get to a certain level) usually 10+0. Blitz is harder to find on Pandanet - but you can easily blitz on Fox.
Zero increment blitz go is a terrible idea IMX; people will just play nonsense moves after the game should be ended, and calling a moderator takes time. Go lacks the absolute nature of checkmate.
http://online-go.com has an interesting anti-stalling feature: If you pass several times it checks with KataGo. If KataGo is 99% sure you will win, either player can click a button to accept that result and end the game.
While reading I remembered "Hitchhiker's Guide to the Galaxy" where the whole world is a computer and everything in on Earth happened to a random person have a sudden insight about the meaning of life.
My two cents: I think computation is a bedrock concept in the universe, idk about the extent of this importance but it's something that was "discovered" and not "invented"
The only think turso has in common with postgres is mvcc, which is a rather standard concurrency control model across modern databases. Idk if I answered your question :)