Prelude
I've always cringed at the people that said "I'm making a programming language". I guess it's more of the arrogance behind statements like "... That'll be better than C!"
While I don't think I'll make anything better than C, I am making a programming language.
It's not going to be polished. It's not going to solve problems that I don't find interesting. But it might solve something for me and maybe others will think it's as neat as I do.
I've worked on a lot of different software projects from front-end web applications, to native mobile applications, and backend microservices. Back-end development specifically was something I liked quite a bit; but, there were a lot of problems that irked me every time I encountered them. While most of them can be chalked up to skill issues, I feel like there's something there that is asking to be solved.
I feel like microservices often are either too bloated or too small. Deploying a microservice is often more time intensive than writing a change to begin with. In larger scale applications, you get scope creep across microservices or they aren't architected for the eventual behavior but for the optimistic. Not to mention container orchestration and the headaches that come with everything you need to learn to even run your service (and the countless dependencies it has) to test a change(s) locally.
Then there's the data logistics problem. I like being able to see where data starts and where it ends. How it flows and transforms through an application. Microservices introduce a lot of barriers. A lot of contracts that have to be fulfilled. Tracing a piece of data for its entire life cycle becomes extremely difficult. This is exacerbated by things like message streaming platforms. As a developer, you lose insight into the flow of the data once it leaves your hands and enters into some nebulous message broker. Especially when it's just going to one of your other microservices.
Mycelium
Mycelium is a biologically inspired Virtual Machine Network (VMN) that runs a purely functional language called Spore. Or, at least, that's the plan.
Each Spore function will be deployed as a stand-alone unit in the VM and distributed through the network. You can think of them as nano-services. Since each function is pure, we'll get a lot of benefits that other functional languages provide (memoization, async safety, modularity, scalability, etc.).
Functions will be semantically hashed so that only true function changes will result in a redeployment (reordering of statements, comments, etc. will not result in a new deployment).
The network will automatically distribute functions (hopefully optimally!) based on usage and available resources. The idea being that "microservices" will automatically form and reform optimally based on the actual usage pattern of your application -- not just the optimistic usage pattern your team thought up before requirements were changed or added. Code that fires together wires together!
The VM network itself will connect and reorganize according to the usage and available resources as well. Ideally restructuring itself from cases like individual node failures to catastrophic failure like a data center outage. This is inspired by how mycelium networks organize themselves in nature (thus the name!).
At the time of writing, Spore is nothing more than a hastily (and only partially -- but functional!) built bytecode interpreter. Mycelium only composed of experiments to try out the different ideas that will make it possible.
But, I've had these ideas floating around in my head in one variant or another for quite a few years now. Figured it was time to start putting them out into the world.
I plan on building out the language and VMN during my spare time and documenting ideas and processes along the way in this blog. I think some of the solutions I have to some of the problems in the Prelude are pretty interesting!
If you're interested in seeing the progress or suggesting contributions, you can check it out on my GitHub!
Top comments (0)