I bet if Datomic were open source it would get adopted at an incredible pace and become one of the go-to tools for working with data.
Right now, I'm sifting through the internet to find any other (up to date) similar system supporting datalog querying.
Let me know if you know about one!
(Only one I found so far being Cascalog [1], which is unfortunately only supporting old sluggish hadoop)
Will think hard about the suggestion of using some functional language instead also ... you for sure got me thinking! :)
Feel free to share any pointers regarding this!
In the meanwhile, sharing my thoughts so far: What I have so far thought was pretty "unique" about datalog is that it support "named queries", which can be used as a kind of "duck typing" classification, to build up a model of your domain of interest that is always computed on-demand, leaving the raw data unchanged in it's default ("normal"?) form.
Because of the "named queries", you can combine lower-level queries in higher-level ones, to create a hierarchy of "dynamically generated concepts", which I haven't seen any other technology be able to do.
(While named queries are conceptually similar to views in SQL, they are so much more natural to work with.)
I know this by experience from my dabblings in prolog [1], but haven't found any large-scale prolog data system supporting distributed computing (I understood it has some features making it unpractical for distributed computing and more, in a way that datalog doesn't).
[1] http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A3988... (PDF: http://www.diva-portal.org/smash/get/diva2:398839/FULLTEXT01... )
Read this section from the Elixir docs: http://elixir-lang.org/getting-started/pattern-matching.html
Also this page from the Haskell tutorial: https://www.haskell.org/tutorial/patterns.html
Fun fact: early versions of Erlang (which Elixir is built upon) were implemented in Prolog, and IIRC what would become Erlang later was originally intended to be an extension of Prolog. There are no new ideas.
This is the purpose of functions in most programming languages. A function is kind of like an HTML template, but for code. So rather than have `<h1 title="{{bar}}">{{foo}}</h1>` you have `function(foo, bar) { return h1({title: bar, text: foo}); }`. DOM tree, AST ("abstract syntax tree"), relational data, same thing: a graph, and most programming languages can represent raw graph nodes/edges easily as lists of strings. You can write a simple tuple-matching engine in Javascript: https://gist.github.com/notduncansmith/7858d27a2b875ff10b84
Obviously that's not a production-ready piece of software, but it highlights an important lack of distinction between "database" and "program" that wasn't readily apparent to me as a developer for a while.
HTML, source code, and user input are all the same thing (just data, really). One program's source code is another's input data, all the way down.
If you want to get existential, you can extend this even down to matter itself as simply a representation of information: imagine a physical machine in a factory that winds jack-in-the-box toys on their way out the door. Same thing as a higher-order function.
function wind(toy) {
return toy.lever.rotateByDegrees(360);
}
Moving from the abstract to your concrete case:
> build up a model of your domain of interest that is always computed on-demand, leaving the raw data unchanged in it's default ("normal"?) form. [...] (While named queries are conceptually similar to views in SQL, they are so much more natural to work with.)
SQL views don't compose at the same level that Datalog expressions do, but that's because they aren't typically expressed as raw graph data (i.e. lists of strings where each list item is a node in the graph). If you could just name arbitrary chunks of SQL AST and mash them together, it would be just as composable (though perhaps more cumbersome due to boilerplate).
One final thing before this already-too-long comment comes to a close: you might give CouchDB a look. It's a document datastore that offers map/reduce views written in Javascript (use as much or as little composition/abstraction as you want). The distributed features are pretty cool (bidirectional sync, versioned documents) and writing apps with it is awesome, especially if you can leverage supporting projects like PouchDB or Couchbase Lite. Not sure if it fits your use-case but it sounds like you might find it personally interesting.
Hopefully this has been helpful!
Posted a separate HN link: https://news.ycombinator.com/item?id=13064674
This is just not something we've got a good, reliable answer for. E.g. I'm pretty confident that his creating and being the BDFL of Clojure wasn't sufficiently remunerative.
That said I also think it is worth to regularly revisit what an open sourced Datomic could do for adoption of Datomic itself as well as for Clojure (edit: not to mention what the impact would be like for the world at large). I'm optimistic that there are monetization opportunities through SaaS, consulting and other licensing concepts.
Ideas?
If Datomic achieves widespread success with both community and enterprise editions, Rich Hickey would have an impressive range of opportunities.
The man, however, is far more accomplished than I so I can only assume he's thought of that and firmly rejected it. Perhaps, although he wants to see his kids go through college, he also wants to be a big part of their lives. Perhaps 2 massive, popular over source projects would get in the way of that.
I think it would. What it wouldn't do is give Rich Hickey the control he currently has over his life and his projects. He'd likely end up getting paid to work on Datomic by some big company instead of running his own as he does right now.
Unity - free community version, pay monthly for extra features and to remove the splash screen, option to stop paying and keep license but stop receiving updates
UE4 - free, source code is on github (but not FOSS), takes 5% of your gross revenue after first $3000
Lumberyard - free, source code available (but not FOSS), you must either run your own private servers or use AWS
Early adopters will take most of the financial burden in order to recover the development costs, and open sourcing will happen once it's more strategic to use Datomic as a way to promote their knowledge and services broadly than it is for them to make money directly from the product.
Support tiers will remain even after open sourcing, of course. I don't expect it to turn into abandonware.
But as a developer I think the current license is a bit of a shame. I've played with Datomic, think it is fantastic, and would love to use it.
However:
- After the closure of products such as FoundationDB and Parse, I will never have a significant dependancy on a closed source product again. (maybe if the company was a behemoth like Microsoft or Oracle, but these days probably not even then.) [1]
- As a little guy, the $5000 I would need to pay after one year to keep getting updates to the product is just too much. One could argue that Datomic are looking for bigger fish, but something to consider is how important it is to get people using your technology (al la Microsoft 'developers developers developers!') Little guys can go on to be bigger guys making the important technical decisions. There is post above looking at the licensing done by game engines such as Unity, where larger companies pay more and the little guys are given a break until they are making a profit. Hopefully we will see more of this in the future.
[1] https://www.wired.com/2015/03/apple-pulls-plug-tech-company-...
I'll just keep using the free edition for my toy/side projects.
Datomic free edition also sounds great for small open source projects.
It wouldn't be suitable for large scale free SaaS websites but I feel that's a tiny slice of developers.