@OvermindDL1 Not grokking the purpose and how/why ibGib will be used is perfectly “non-odd” hah. Rather, that certainly is reasonable to say, and it speaks to the abstractness of the concept.
In short, its purpose is unification, something of a rethink on existing patterns/tools on a very broad scale. But since that won’t help much, we can think of the near term. The most immediate use case is “replacing” the back-end, much like Event Sourcing + DDD is challenging Relational Databases more recently because of the cheapness of data => explosion of “Big Data” and data mining. But there are various key fundamental differences, the primary one probably being that ibGib’s domain language is an abstract meta-language addressing combining/mutating/splitting nodes. Also, it does not have “past events” like Event Sourcing, rather it has something more akin to “expressing DNA”, a mechanism of which replaying past events (called “hydrating” in ES) is only one special case.
So in short, for starters, think of a back-end “evolution” of Event Sourcing (though I was working on this before ever hearing the term 15 years ago).
If you want a more concrete history, I can point you to my previous Xamarin.Android implementations of three Android apps:
- languageGib for learning multiple foreign languages by studying songs (and any other ordered texts)
- coffeeGib for coffee geeks and snobs to track coffee history: coffees, coffee gadgets like aeropress/chemexes/etc., and individual roasts.
- ibGib/mobileGib, which contained both languageGib and coffeeGib.
So you can think of these as the “problems”. But you could say that it was the separate domain languages that was the “primary” problem. I wanted a simpler back-end creation mechanism so I would haven’t to keep implementing data source stuff that I didn’t care about. I wanted business object creation/validation to be able to be shared across all of my implementation “domain languages” (e.g. languageGib had Song, Author, Language, etc; coffeeGib had Coffee, Roast, Composition).
So, in order to write these various data models (in Elixir, these would be structs I imagine), I had to write the models themselves, migrate the database, add validations, try to share validation logic (I had written my own plumbing architecture all the way), implement CRUD, and then test all of these things, then test them across the wire to a cloud database that I had to take care of, blah blah blah, etc. etc. I just need one back end for my particular use cases, and I abstracted it into a nodal form that actually keeps the history of this process. It “worked” in my POC javascript implementation, but the expression part is just plain clunky in javascript. I got tired of trying to compose complex parallel execution at a high level, hence erlang and then elixir.
It’s such a broad problem though, the “simplest case” use case is a “note” taking app. This is “simply” creating a “text” thing and then a text implementation. The “Hello World” is actually almost the entire thing! But even just Hello World is difficult because of the abstraction. But the abstraction buys us the ability to use each individual “datum” instance of a “text” as a template for others. So if user A creates some template, then user B should be able to “fork” that template and tweak it. The browsing process is shared, so you can look online for others’ “templates”, which can actually be just their data, i.e. they don’t have to do anything special to mark it as a “template”. (Edit: Think of this like navigating to someone’s github repo, then saying “Hey, I like they’re data model X” and then being able to fork just that data model and not the entire repo).
This then goes beyond “notes”, which would be text “instances”.
So with coffeeGib, I had a Coffee model. I chose the properties and architecture that I wanted, me as the programmer. I chose Name, Roast Date, etc. Well this kind of templating could be created one time online. So imagine some other company/user likes my coffee template but doesn’t want the roast date or the brand name or whatever. They would fork it, split off what they don’t want, and then they could create instance data of that template.
I could go on and on all day of what it could do…for example, because of this architecture, you would know when refactoring exactly which data would be affected by the “refactor”. When you make a “change” on a data object on the server, your UI could know exactly which properties need to be updated. It’s specifically designed for micro-service structure, i.e. “Big Data”…On and on…anyway, I’ve written too much!
Thanks for your interest, and let me know if there is anything else. You can also check out the wiki for more abstract stuff. Also, I am unsure if talking about this more is the goal of this forum, and if you want to continue this you could also create a GitHub issue and I could go on and on there. Maybe one of the admins could help me out on that point?
I chose Elixir because I think it is better suited than Go for many reasons, as I’ve expounded elsewhere on this forum. I hope that it comes to fruition and I’m right! 
Fork ibGib
Authenticate with multiple email addresses
Add notes/comments
Upload pictures (must be authenticated with an email address)
refresh button to go to the latest version, etc. Think of it as a visual entity git-timeline explorer 
next is a move towards more JSON api stuff and an 
on the back end with parallel processing and scaling, that voice-controlled devices like the Echo 
- in addition to Nerves/Embedded devices in general - is 
.
