I don't think that "Stockholm Syndrome" is a good label for what you describe. Computing hasn't become the victim of some evil outside force. It has become the victim of its success, like so much other technology. It evolves through incremental improvement, not through revolution, because incremental improvement yields immediate pay-off whereas revolutionary innovation would most probably just fail for lack of adoption.

C++ which has co-routines, although 30 years late and thread-safe queues should be sufficient for Message Passing right ?

There likely is a difference in how I think of computation. I think in a very hardware-centric way.

Incremental improvement is good, but has its down-sides, too, like the Mars Pathfinder fiasco, callback hell, Ptolemaic Cosmology, etc.

Previously, you said something that resonates with me. We have what we have. Period. Can we use it in some different manner? I think so. I think that the ingredients are all available: queues, closures, tagged messages, main-loop meme extended to be recursively defined (like, say, Lisp lists, or bash scripts that call other bash scripts), UNIX process and pipeline memes (actually, the pipeline meme runs so much faster in 2025 that shelling-out becomes a practical strategy for program development, in my mind (we /can/ use multiple languages if we want it (John Lennon))), etc. We don't need wild new hardware and we don't need to dump the code that we have. I think that it boils down to only a psychological issue, not a technical issue(s).

Konrad Hinsen

In my mind, the model of Message Passing is two completely separate computers. Say, Arduino A running one thread and another thread on ESP32 B. Two thin uni-directional wires between them. No memory sharing. We needed to worry about thread safety and the politically correct verbiage for time-sharing (later rebranded as "multi-processing") back in 1960/1970/etc. We don't need to think that way any more. Thread safety, red/green threads, co-routines, 55,000,000 LOC operating systems are just inefficient ways to use computers. Apple made zillions of $'s by stuffing CPUs into printers (postscript printers) back in the day. An acquaintance told me about his horse-racing technology - he hung 30-ish computers off of each horse (in the stable), each one running micro-python essentially executing one main thread. Then, he asked me how to make it "better". I took his question to mean how could he complicate the design and told him not to change anything. The missing piece of technology didn't obviously exist at the time (a way to coordinate the computers in layered form instead of in an infinite canvas form (hence my train of thoughts on 0D/PBP)) xyzzy

I can see how your architecture would work for some kinds of computations, roughly summarized by "data flow". But there are other kinds, roughly summarized as "updating state", where I don't see how it could be done if the state cannot be distributed efficiently.

You're working on Wikifunctions‽ That's so cool! I've been following y'all's work for a while.

Thanks! Yes, if you have any questions, or want to discuss the foundations, happy to do so!

A) From the readme I don't understand the problem you're trying to solve.

B) If this is a cloud project, why the html/react syntax? It's not supposed to run in the browser right? I don't need an answer here, but it's a bit weird so I'd expect a rationale in the project description.

Hi Jouke, thanks so much for the feedback! The problem I'm trying to solve is pretty much the problem Vercel tries to solve, increase devEX, alonside making more dynamic architecture, did you the example application on the readme? imagine infra that could adjust, or better yet, imagine having reactive workflows

think of it as "n8n" on steroids

with JSX syntax

the html/react syntax its a tool so that we can map dependencies, xml syntax allow for that

doesn't k8s do most of this already?

and my point is mostly that you're not supposed to try and convince people here, but in the docs 😉

got it

it's hard because I'm having a hard time defining it, its kinda of a paradigm shift in my vision

and people are busy, so before I try the example, I want to see a compelling problem it solves that I can relate to.

let me think, since you are here talking to me, which field do you work?

maybe I can give a practical example to see if it makes sense to you

cto typically

in web tech companies

do you know spot instances?

1

cheaper vm's based on demand

are you familiar with this concept?

1 = yes, 0 = no 😉

1

so, for instance, in this example, imagine that you have a microservice that always need to run, but it sudden peaks of demand what of the blue and most of the time its very little access

what if the infra itself could read the access patterns and adjust itself so the cost is lower?

thats the kinda of problem that my framework allows solving in a easy XML-friendly way with reusable components and a ecossystem that could grow to resemble what today we have on the react side

does that make sense?

how it works yes, why I would pick this over a k8s cluster that uses node pools with spot instances does not (yet)

kubernetes is the default at many organizations now, so if you think you have something that goes beyond what k8s can do, I'd at least explain in the docs how this is better 🙂

the main difference that K8s scaling in policy based, CReact scaling (or any other reactive behaviors) are state based

so that allows for more flexibility mean while keeping a familiar syntax

imagine the verticals owning everything?

that's possible withing the framework mindset

or even today where AI is on the forefront, this allows for a easier why to deploy an app (or even a "company") end to end, using only declarative modular syntax, very similar to react components

is it making sense so far?

the problem is that this kind of framework is kinda of a brand new category in my view, and I'm having hard problems getting the concept across, what exactly is and what it does

i can understand that

but in production systems, we care about simplicity and stability

so this is scary 😂

why do you think creact implies instability? what gives you that feel?

i don't understand where the scheduler runs, why it uses front-end syntax, what's happening under the hood, etc.

and everything new is scary

i will try to explain it working systems now

in simple concepts

pardon my english

in the FoC community it's great, experiments and stretching the limits of what's possible are the name of the game

imagine a company as a graph of nodes, these nodes are basically workflows (they execute a process and produce an output)

I call this graph of nodes the CloudDOM

doing a analogy with the HTML DOM model

but instead of HTML elements we have these units of action lets say

imagine that then the next state of the graph is determined by the outputs of the previous

thats an fair assumption to make

what I do is generate this CloudDOM model from the nested XML syntax, inferring its nodes from its structure

the "reactivity" comes when a node produces an output and that output doesn't change

so we have a 2 way binding that allows for the component to know the output have changed and react accordingly, and similar the workflow the produces the output has a way to trigger the reaction

is this making sense?

yes I am familiar with reactivity

there are a few key differences between the way reactivity works in React framework, compared to how it does on mine

I'm using Vue, which is also a bit different

its very different from UI Reactivity, in UI you expect thousands of cycles in a brief time, reactivity in a CReact app is very contained

not contained but lets say split, because in UI Programming you dont code the browser, so you dont have control on what makes it render

on CReact you code both ends

have you ever built a kubernetes operator?

what defines it?

it's a form of reactivity in custom resources in your kubernetes cluster. Desired state is expressed on high level descriptions (typically custom objects / CRDs), and the operator's job is to make that a reality by inspecting and manipulating the lower level resources.

thats exactly the kind of things CReact enables, but with the simplicity of React syntax and ecossystem support

also it enables for recursive deployment, CReact in theory deploy itself

which makes infra today a mere glance of what it could even be

Have to 💤 soon, but if you are going into infra/cloud territary, you have to show in the readme how you differ from k8s and how this is better than k8s operators. Saying "operators that work with familiar React syntax" might be an interesting pitch.

thats very helpful, do you have any reference for such operators?

just ask chatgpt, it can explain better than i can

thank you for the suggestion! I will def look into this

this is great feedback

i built one myself based on kopf and am using cnpg and a couple of others in production

I encourage you to play around with CReact just for fun if you have the chance, its fully functional (even lots of bugs I'm sure but the POC is totally functional)

with friendly cli

I'm afraid I have 0 time, was typing this while waiting for some CI runs and cloud deployments 🙈 anyway, it's interesting, good luck 🙂

I totally understand, thank you so much for the attention

if you ever get the chance, let me know how it it turns out