mamcx

Is interesting that this is how array langs work.

I bet will be easy to turn into a lib.

AND shipping.

This sound fantastic and Django is the main thing I miss from python.

htmx+ tailwindcss is the one combo that is right and I use it so seeing is the direction give me hope.

Some notes, I hope can be considered!:

- The main thing is the auto admin, then `auth`, is great that the `auth` is mean to have a one-to-one connection for your own extensions

- The main pain is that everything is tangled to the ORM and the auto-admin

What I have done informally is that with traits I have something like `ListQuery` and compose `Paginate(ListQuery)`.

Then pure descriptors of what the ui DO, but not what it looks like and not even html at all.

THEN, I inject the stucts/enums (all Ui is things like `Label{...}` with not logic at all in templating, all the server side is in charge of pre-render) into some templating and there is where the ui is alive, but replacing is 100% doable and expected.

What I miss is a way to introspect to auto-generate things more auto.

After read, it hit me that because sqlite is a DB, "editions" as-is not work.

Because it not tied to the data but to the code.

Instead, what I think should be is that the PRAGMAs become "data" that is always checked in full with "if manually set" and then on next "open" THEY GET APPLIED.

That is.

(and in the command line when open interactively they show up).

I read it as "tensors in programming*.

This also happens to "numbers", "integers" and such, because in the computer universe don't exist out math, only a subset(?) variation(?) of it

Well if the company have somebody like you it helps tons!

In the flip side:

the problem with a single system is that mundane things cause unavailability

Is multiplied by each "system" you add. The basic failures are relative easy to deal and understand, the ones introduced by more complex system who knows?

Probably the most important step that I miss:

How long would it take to procure a new server and restore from backup?

.. and applied to any complex extra you have.

For single system is viable (with something like nix) to go off for maybe half hour for what I see around, most of the time in procuring another machine (that what people do is to Bring any other machine it can not go to amazon and buy!) and restoring the backup.

Of course, I factoring that downtime is not "seconds or minutes" here, but neither I think many can do like that

P.D: all

Rebuilding my long ERP-like project to become more like a "business engine" to become a proper ERP backend (so it can cover most business scenarios and is multi-company, branch, currency, etc).

Have now the core done and working on a MVP UI to validate it.

One of the things I always wish to do properly was to model currency and unit of measure in full as core types, plus truly trace everything related to the business transaction from production to beyond the sale.

Looking into a persistent workflow engine like `temporal` now...

P.D: I'm debating if open source or not, in light of the AI-pocalypse...

When writing an API, it’s easy to unknowingly introduce a dangerous, implicit assumption: that the database is the ultimate source of truth. If a record is in the database, an application often treats it as authoritative. I want to explain in this post why that might be a very bad idea.

This premise is weird at best.

"the database is the ultimate source of truth" is not a "dangerous, implicit assumption", is the best rule you can get (and the rest of the post say so: all useful data comes from it!)

Instead the rest of the article is interesting on how to choose what to use for the hash, but not follow with this first paragraph :shrug:

I live in the ERP-adjacent world, and the vast majority don't have any of that, never have, and I pray most don't.

P.D: the business world is the one that needs AND tries everything, and most attempt to implement something is much worse than the simpler previous thing.

For most that I know and most I bet (even without knowing) add "high availability" or "warm standby" WILL CERTAINLY lead to worse availability.

In fact, the best setup for most people, and consider things from today (that you will see, not that different from mainframe days!):

- Single server on a *nix LTS/immutable distro with just the RDBMS + App backend, on decent hardware. Fast, lots of ram or whatever optional

- A true reliable backup system

- A decent network setup, ideally a VPN one for connect everybody, with good firewall, SSL and that is

More complex than this and is 90% certain is much worse, other 8% until the dude that do it and care leaves.

Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!

P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.

Once you see what good application of types look like, is far better sell!

Sure, the point I try to make is that if you add things useful for OLAP to a OLTP system you could pessimist the OLTP system (that most often is the source of truth)

YES!

The problem of all the datastores is that are applications (like Wordpress) so you are too late to fix anything deep.

We need "frameworks" (so each sub-component can be used as-is or even swapped) and even wondering what a "system level" data engine could be.

With the other comment about kdb+ and this show a misread of the article: The article AND ANY use of a columnar DB show the same issue: Point lookups are badly pessimized with both partitions on other columns and/or columnar.

That is why columnar DBs, not matter how impressive, are not used by OLTP workloads (and here this article point you can undo the advantages without pay attention at the consequences of partitions).

In general you WANNA see any people using your app.

Read an "accessibility" spec or a requirement or a UX "good practice" is not a substitute for see how people use it!

One of my anecdotes from back in the day: The secretary of a school that use the app I help develop call about problems reading data, that comes in CD. We can't do much by phone so I travel to the town to try to debug on site (bring dev tools in the day where that means diskettes and cds, we were transitioning from FoxPro 2.6 DOS to Visual Fox Windows 95).

Eventually after some time the secretary put the coffee cup in the CD tray.

Go figure!

The same with NixOS and in production. Even less than 15 minutes month.

LOL!

Something I learn doing this stuff +25 years is that support and custom development eat you alive, and is not profitable for small ISV like mine.

Sadly, I can't use Fox now so I more constrained and unable to give the same. That is why I rebuilding the erp as an engine (fancy name: "headless erp") and working in make a lang and maybe a custom RDBMS. But then I need a GUI builder to get the same idea!

