Very interesting. It occurs to me that clojure will be widely adopted without a killer app, but a few near killers (I thought incanter and a web app framework around ring and enlive would be the first).
Rich Hickey's new project: datomic.com
41–50 of 111 posts
Re: Rich Hickey's new project: datomic.com
#42Webdevs will be all over this when the Peer runs on Javascript runtimes. Who's taking bets that it's written in Clojurescript?
I'm pretty sure the whole thing is built on the JVM, but I agree with you that having a peer run inside a js browser app via clojurescript would be a logical next step. (and arguably really useful)
Re: Rich Hickey's new project: datomic.com
#43Re: Rich Hickey's new project: datomic.com
#44Stuart Halloway provides more information in his Datalog querying in Datomic screencast: http://www.youtube.com/watch?feature=player_embedded&v=b...
This is really cool. Highly recommended. You see some querycode in clojure and in java.
Re: Rich Hickey's new project: datomic.com
#45Okay, I don't quite get this. The processing gets moved to the client. But what if the dataset involved is too large for the client to hold?
Re: Rich Hickey's new project: datomic.com
#46From a UX point of view, i didn't realize there was a menu until i scrolled down and your js menu popped in on the top. once that happened I scrolled back up to see where the menu initially was, because why would they do a pop-in menu if there wasnt one initially. ah ha! i see it. my eyes completely looked over it. yes, i realize it's giant but it's also about the same size as an ad banner (which my eyes typically just ignore). also, the colors are quite bland and do not set any type of priority. just some constructive criticism for ya. good luck!
Re: Rich Hickey's new project: datomic.com
#47Why is this interesting? It sounds like yet-another data store.
I disagree its not at all like anything I have seen befor. It has a very powerful querylanguage you can use your hole programming language not just what the designers wanted (like in SQL).
http://www.youtube.com/watch?feature=player_embedded&v=b...
There is other novel stuff.
Re: Rich Hickey's new project: datomic.com
#48Clojure is an amazing language, so i'm willing to go the extra mile to attempt to understand this work. However there's one thing that I can't get over. From my understanding, the big idea is the query engine is brought local, and the storage would eventually come local too. It seems like for smallish db's this is fine. What happens though if you're working with a rather large database? Additionally, If local means t…
The key is that you can replicate peers and partition at the app level so that each peer in your infrastructure has the working set in memory. Compare with sharding as a partitioning mechanism in the database layer. The nice thing is that the data is cached on demand so the working set can change over time.
Terracotta and other data grid architectures do something similar.
Re: Rich Hickey's new project: datomic.com
#49Clojure is an amazing language, so i'm willing to go the extra mile to attempt to understand this work. However there's one thing that I can't get over. From my understanding, the big idea is the query engine is brought local, and the storage would eventually come local too. It seems like for smallish db's this is fine. What happens though if you're working with a rather large database? Additionally, If local means t…
Local data is immutable (read-only). Also, the Peer cache uses a LRU replacement strategy; older data will drop off as new data comes in to keep most-recent local data in memory.
Re: Rich Hickey's new project: datomic.com
#50Earlier quoted context omitted.
> In this case where changes come in at two times (which are subject to all the raciness of the real world that exists regardless), one will win. That describes many methods of optimistic concurrency control, but it doesn't answer my question of how this supposed to work in practice with high write contention, the higher latency of a distributed peer model, the long-running transactions the video mentions (or maybe t…
From the FAQ: Thus, Datomic is well suited for applications that require write consistency and read scalability. Seems like they're not focusing on high-write situations.
Correct, it's not write-scalable in the same way it is read-scalable. The transactor is a bottleneck for writes.
However, that doesn't mean it has slow writes - it should still do writes at least on a par with any traditional transactional database, and probably a good deal faster since it's append-only.