> I have converted larger Erlang codebases to Elixir incrementally

Jake, can you explain the rationale behind this? Why did you want to run 
your apps in Elixir instead of Erlang?

> The most interesting thing is probably an example combining Zotonic with 
> Phoenix. 

This is something I’ve been thinking about for a while now. Going one step 
further: what about porting Zotonic to Elixir? There are a many reasons why 
Zotonic and Phoenix (= Photonic ;) are a great match:

1. As of yet, there’s no fully-fledged CMS available for Phoenix/Elixir. 
Having *a stable CMS for Phoenix* will enable developers to be more 
productive in Elixir and attract more of them to start doing Elixir in the 
first place. There’s definitely a demand for a Phoenix CMS: as Allen and 
others write in this thread and again others have told me.

2. This is also a great chance for Zotonic. As most web developers on the 
Beam VM are doing Elixir, it will be much easier for them to submit 
improvements to an Elixir CMS than an Erlang one. So by porting Zotonic to 
Elixir we will hopefully find *more contributors*.

3. The number of Zotonic contributors is rather small for such a large 
product. One way to solve this problem is by *reducing the scope of Zotonic*. 
Currently it has custom logic for HTTP (Cowmachine), templates (template 
compiler), routes (dispatch compiler) and so on. All these belong to *web 
applications in general, not a CMS specifically*. Let’s use Phoenix to take 
care of these. Phoenix has a (much) larger community, so it can do these 
fundamentals better and more efficiently than we can. Worst case, we would 
have to build something on top of what Phoenix ships with out of the box, 
such as adding adding dynamic routing 
<https://gist.github.com/chrismccord/1c6b6fb086d5432d4e08>. Let’s stick to 
makes Zotonic unique*: its flexible datamodel, performant depcache, 
(possibly) ErlyDTL template language. 
(As a side-note, let’s not forget Zotonic is much older than Phoenix, and 
Zotonic has been doing things such as real-time client/server communication 
before Phoenix existed, let alone added Channels.)

4. Phoenix is well-designed and properly *decoupled* (Plug for HTTP, Ecto 
for databases and Contexts for domain logic). The same cannot not always be 
said of Zotonic. So switching over to Phoenix will result in smaller 
Zotonic components written in higher-quality code.

5. Most web development on the Beam VM is happening in Elixir: if you need 
authentication, JSON-LD parsing etc., there are much more likely to be 
up-to-date, well-maintained and documented Elixir *packages available* on 
Hex.pm than a single Erlang one. It therefore makes sense to integrate with 
the Elixir ecosystem.



Op dinsdag 3 oktober 2017 04:23:11 UTC+2 schreef Jake Morrison:
> On Mon, Oct 02, 2017 at 10:39:04AM +0000, Marc Worrell wrote: 
> > 
> > > On 2 Oct 2017, at 02:19, Jake Morrison <ja...@cogini.com <javascript:>> 
> wrote: 
> > > 
> > > Marc, 
> > > 
> > > On Fri, Sep 29, 2017 at 09:40:07AM +0000, Marc Worrell wrote: 
> > >> Can mix build rebar3 based apps? 
> > > 
> > > Mix is more or less a replacement for rebar3, so they are mutually 
> > > exclusive, though largely compatible. 
> > > 
> > >> If so then we can just provide a mix based project. 
> > > 
> > > For Elixir users, the easiest thing is if Zotonic can be used 
> > > as a library which can be pulled in by mix/rebar from https://hex.pm/, 
> > > i.e. it's a well behaved OTP application. It might make sense 
> > > to have some mix tasks which e.g. create template modules. 
> > 
> > The master is being split in OTP apps, with the specific goal of 
> > being reusable. 
> > 
> > Actually, there is not much left in the ‘zotonic.app’, almost everything 
> > is moved to the other (OTP) apps. 
> > 
> > So I guess having a Mix (/Elixir) project that people can clone could 
> > be a good starting point for Elixir devs. 
> The most interesting thing is probably an example combining Zotonic with 
> Phoenix. 
> > >> I am also thinking of using the introspection (we are using that for 
> > >> notify observers) to discover if a module, filter, action or other 
> > >> type of Zotonic callback module is an Elixir module. 
> > >> And if so we could generate or use some glue code to call directly 
> > >> into the Elixir modules from Zotonic. 
> > > 
> > > Generally speaking, Elixir code is functionally the same as Erlang 
> > > code, the module atoms just start with 'Elixir.', so that may not be 
> > > necessary. 
> > 
> > So if an Elixir source file defines the Elixir equivalent of a function: 
> > 
> >         observe_some_event/2 
> > 
> > Then in the function definitions I can find just that function? 
> > And the module itself would be loaded as ElixitSomModuleName? 
> > 
> > That would make it quite straightforward to integrate Elixir code 
> > into the notification system. 
> It's basically the same, just the Elixir compiler adds "Elixir" to 
> the front of the module names. So probably nothing needs to be done. 
> In Erlang, if you have a module foo, it would look like: 
> -module(foo). 
> -export([observe_some_event/2]). 
> observe_some_event(One, Two) -> ... 
> And you would call it like foo:observe_some_event(One, Two) 
> In Elixir, it would look like: 
> defmodule Foo do 
>   def observe_some_event(one, two) do 
>   ... 
>   end 
> end 
> From Erlang, the module atom would be 'Elixir.Foo', and you can call it 
> like 'Elixir.Foo':observe_some_event(One, Two) or apply('Elixir.Foo', 
> observe_some_event, [One, Two]) 
> > - M 
> Jake 


You received this message because you are subscribed to the Google Groups 
"Zotonic developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to zotonic-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to