Just a minor inconvenience!

Cool!

I have this dream of revive this kind of spirit (https://tablam.org).

I started with Foxpro 2.6 and it was a blast.

One of the very cool things Fox allow us was to ship their ability to `CREATE FORM, CREATE REPORT, BROWSE, etc` so the users can customize the app with the same power as us. This is one of the most important advantages of ERPs and such made with Fox and is still unmatched.

Aside: what is the best to read receipts/bank statements/invoices?

The other way is to make the tool UX do the semantic, ie:

`git split`

Something that I enjoy with jujutsu is that the semantics is the tool itself. ONCE you do that, the rest become easier!

Now why can't compilers do this sort of thing automatically?

Because they are not query compilers, ie: They don't know the data.

For example a query compiler could swap index to full scan because it "see" (by runtime statistics) the data not benefit for it.

In the other hand, an optimization here can pessimism there. So optimizers in general should be very conservative because butterfly effects!

I have read TONS of material about it*, and none of that is part of the majority of that!

In fact, the "backend" be compiler or interpreter is nearly always left as "exercise to reader".

You can't imagine how much is left to be discovered, from how make a closure, track environment, do pattern matching, memory representation, etc.

EVERYTHING interesting is something you need to look for.

P.D: This only one of the years:https://gist.githubusercontent.com/mamcx/e1743571b9a1ea163a7...

Reworking my ERP so is becoming more a "system" than an "app" and has composable units to build any kind of business transaction.

Think like https://plaintextaccounting.org but with more metadata so it can model the flow from manufacturing/production to sales.

Is build with Rust and hope to launch this year.

Ok this looks like interesting, and now rebuilding my ERP it sounds the kind stuff I need to look at.

Question: Could this be useful to store history of changes? One pesky trouble is that after you close an invoice all the data there becomes immutable but you need to continue change the base tables.

So, I have a convoluted way of double write rows and keep the "current" as main. All for "just" the case that an invoice need to see the data as was when finalized.

Is this feature for this case too?

I do tenant per PG schema, most are smallish some are bigger (not much, can do all in a single box) but moving forward eventually will need something like this. Also plan to provide "get your own VPS" for more enterprise customers.

This kind of tool will help in this case?

This is a misunderstanding of what serializable in an ACID datastore does, neither that trust developers without FK is always trouble, and that the suggestion of Redis show how much is lost here.

Big point: Serializable not exist alone in a decent ACID datastore, and no, less strict rules for the MOST important thing you have(your data) is NOT a good idea.

Over and over again Acid RDBMS have proven that trying to "relax" the rules in pursuit of performance or worse, mystical holy grails that have never been right or correct for a primary datastore, is a mistake. And then people goes back to them, because is the best tool for ALL the primary data store jobs. ALL OF THEM.

Is like the mythical C developer that "not need safety", that at least has more chance of be possible (after MANY passes over the code) that a datastore without safeguards.

yeah, lets be clear:

Most of the proc macros non-sense is to be able to annotate the enum or struct without wrapping it.

So that is why I use this hack:

https://docs.rs/macro_rules_attribute/0.2.2/macro_rules_attr...

P.D: Is there a true actually reason for proc-macros apart for this weird restriction?? And even if yes, how much nice things will be if this kind of scenario was already present so most not need to reach for proc-macros

How is this done?

How does CQL differ from SQL?

Most attempts to replace/improve SQL derive from the fact SQL was a poorly conceived and designed interface, that originally was meant to be a very small DSL for end users, but unfortunately, was allowed to become a poor, complicated, confusing mess for app developers:

https://cacm.acm.org/research/50-years-of-queries/

    SQL is not an orthogonal language... This is because, in the early days, Ray Boyce and I did not think we were designing a language for programmers. ..
 As it turned out, Ray and I were wrong about the predominant usage of SQL...

---

So the #1 thing any actual replacement or alternative to SQL is how actually become a good language for development, so it is actually composable, can be actually be used to reason about it, has minimal foot guns, etc.

There is a lot of misunderstanding and pushback, similar to how people in the past fight improvements over JS/C/C++ until typescript, rust comes.

But, oh boy, SQL need their typescript!

It works both ways, looking for jobs is full of IA spam too.

I think the best is loot at the companion https://news.ycombinator.com/item?id=48357724

Senior Rust / Database Engineer

Also open to do custom software development!

Location: Medellín, Colombia Remote: Yes! Willing to relocate: No

Technologies:

* System engineer: Rust · query engines · programming languages · VMs · transactions · storage · performance optimization · data modeling · ERPs · Business Apps

* Databases: RDBMs · PostgreSQL · SQL Server · SQLite · SpacetimeDB

* Backend: Business logic · APIs creation · integration · orchestration · ETLs

* Additional: Python, F#, Swift, Web assembly, Git, Jujutsu, macOS, Linux (NixOS, Debian), Windows

* ERP/eCommerce building from scratch

Résumé/CV: https://www.linkedin.com/in/mario-alejandro-montoya-cortés-6...

Email: mamcx@elmalabarista.com

https://www.elmalabarista.com

Software engineer with 30+ years building production-ready business applications and 3+ years as a core database engineer building high-performance RDBMs.

Founder and principal engineer of small ISV with a long track record of owning complex systems end-to-end, from low-level design to production reliability.

Driven to learn new domains quickly and choose the simplest effective architecture, tools and paradigms for each problem.