I must have missed something. How is Red Planet Labs related to Electric?

no business relationship; the technology allows making reactive backends which Electric can natively consume

I summarized here : https://www.reddit.com/r/Clojure/comments/15rzyqq/how_we_reduced_the_cost_of_building_twitter_at/

Not a word of Clojure but when I read the blog post Clojure philosophy is here.

This true incremental reactivity won’t need to be sent to the frontend by Rama. Obviously, Hyperfiddle can subscribe to it and color whatever reactions for the server or the client.

> Will there be a first-party Clojure wrapper? Or, would the expectation be that users would use Java interop? > answer: We’re not releasing one as we don’t have the bandwidth right now to maintain and document another API. That said, making a Clojure wrapper around the Java API should be pretty easy.

^ from Nathan in the HN post

yeah i mean look closely at the java “not a DSL” DSL, it is … unclear if java programmers will accept that as java

i wonder what their clojure macro DSL is/was

I have never needed “twitter scale” in anything I’ve done, so it is not clear how this would 100x my productivity in a typical app… but the proof is in the pudding, will definitely need to play around with this

I probably haven't written anything twitter scale but pretty high scale So many things can go awry, the breakdown to micro services which should help you be reactive and encapsulate difficulties multiplies the surface area of the problem Databases, monitoring, health, logging, queueing systems, man, gimme Rama now if I can cut all that crap out

Their Java API is a thin wrapper over their actual Clojure API, which they’re https://groups.google.com/g/rama-user/c/aNZds6mbnwE. I suppose they don’t want anyone in the community to be able to claim that Rama is better for clojure users, because it would hurt their true adoption target: the world of enterprise Java apps. Knowing that, It’d feel wrong to me to produce a Clojure wrapper over the Java API, which is itself a wrapper over the internal Clojure API. But still, if it could mean I can develop Rama with my REPL and plain clojure functions, yeah, I suppose I’d still compromise. 🙂

Also, it seemed from the HN thread that the Clojure DSL was used internally for implementation. Not clear if that is the same as the userland API. The Java DSL as it currently stands looks like a big adoption hurdle to me

Talking to @U2J4FRT2T he said that the DSL resembles Specter, and it can related to what @U09K620SG said some time ago: https://old.reddit.com/r/Clojure/comments/izh9o4/specter_vs_meander_vs_handcrafted_code_when/g6jrq48/

To make this more approachable to Java devs, maybe wrapping it into a Java Stream compliant API would help.

Thanks for linking that I would love to see higher level database-like abstractions built on top of Rama (however the closed source nature means that this will not happen)

imagining a streaming Datomic-like database with datalog, transactions etc that lets you drop down to the "Rama layer" to code queries directly against custom indexes

That's really the main barrier to Rama adoption that I see – if it is really a tool for database engineers to develop scalable custom indexes, that is a fairly narrow use case

Yep, it would be awesome

Does it handle data loops? If so, you can compile datalog to it Another thing I didn't see yet is how data stores get the data in them. If you can feed ETLs back to those you have a stream processing platform not just a db

you mean "depot appends" ? I think it's like depotReference.append(record)

Nathan didn’t confirm what I wrote in all the details, but graciously provided some interesting bits: > I suppose I shouldn’t be surprised that Rama would resonate more immediately with Clojure programmers, given the emphasis on data structures and its origins in functional programming. So exposing the Clojure API may come sooner rather than later – no promises though. I’m curious how everyone’s experience is next week using Rama through Java interop. > > We did feel the pain of not having a proper REPL while developing Mastodon in straight Java, which brought me back to my pre-Clojure days. It’s annoying to have to reload everything from scratch when wanting to test a small change. We did a little bit of work to try to be able to reload Java classes dynamically, but we never could get it working robustly especially when there were changes across multiple files. You won’t have any of these issues developing modules from Clojure with Java interop. https://groups.google.com/g/rama-user/c/aNZds6mbnwE/m/bCpUdFhVBAAJ

Spoke with Natahan today, our company is going to be experimenting with the beta. I asked for feedback on what’s ok to share, but in response to @UK0810AQ2’s question above, using datalog with rama isn’t required or desired, the idea is that targeted data structures with associated indexing is better than an arbitrary query language – It’s not normalized by design

ask for opening the clojure API 😉

It’s coming, we reviewed it and its real. It’s pretty heavy on the DSL though, think similar to core.async. It will take some time to adapt the mental model