CB vs. Goliath
520 views
Skip to first unread message
wulftone
May 8, 2012, 3:46:03 PM5/8/12
to ChicagoBoss
Hey all,
I'm curious if any of you have any experience with the fairly new
Goliath framework (http://postrank-labs.github.com/goliath/) and how
their process compares to what Erlang and CB can do... or at least
provide some insights into things that CB does better, in your
experiences.
I just implemented a site in Goliath and it was quite enjoyable
(though I know Ruby _much_ better than Erlang). I'm still working on
CB for another thing.. slowly.. : )
Thanks!
I'm curious if any of you have any experience with the fairly new
Goliath framework (http://postrank-labs.github.com/goliath/) and how
their process compares to what Erlang and CB can do... or at least
provide some insights into things that CB does better, in your
experiences.
I just implemented a site in Goliath and it was quite enjoyable
(though I know Ruby _much_ better than Erlang). I'm still working on
CB for another thing.. slowly.. : )
Thanks!
Florent Gallaire
May 8, 2012, 11:53:06 PM5/8/12
to chica...@googlegroups.com
Compare Goliath to RoR (because it's Ruby), or to Tornado (because
it's asynchrone), but not to an Erlang based framework, because Ruby
(or Python) VM can't compete with the Erlang one.
Florent
--
FLOSS Engineer & Lawyer
it's asynchrone), but not to an Erlang based framework, because Ruby
(or Python) VM can't compete with the Erlang one.
Florent
FLOSS Engineer & Lawyer
Tim McNamara
May 9, 2012, 12:59:47 AM5/9/12
to chica...@googlegroups.com
I am very wary of these types of comparisons. However, saying that the
VMs of other dynamic languages "can't compete" is a little
disingenuous. For example, gevent is performs extremely well.
Getting back to the original question, CB has several advantages to
other web frameworks:
- built-in SMTP support
- async tasks / message queue
- fast rendering times, due to compiled templates
I wouldn't worry about the performance of the request/response cycle
too much though. You will not have a site that needs that level of
performance until you're in a position to pay people to worry about
performance problems.
VMs of other dynamic languages "can't compete" is a little
disingenuous. For example, gevent is performs extremely well.
Getting back to the original question, CB has several advantages to
other web frameworks:
- built-in SMTP support
- async tasks / message queue
- fast rendering times, due to compiled templates
I wouldn't worry about the performance of the request/response cycle
too much though. You will not have a site that needs that level of
performance until you're in a position to pay people to worry about
performance problems.
Florent Gallaire
May 9, 2012, 5:35:48 AM5/9/12
to chica...@googlegroups.com
> disingenuous. For example, gevent is performs extremely well.
No, gevent "performs well" on only one core because the Python VM runs
on only one core (how many cores have your computer ?). And nothing
about scaling with distributed computers.
Ben G.
May 9, 2012, 4:01:55 PM5/9/12
to chica...@googlegroups.com
I have worked with tornado and node.js, which have the same operating principle.
Most of the advantages of CB are because of it's erlang foundation, so this comparison kinda ends up as a erlang vs. ruby debate.
To the best of my understanding; tornado,node.js and goliath all run on a single thread. This is not scalability problem however, you just put a load balancer in front of it like nginx. Actually node.js doesn't even need that anymore. These systems scale fine, much more easily than your database will. I guarantee.
The disadvantages of these systems are when one process starts blocking the others. You have to be very careful about writing your code with that in mind. You often may have to suffer through many nested callbacks or other ugly code.
--edit--
I guess goliath has it's own way of dealing with callbacks. But it's still nonblocking server underneath and subject to those quirks.
Erlang doesn't suffer from any of those problems. You can write callback-free free code. The erlang VM uses all available threads much more intelligently. It was design for telecom where latency is important, so it takes care of it's own blocking issues auto-magically. There are some erlang server performance tests that outperform node.js(node outperforms goliath IMHO). All of that usually matters very little, in the real world you'll just add another server. Hardware is cheaper than developer time. But if speed does matter to you, do some tests for your scenario and don't take anybody's word about it(even though I already know CB will smoke the competition;p )Again, If all you care about is raw number crunching speed, then maybe you should be looking at haskell+yesod?
I think the most important feature Erlang has is linked processes. You really can write code that will never ever have downtime. Write once and forget for 20 years. That's not something ruby(or any other language I know of) has an equivalent to. There's hook.io, but that's not half of what erlang offers out-of-the-box.
CB and Goliath also have very different code libraries available. You really should be looking at what libraries your project will need as it might disqualify one or both of these frameworks.(e.g. websockets support) Personally, I would be choosing between node.js vs CB, not Goliath vs CB. Mostly because I think the maturity and support is much better than Goliath. but that's entirely IMHO
wulftone
May 9, 2012, 8:05:57 PM5/9/12
to ChicagoBoss
Thanks, this is what I was looking for in response. A lot of you know
much better than I what lies underneath all of the fluff of different
languages. I also ran across DCell (http://www.unlimitednovelty.com/
2012/04/introducing-dcell-actor-based.html) which comes from a guy
who's really into Ruby and Erlang and basically implements much of
what Erlang has buy Ruby doesn't. I'm curious how close Ruby is
getting to being able to do what Erlang has done for ages. Not that
Erlang isn't wonderful, I'm sure, but the Ruby ecosystem is so huge
that if it becomes viable to have performance like Erlang, it might
actually happen. Maybe if someone made a web framework based on DCell
we could compare CB better?
much better than I what lies underneath all of the fluff of different
languages. I also ran across DCell (http://www.unlimitednovelty.com/
2012/04/introducing-dcell-actor-based.html) which comes from a guy
who's really into Ruby and Erlang and basically implements much of
what Erlang has buy Ruby doesn't. I'm curious how close Ruby is
getting to being able to do what Erlang has done for ages. Not that
Erlang isn't wonderful, I'm sure, but the Ruby ecosystem is so huge
that if it becomes viable to have performance like Erlang, it might
actually happen. Maybe if someone made a web framework based on DCell
we could compare CB better?
wulftone
May 9, 2012, 8:06:58 PM5/9/12
to ChicagoBoss
Shoot, it put a newline in my link..
Here it is again:
http://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based.html
Link!
Here it is again:
http://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based.html
Link!
Ben G.
May 10, 2012, 12:06:07 PM5/10/12
to chica...@googlegroups.com
wulftone
May 10, 2012, 3:22:36 PM5/10/12
to ChicagoBoss
lol, thanks. It's interesting to see these languages influence each
other and what happens in the long run to them.
On May 10, 9:06 am, "Ben G." <bngr...@gmail.com> wrote:
> Here, knock yourself out:https://github.com/celluloid/reel
>
>
>
>
>
>
>
> On Wednesday, May 9, 2012 5:05:57 PM UTC-7, wulftone wrote:
>
> > Thanks, this is what I was looking for in response. A lot of you know
> > much better than I what lies underneath all of the fluff of different
> > languages. I also ran across DCell (http://www.unlimitednovelty.com/
> > 2012/04/introducing-dcell-actor-based.html<http://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based...>)
other and what happens in the long run to them.
On May 10, 9:06 am, "Ben G." <bngr...@gmail.com> wrote:
> Here, knock yourself out:https://github.com/celluloid/reel
>
>
>
>
>
>
>
> On Wednesday, May 9, 2012 5:05:57 PM UTC-7, wulftone wrote:
>
> > Thanks, this is what I was looking for in response. A lot of you know
> > much better than I what lies underneath all of the fluff of different
> > languages. I also ran across DCell (http://www.unlimitednovelty.com/
Evan Miller
May 10, 2012, 11:54:18 PM5/10/12
to chica...@googlegroups.com
If I had to sum up the difference between Ruby and Erlang in a
sentence, it'd be this: Erlang makes programming harder, but
engineering easier, while Ruby makes programming easier, but
engineering harder.
It took me a long time to appreciate the difference between
programming and engineering. The distinction is somewhat artificial,
but I think of "programming" as those times you just want to produce
some output of interest, and engineering is when you start to worry
about performance and resource consumption.
With most languages, engineering websites is difficult. You have to
worry about templates being slow, databases taking a long time, the
garbage collector running, and all of the side-effects on the system
that these events have. As a result you have to think very carefully
about caching strategies, I/O strategies (async vs. sync), and
manually invoking the garbage collector.
Erlang makes all that stuff easy. Templates don't need to be cached,
I/O is always async, and the garbage collector runs on one process at
a time so you're not going to see weird system-wide performance
spikes. As a result you don't have to waste brain cycles thinking
about the usual engineering problems, and can focus on the user
interface and business logic.
With Ruby, novice programmers are led to believe that engineering Ruby
must be easy because programming Ruby is easy. But the reality is that
engineering a Ruby application is basically the same as engineering an
application written in any other language (apart from Erlang). You get
some nicer syntax along the way, and a lot of libraries, but you still
have to worry about threads and rendering time and stack sizes and all
that.
In a sense Erlang applications are practically engineered for you by
the guys at Ericsson. They made a large number of correct design
decisions that has resulted in a truly great platform to program for.
The trade-off with Erlang is that it's a functional language, which
requires more thinking to solve a particular logic problem, so
programming Erlang is harder than Ruby. (That and Erlang is slow at
crunching numbers.) But most of website development has nothing to do
with logic problems, let alone arithmetic, so you can get pretty far
with just sequential calls to APIs.
With CB I've tried to design a nice clean set of APIs that makes web
development in Erlang a lot of fun. You get the satisfaction of
knowing you're building an application on a rock-solid foundation, and
along the way you don't have to sweat over traditional engineering
problems. That's taken care of for you.
Evan
sentence, it'd be this: Erlang makes programming harder, but
engineering easier, while Ruby makes programming easier, but
engineering harder.
It took me a long time to appreciate the difference between
programming and engineering. The distinction is somewhat artificial,
but I think of "programming" as those times you just want to produce
some output of interest, and engineering is when you start to worry
about performance and resource consumption.
With most languages, engineering websites is difficult. You have to
worry about templates being slow, databases taking a long time, the
garbage collector running, and all of the side-effects on the system
that these events have. As a result you have to think very carefully
about caching strategies, I/O strategies (async vs. sync), and
manually invoking the garbage collector.
Erlang makes all that stuff easy. Templates don't need to be cached,
I/O is always async, and the garbage collector runs on one process at
a time so you're not going to see weird system-wide performance
spikes. As a result you don't have to waste brain cycles thinking
about the usual engineering problems, and can focus on the user
interface and business logic.
With Ruby, novice programmers are led to believe that engineering Ruby
must be easy because programming Ruby is easy. But the reality is that
engineering a Ruby application is basically the same as engineering an
application written in any other language (apart from Erlang). You get
some nicer syntax along the way, and a lot of libraries, but you still
have to worry about threads and rendering time and stack sizes and all
that.
In a sense Erlang applications are practically engineered for you by
the guys at Ericsson. They made a large number of correct design
decisions that has resulted in a truly great platform to program for.
The trade-off with Erlang is that it's a functional language, which
requires more thinking to solve a particular logic problem, so
programming Erlang is harder than Ruby. (That and Erlang is slow at
crunching numbers.) But most of website development has nothing to do
with logic problems, let alone arithmetic, so you can get pretty far
with just sequential calls to APIs.
With CB I've tried to design a nice clean set of APIs that makes web
development in Erlang a lot of fun. You get the satisfaction of
knowing you're building an application on a rock-solid foundation, and
along the way you don't have to sweat over traditional engineering
problems. That's taken care of for you.
Evan
Paul Barry
May 11, 2012, 5:06:13 AM5/11/12
to chica...@googlegroups.com
I'd concur with a lot of what Evan is saying here.
From my own point-of-view, I'm coming to Erlang (and now CB) from the
Python/Ruby/Perl world, with experience in a lot of the web frameworks
that exist in those arenas. What I'm finding is that although I tend
to think "programming" in Python, I'm much more of a "software
engineer" when it comes to working with Erlang. Yes, Erlang is
different, but once you are used to how Erlang thinks, it's not too
bad.
And, for the record, I'm having a blast working with CB. Not only is
it fun to develop with, but I'm finding the stuff I build is running
like a rocket compared to - say - an equivalent system written in
Python/Django. I'm especially pleased to see CB support MongoDB,
which I like to use on the back-end. :-)
Paul.
--
Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul....@itcarlow.ie
Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
From my own point-of-view, I'm coming to Erlang (and now CB) from the
Python/Ruby/Perl world, with experience in a lot of the web frameworks
that exist in those arenas. What I'm finding is that although I tend
to think "programming" in Python, I'm much more of a "software
engineer" when it comes to working with Erlang. Yes, Erlang is
different, but once you are used to how Erlang thinks, it's not too
bad.
And, for the record, I'm having a blast working with CB. Not only is
it fun to develop with, but I'm finding the stuff I build is running
like a rocket compared to - say - an equivalent system written in
Python/Django. I'm especially pleased to see CB support MongoDB,
which I like to use on the back-end. :-)
Paul.
Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul....@itcarlow.ie
Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland.
wulftone
May 11, 2012, 2:25:04 PM5/11/12
to ChicagoBoss
Great! This is turning into a very thoughtful discussion. It's great
to hear these things from the experts. Have any of you tried Elixir
(http://elixir-lang.org/)? It's been seeing a lot of development
lately, and I'm curious to know what people steeped in Erlang think of
its shortcomings vs. something like Elixir that runs on the same VM
and thus potentially has the same advantages as Erlang itself. Does
it mitigate some of what people think are Erlang's shortcomings? Just
as an experiment, would porting ChicagoBoss to Elixir provide any
insight into potential advantages of writing in that language?
Here's another tidbit I ran into that compares so-called "Sinatra-
like" frameworks written in Ruby, JavaScript, and Elixir:
https://gist.github.com/1582864
I imagine writing the same thing in Erlang would provide identical-ish
results as the Elixir one?
On May 11, 2:06 am, Paul Barry <paul.james.ba...@gmail.com> wrote:
> I'd concur with a lot of what Evan is saying here.
>
> From my own point-of-view, I'm coming to Erlang (and now CB) from the
> Python/Ruby/Perl world, with experience in a lot of the web frameworks
> that exist in those arenas. What I'm finding is that although I tend
> to think "programming" in Python, I'm much more of a "software
> engineer" when it comes to working with Erlang. Yes, Erlang is
> different, but once you are used to how Erlang thinks, it's not too
> bad.
>
> And, for the record, I'm having a blast working with CB. Not only is
> it fun to develop with, but I'm finding the stuff I build is running
> like a rocket compared to - say - an equivalent system written in
> Python/Django. I'm especially pleased to see CB support MongoDB,
> which I like to use on the back-end. :-)
>
> Paul.
>
> Paul Barry, w:http://paulbarry.itcarlow.ie- e: paul.ba...@itcarlow.ie
to hear these things from the experts. Have any of you tried Elixir
(http://elixir-lang.org/)? It's been seeing a lot of development
lately, and I'm curious to know what people steeped in Erlang think of
its shortcomings vs. something like Elixir that runs on the same VM
and thus potentially has the same advantages as Erlang itself. Does
it mitigate some of what people think are Erlang's shortcomings? Just
as an experiment, would porting ChicagoBoss to Elixir provide any
insight into potential advantages of writing in that language?
Here's another tidbit I ran into that compares so-called "Sinatra-
like" frameworks written in Ruby, JavaScript, and Elixir:
https://gist.github.com/1582864
I imagine writing the same thing in Erlang would provide identical-ish
results as the Elixir one?
On May 11, 2:06 am, Paul Barry <paul.james.ba...@gmail.com> wrote:
> I'd concur with a lot of what Evan is saying here.
>
> From my own point-of-view, I'm coming to Erlang (and now CB) from the
> Python/Ruby/Perl world, with experience in a lot of the web frameworks
> that exist in those arenas. What I'm finding is that although I tend
> to think "programming" in Python, I'm much more of a "software
> engineer" when it comes to working with Erlang. Yes, Erlang is
> different, but once you are used to how Erlang thinks, it's not too
> bad.
>
> And, for the record, I'm having a blast working with CB. Not only is
> it fun to develop with, but I'm finding the stuff I build is running
> like a rocket compared to - say - an equivalent system written in
> Python/Django. I'm especially pleased to see CB support MongoDB,
> which I like to use on the back-end. :-)
>
> Paul.
>
wulftone
May 11, 2012, 2:26:02 PM5/11/12
to ChicagoBoss
For the record here, I'm just exploring things--_definitely_ not
trying to talk down on any particular anything.
> > Paul Barry, w:http://paulbarry.itcarlow.ie-e: paul.ba...@itcarlow.ie
trying to talk down on any particular anything.
Graeme Defty
May 13, 2012, 7:46:17 AM5/13/12
to chica...@googlegroups.com
I'm also interested in Elixir.
I too noticed that many of the benefits touted for Erlang (light threads, light message passing, etc.) were actually benefits of the VM and not really related to the language at all.
It also occurred to me that having a more easily digestible language on the platform would help encourage new developers in the transition from the "other world" (i.e. the non-functionalites), and perhaps in time even get them into Erlang. (I do not subscribe to the view held by some of the old guard that we don't want more users of the platform.)
As a result of all that, many moons ago I did a fair bit of work creating a PEG-based parser for the Reia language, which had many of the same goals as Elixir (and didn't look dissimilar in many ways).
I was a little disappointed that the indent-structured version of the language was dropped in favour of the end-keyword version - like most people I follow the structure of a program form the indentation and it makes sense to me to make the compiler do the same - but Reia still looked like a nice language to me
However, a bigger disappointment was when the project owner dropped work on the language altogether on the basis that it was too similar to Elixir and Elixir was more advanced.
I wanted to offer to do something similar for the Elixir project, but my work with CB started soaking up too much time, and in truth I was a bit disheartened for a while.
I AM still interested in using Elixir with CB though. Models would still need to be in erlang I think because of the modified compiler we use, but I don't see why controllers couldn't be elixir, and in particular all the stuff in the /lib/ directory (which was where I planned to start) could be Elixir.
I got as far as downloading and installing Elixir, but that was it - lol.
I dont think that rewriting CB itself (or even parts of it) in erlang is of any great value. Offering Elixir to the USERS of CB is where the benefits lie IMHO.
I would be very interested to hear form anyone who has got further than I and maybe swap war stories as we go.
Cheers,
g
___________________________________________
I too noticed that many of the benefits touted for Erlang (light threads, light message passing, etc.) were actually benefits of the VM and not really related to the language at all.
It also occurred to me that having a more easily digestible language on the platform would help encourage new developers in the transition from the "other world" (i.e. the non-functionalites), and perhaps in time even get them into Erlang. (I do not subscribe to the view held by some of the old guard that we don't want more users of the platform.)
As a result of all that, many moons ago I did a fair bit of work creating a PEG-based parser for the Reia language, which had many of the same goals as Elixir (and didn't look dissimilar in many ways).
I was a little disappointed that the indent-structured version of the language was dropped in favour of the end-keyword version - like most people I follow the structure of a program form the indentation and it makes sense to me to make the compiler do the same - but Reia still looked like a nice language to me
However, a bigger disappointment was when the project owner dropped work on the language altogether on the basis that it was too similar to Elixir and Elixir was more advanced.
I wanted to offer to do something similar for the Elixir project, but my work with CB started soaking up too much time, and in truth I was a bit disheartened for a while.
I AM still interested in using Elixir with CB though. Models would still need to be in erlang I think because of the modified compiler we use, but I don't see why controllers couldn't be elixir, and in particular all the stuff in the /lib/ directory (which was where I planned to start) could be Elixir.
I got as far as downloading and installing Elixir, but that was it - lol.
I dont think that rewriting CB itself (or even parts of it) in erlang is of any great value. Offering Elixir to the USERS of CB is where the benefits lie IMHO.
I would be very interested to hear form anyone who has got further than I and maybe swap war stories as we go.
Cheers,
g
___________________________________________
wulftone
May 13, 2012, 2:36:24 PM5/13/12
to ChicagoBoss
Yeah, that all sounds good to me. I really feel fine about the Erlang
syntax, but Elixir does look very promising--not so much because of
the syntax, but the additional features (obviously taken from
experience with Ruby) it offers above and beyond what Erlang does. It
being "more digestible" is surely nice for those people that hate
Erlang's syntax, but really not as important as what it can do. I
think it's nice that Elixir adds more functionality than Erlang has,
making it a kind of superset of Erlang, instead of just a different
syntax.
With regards to CB, would some of Elixir's metaprogramming features
remove the need for a "modified compiler"?
> ...
>
> read more »
syntax, but Elixir does look very promising--not so much because of
the syntax, but the additional features (obviously taken from
experience with Ruby) it offers above and beyond what Erlang does. It
being "more digestible" is surely nice for those people that hate
Erlang's syntax, but really not as important as what it can do. I
think it's nice that Elixir adds more functionality than Erlang has,
making it a kind of superset of Erlang, instead of just a different
syntax.
With regards to CB, would some of Elixir's metaprogramming features
remove the need for a "modified compiler"?
> On 12 May 2012 01:26, wulftone <trevor.bort...@gmail.com> wrote:
>
>
>
>
>
>
>
> > For the record here, I'm just exploring things--_definitely_ not
> > trying to talk down on any particular anything.
>
> > On May 11, 11:25 am, wulftone <trevor.bort...@gmail.com> wrote:
> > > Great! This is turning into a very thoughtful discussion. It's great
> > > to hear these things from the experts. Have any of you tried Elixir
> > > (http://elixir-lang.org/)?It's been seeing a lot of development
>
>
>
>
>
>
>
> > For the record here, I'm just exploring things--_definitely_ not
> > trying to talk down on any particular anything.
>
> > On May 11, 11:25 am, wulftone <trevor.bort...@gmail.com> wrote:
> > > Great! This is turning into a very thoughtful discussion. It's great
> > > to hear these things from the experts. Have any of you tried Elixir
>
> read more »
Evan Miller
May 13, 2012, 5:59:58 PM5/13/12
to chica...@googlegroups.com
On Sun, May 13, 2012 at 1:36 PM, wulftone <trevor....@gmail.com> wrote:
> Yeah, that all sounds good to me. I really feel fine about the Erlang
> syntax, but Elixir does look very promising--not so much because of
> the syntax, but the additional features (obviously taken from
> experience with Ruby) it offers above and beyond what Erlang does. It
> being "more digestible" is surely nice for those people that hate
> Erlang's syntax, but really not as important as what it can do. I
> think it's nice that Elixir adds more functionality than Erlang has,
> making it a kind of superset of Erlang, instead of just a different
> syntax.
>
> With regards to CB, would some of Elixir's metaprogramming features
> remove the need for a "modified compiler"?
Elixir might be a good fit for the model layer, actually, which is
> Yeah, that all sounds good to me. I really feel fine about the Erlang
> syntax, but Elixir does look very promising--not so much because of
> the syntax, but the additional features (obviously taken from
> experience with Ruby) it offers above and beyond what Erlang does. It
> being "more digestible" is surely nice for those people that hate
> Erlang's syntax, but really not as important as what it can do. I
> think it's nice that Elixir adds more functionality than Erlang has,
> making it a kind of superset of Erlang, instead of just a different
> syntax.
>
> With regards to CB, would some of Elixir's metaprogramming features
> remove the need for a "modified compiler"?
where most of the crazy compiler stuff happens. A couple of recent
patches make it possible to swap out BossDB with something else; see
https://github.com/evanmiller/ChicagoBoss/pull/107. At this point
there's nothing stopping anyone from making an Elixir-based ORM that
works with CB. If you are in the "thin controller/fat model" camp,
this will mean most of your code would be in Elixir and templates. I
am not too familiar with how Elixir is implemented, but ErlyDTL might
need to be modified to work with Elixir objects.
I am not keen on having controller APIs for multiple languages. It
just adds too much complexity, and it will tend to fragment the
community, for example Erlang programmers would not be able to answer
an Elixir programmer's questions. As it is I think Erlang's semantics
work very well with controllers -- no side-effects, everything passed
by return values, and no double-render errors. Elixir might offer
similar benefits, but I don't see that it offers a clear advantage
over vanilla Erlang when writing controller logic.
Long story short -- I think an Elixir-based ORM that could plug into
CB would be a great addition. But anything beyond that should probably
go into its own framework.
Evan
Evan Miller
http://www.evanmiller.org/
Vitor Pellegrino
Sep 17, 2012, 5:36:31 PM9/17/12
to chica...@googlegroups.com
Sorry to bring this post back to life, just wanted to know if people are still interested on this or if there is any updates on that subject.
On Sunday, May 13, 2012 1:46:17 PM UTC+2, graeme defty wrote:
Comments inline,
On Sunday, May 13, 2012 1:46:17 PM UTC+2, graeme defty wrote:
I'm also interested in Elixir.
I too noticed that many of the benefits touted for Erlang (light threads, light message passing, etc.) were actually benefits of the VM and not really related to the language at all.
It also occurred to me that having a more easily digestible language on the platform would help encourage new developers in the transition from the "other world" (i.e. the non-functionalites), and perhaps in time even get them into Erlang. (I do not subscribe to the view held by some of the old guard that we don't want more users of the platform.)
As a result of all that, many moons ago I did a fair bit of work creating a PEG-based parser for the Reia language, which had many of the same goals as Elixir (and didn't look dissimilar in many ways).
I was a little disappointed that the indent-structured version of the language was dropped in favour of the end-keyword version - like most people I follow the structure of a program form the indentation and it makes sense to me to make the compiler do the same - but Reia still looked like a nice language to me
However, a bigger disappointment was when the project owner dropped work on the language altogether on the basis that it was too similar to Elixir and Elixir was more advanced.
I wanted to offer to do something similar for the Elixir project, but my work with CB started soaking up too much time, and in truth I was a bit disheartened for a while.
I AM still interested in using Elixir with CB though. Models would still need to be in erlang I think because of the modified compiler we use, but I don't see why controllers couldn't be elixir, and in particular all the stuff in the /lib/ directory (which was where I planned to start) could be Elixir.
I got as far as downloading and installing Elixir, but that was it - lol.
I dont think that rewriting CB itself (or even parts of it) in erlang is of any great value. Offering Elixir to the USERS of CB is where the benefits lie IMHO.
Me too. I think that providing elixir to CB apps would ease very significantly the learning curve.
I would be very interested to hear form anyone who has got further than I and maybe swap war stories as we go.
I think i haven't made much progress other than this. Pretty much what i've did was to add Elixir as a rebar dependency and also listed as a library. I tried to compile the project and it shows no errors, so i think this setup is fine. I just went as far as this; my very limited knowledge of both Elixir and Erlang did impede me to go any further.
I would also love to hear stories from people who have tried this. I hope it is something possible to do!
Cheers,
Cheers,
Vitor
Graeme Defty
Sep 17, 2012, 9:42:49 PM9/17/12
to chica...@googlegroups.com
Vitor,
Yes, I for one am still interested, but have had no time to do anything lately, so no updates of any interest at this point.
I would be very interested in the changes you have made because all my efforts so far have been fully manual with no integration with CB.
The other thing that would be nice in terms of set up/integration (and my apologies if you have done this already and I have not understood) is to have Elixir modles automatically re-compiled on update when in a development environment.
Cheers,
g
PS
I just noticed that there was an error in my original post. When i referred to there being no benefit in rewriting CB in erlang, I meant of course no point in rewriting it in Elixir ;-)
__________________________________________________________
Yes, I for one am still interested, but have had no time to do anything lately, so no updates of any interest at this point.
I would be very interested in the changes you have made because all my efforts so far have been fully manual with no integration with CB.
The other thing that would be nice in terms of set up/integration (and my apologies if you have done this already and I have not understood) is to have Elixir modles automatically re-compiled on update when in a development environment.
Cheers,
g
PS
I just noticed that there was an error in my original post. When i referred to there being no benefit in rewriting CB in erlang, I meant of course no point in rewriting it in Elixir ;-)
__________________________________________________________
Vitor Pellegrino
Sep 18, 2012, 6:10:11 AM9/18/12
to chica...@googlegroups.com
Hi Graeme!
On Tuesday, September 18, 2012 3:42:51 AM UTC+2, graeme defty wrote:
Basically what i've done apart from the normal is described in this gist: https://gist.github.com/3742322.
On Tuesday, September 18, 2012 3:42:51 AM UTC+2, graeme defty wrote:
Vitor,
Yes, I for one am still interested, but have had no time to do anything lately, so no updates of any interest at this point.
I would be very interested in the changes you have made because all my efforts so far have been fully manual with no integration with CB.
Basically what i've done apart from the normal is described in this gist: https://gist.github.com/3742322.
The other thing that would be nice in terms of set up/integration (and my apologies if you have done this already and I have not understood) is to have Elixir modles automatically re-compiled on update when in a development environment.
That would be my very next step, as soon as i could get a Hello World working. The problem is that i don't believe Elixir supports parameterized modules, which is used extensively throughout Chicago Boss. I might be wrong (and i really hope i am!!), as i'm a total newbie to the platform and to the framework, but i think that's a major no-go - at least for writing models and controllers using it.
Reply all
Reply to author
Forward
0 new messages