On Wed, May 25, 2016 at 5:43 PM, Antti Kantee <[email protected]> wrote: > >> 2. The framework to build and package Erlang application on RumpRun is >> ugly >> (not surprisingly the intent was to get it to work in the first place) and >> needs a lot of improvement. > > > How does this "ugly" manifest itself? Does it matter? >
I guess considering the projects within rumprun-packages are primarily for demo, so it does not. >> 3. There is a lack of a showcase project which demonstrates the power of >> Erlang on RumpRun, which motivates wider adoption. > > > the eternal chicken-egg > > Paradoxically, it's very difficult to get people to use something out of > their free will. If you make them to pay you to use it, it's a different > story. So, in effect, a quick way to get to the point of wider adoption is > to attract a sales team. Unfortunately, I don't remember seeing a lot of > open source sales teams ... > :) >> 4. Although related to point-2 I would like to indicate separately that >> Erlang build is way beyond something which can be termed as a bloat. This >> again is a consequence of neglecting it in the interest of a working >> prototype (achieved earlier). The final output should be inline with the >> principle of unikernels; which is to be a working-bare-minimum >> distribution >> ultra-small. There are some ways of achieving that, but may require a lot >> of time to gain desired design, flexibility or performance. > > > As long as it's not worse than standard Erlang, why is it a priority? > It just doesnt look right thought it'll take some time sorting it out. I guess I am fine with the intent of the repo limited to demonstration rather than anything else right now. >> The intention of this email is not to propose a solution rather than >> initiate a discussion, but I couldn't resist presenting my views of trying >> to tackle point (2). I worked with numerous build systems and believe that >> something similar to the openembedded + yoctoproject (due to my love for >> python) can help in this respect, whose design require a steep learning >> curve but makes sense after a while and gives a lot of flexibility and >> reuse in the end. Having said that the idea is to make it easy for >> packaging applications on top of RumpRun which is much nicer than what >> exists today. > > > Well, rumprun-packages isn't much of a framework, so much as a collection of > demos. Leadership in developing it to an orchestrating system for building > images and(or?) deploying/managing the fleet of instances is up for grabs. > But, I think everyone already understands that we're not there yet, and > words without concrete actions won't change things. > I did spend some time on this but then I am still evaluating how bulk of the functionality can be inherited from someplace else rather than to write one from scratch :) -Neeraj
