Original Post

The easiest way to explain my project codenamed "Cartilage" (under brand name "Material Programs") is to compare it with Hadoop. If you are familiar with "in-memory compute", the leap of imagination required is not that big. Database-oriented programming puts all state being processed in a swampy "lake", and now you have to solve membrane isolation and secure access issues. It's doable, but encapsulation is inherently violated by design. Next leap is reactive programming. In ETL and change data capture (CDC, don't confuse with clock domain crossing), where real time data ingestion using streaming techniques ultimately yields the same system, in its structural sense, mathematecally equivalence class to that of actor model, unified over reactive streams. Actors in the object capability model (OCAPs) maintain membrane security and controlled access to resources, which is extremely difficult to enforce in ad-hoc lambda processors and BI tools like Snowflake etc.

Cartilage is also inherently parallel supercomputing cellular automata made of a sea of FPGAs. Think about it: your data being processed in object-oriented way, everywhere, securely, simultaneously.

Cartilage started in the summer of 2013 as an attempt to solve the von Neumann bottleneck problem.

I spent 10 years on a hardcore computer science research without raising funds. It's wild to see how far it went! It's really like Hadoop, but with code instead of data, and low-level switching on transistors, instead of Java VM and HDFS. But very similar idea of spatial awareness of how many resources are locally available, what's the shape of the server rack we're running on, and what are the bandwidth cables and topology and time delays between compute nodes, and overall shape of bigger clusters. But object-oriented reactive programming model with hardware instantiation of FPGA bitstreamlets.