lava

Very interesting. From a quick read, I feel like the domain/converter pattern has elements in common with flow based programming, is this close? I've came another repo that reminded me of some of the goals of your projects, If I get it right. Lava [1], according to the author, it is an architecture to solve "classic software problems" that includes visualization tools. 1: https://github.com/LiveAsynchronousVisualizedArchitecture/la...

He didn't mention a few other big ones with good demo versions: Nuke, Touch Designer and Digital Fusion (much more awkward, but free). Figuring out why programs like these work well and what gaps are between them and general programs is interesting because many of the reasons come down to pragmatic workflow and not technical limitations. They all operate on a very limited set of data types (just images, images + geometry, etc.) and don't have to deal with state, branching, or loops. Results can be viewed easily at each stage and each operation can be isolated and iterated with real time interactivity. This project tries to use message passing nodes as a backbone and data flow as the heavy lifting to get to visual C++ programs: https://github.com/LiveAsynchronousVisualizedArchitecture/la...

I agree but this whole thing just says 'debugging sucks, my commercial tool is great, I won't explain a single detail about it, follow this link' (it is a wrapper around rr). He's preaching to the choir and I still think this post is sleazy. Also replay debugging doesn't have to be complicated. This enables replaying sections of a program with hot reloading by requiring that the data structures are serialized. It also catches low level exceptions so that replay and hot reloading won't crash the running program. https://github.com/LiveAsynchronousVisualizedArchitecture/la...

I've tried working like that and it makes a massive difference. To be able to visualize all the intermediate stages is valuable because they are basically never right until you are able to isolate and refine them individually. https://github.com/LiveAsynchronousVisualizedArchitecture/la...

I would say that searching for the answers to these problems in a new language is going to result in heartbreak. It is likely to not happen and if it does that language will be barren territory where you have what you want architecturally but nothing else. I think the goals are great but addressing them at the architecture level is better, especially with tools to really take advantage of that modularity. Something like this: https://github.com/LiveAsynchronousVisualizedArchitecture/la...

I was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program. As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less. You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples. https://github.com/LiveAsynchronousVisualizedArchitecture/la... https://github.com/LiveAsynchronousVisualizedArchitecture/la...

Here is that exact workflow in modern C++ https://github.com/LiveAsynchronousVisualizedArchitecture/la... All the IO between nodes is serialized, so an output that is already in shared memory (to be examined or visualized in other programs) can also be written to disk. It can then be loaded as a 'constant' node and iterations can be done with hot reloading on the baked output. They key is that you need both live/hot/automatic reloading of execution AND snapshots/replay/rewind/baking. If you only have one or the other, you can't isolate a part of a program and iterate on it nearly as quickly.

You might get something out of looking at lava: https://github.com/LiveAsynchronousVisualizedArchitecture/la... Concurrency really comes from being able to split up data in isolated chunks that have access to all their dependencies. When you think in terms of data and not tasks, things make a lot more sense.

This architecture is made to match software threads to (logical) hardware threads, then have them loop over data separated into chunks that don't depend on each other. If a function is blocking, needs the CPU and isn't thread safe, it can be wrapped in a message passing node that will get skipped over if a thread is already running it. Every separate chunk of data that it creates will be dealt with concurrently and the high level structure can be put together in a graph that uses openGL. https://github.com/LiveAsynchronousVisualizedArchitecture/la...

Programs like Nuke, Houdini and Touch Designer have been doing this for years specific to graphics - this is trying to be more generalized: https://github.com/LiveAsynchronousVisualizedArchitecture/la...

What you are describing sounds very close to this https://github.com/LiveAsynchronousVisualizedArchitecture/la...