Hi Wade, There are no roadblocks that I know of for using ClojureScript and Om along with Pheonix/Elixir.
I haven't tried using Datomic from an Elixir (or Erlang) project though. There is a library called datomex <https://github.com/edubkendo/datomex> (which you probably already know), although I don't have any expierience using it. It uses Datomic's HTTP REST API, I'm not sure if that presents any limitations. Cheers, Juan On Tue, Dec 15, 2015 at 1:14 AM, Wade Moschetti <wade...@gmail.com> wrote: > How has this progressed. Really interested in using Phoenix/Elixir, > Datomic and Om together. > > On Friday, September 18, 2015 at 2:06:04 AM UTC+10, Fergal Byrne wrote: >> >> Hi Juan/Frank, >> >> Elixir has taken the key features of Clojure (especially macros, >> protocols) and used them to build a wonderful language on the BEAM. I'd >> take a look at Elixir if I were you - it's just too much for too little to >> try shoehorning Clojure notions into a BEAM-hosted system. >> >> That being said, Francesco, CEO of Erlang Solutions was here in Dublin >> last week, and after our chats he'll hopefully soon be in touch with people >> at Cognitect about interfacing between Erlang/Elixir and Clojure/Datomic. I >> see a big opportunity for a ClojureScript/Om front end, a >> Phoenix/Elixir/Erlang server, and a Datomic persistence layer. >> >> Regards, >> >> Fergal >> >> >> >> -- >> >> Fergal Byrne, Brenter IT >> >> Author, Real Machine Intelligence with Clortex and NuPIC >> https://leanpub.com/realsmartmachines >> >> Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: >> http://euroclojure.com/2014/ >> and at LambdaJam Chicago, July 2014: http://www.lambdajam.com >> >> http://inbits.com - Better Living through Thoughtful Technology >> http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne >> >> e:fergalb...@gmail.com t:+353 83 4214179 >> Join the quest for Machine Intelligence at http://numenta.org >> Formerly of Adnet edi...@adnet.ie http://www.adnet.ie >> >> >> On Wed, Sep 16, 2015 at 3:34 PM, juan.facorro <juan.f...@gmail.com> >> wrote: >> >>> Hi Frank, >>> >>> I'm wondering why no one ever posted a question/comment/reponse to this >>> thread. Personally I think Clojure is a great language and the Erlang VM is >>> a feat of engineering. I would love to think what other think about this >>> thoughts and about the possibility of having Clojure on the Erlang VM in >>> general. >>> >>> There are some language features that don't quite map from Clojure to >>> Erlang though, which are a challenge to implement. For example it is my >>> understanding that all of Clojure abstractions rely either on Java >>> interfaces (on the JVM) or on protocols (ClojureScript). So I guess a good >>> implementation for the protocol mechanism would be needed for Clojure's >>> implementation on the Erlang VM. >>> >>> In my head this means: >>> >>> 1. Values would need to have a type tag, in order to be able to >>> figure out if they do or do not implement a certain protocol. >>> 2. A possible implementation would be a tuple whose first element is >>> an atom which represents the type (i.e. {type_whatever, ...}) >>> 3. All functions that support this scheme and also the ones that >>> participate in the protocol mechanism need to "wrap/unwrap" values for >>> "type checking". >>> 4. Previous points make interop with Erlang more complicated, since >>> Erlang code would need to account for this wrapping & unwrapping. >>> Although >>> there could be a macro that figures some of these things automatically, >>> but >>> it would still not be a seamless Erlang/Clojure interop. >>> >>> There is also the matter of *namespaces* and *vars*, Clojure's bread >>> and butter :P. >>> >>> In ClojureScript *namespaces* are not a thing you can manipulate [1] >>> (you can't use **ns** for example), which could be a possible >>> workaround to avoid maintaining runtime information about namespaces. >>> >>> *Vars* on the other hand are not reified in ClojureScript [2] (they map >>> to regular JavaScript variables). Vars either have a *root value*, are >>> *unbound >>> *or (when they are dynamic) might have a *thread bound value*. The >>> first two are global state related to a var while the last one is local to >>> each process (when talking about the Erlang VM). There are ways of >>> implementing this in the Erlang VM, just to name one (which is probably not >>> be the best one) using an ETS for global vars state and the process >>> dictionary for the processes bindings (maybe implementing something >>> analogous to Clojure's frames approach). >>> >>> Anyways... >>> >>> These are just a couple of challenges in a possible implementation on >>> the Erlang VM, which I think are key. >>> >>> Cheers! >>> >>> [1] At least not the last time I checked, although ClojureScript is on >>> its way to being self-hosted so, who knows? >>> [2] The *var* special symbol provides compile time information though >>> in ClojureScript. >>> >>> On Friday, July 13, 2012 at 2:15:18 PM UTC-3, FrankS wrote: >>>> >>>> Just became aware of this effort: "http://erlangonxen.org/"; >>>> >>>> which shows off some impressive properties: >>>> >>>> * Startup time of a new instance is 100ms >>>> * Instances are provisioned after the request arrival - all requests >>>> get handled >>>> * No instances are running waiting for requests - the cloud footprint >>>> is zero >>>> * the size of infrastructure is proportional to the maximum load - 8 >>>> servers may be enough >>>> * … >>>> >>>> All that begs the Q: would Clojure on an Elang-VM be feasible and make >>>> sense? >>>> >>>> -FrankS. >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/A6LPAYjmjbY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Juan Facorro -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
