perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ragnar Hákonarson <rag...@signal.bz>
Subject RE: Status of Embperl?
Date Tue, 04 Sep 2012 01:00:24 GMT
I just want to join Jose and air my gratitude to Gerald for his
outstanding work and, not least, his availability which has been
acknowledged by many over the years.



I started using Embperl in 1999 and there are projects under my hat that
are still at large today utilising Embperl. I, as many, do not question
the robustness nor concept behind Embperl but have started to question
whether Embperl is something to utilise in a new project. Embperl
addresses current needs but the apparent lack of enthusiasts behind it
today (apart from Gerald himself and a few die hard including myself) does
beg the question whether it is as a wise choice for future needs.



I for one would love to see the return of the vibrant community once
associated with Embperl and, as far as I can see, the sudden influx in
activity on this mailing list tells me there may very well still be life
in this “animal”.



Time to join forces behind Gerald and bring Embperl back to the forefront?



From: Jose Fonseca [mailto:zefonseca@gmail.com]
Sent: 03 September 2012 16:08
To: embperl@perl.apache.org
Subject: Re: Status of Embperl?



> The good news is that I currently working on a payed project which
includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will be a
new release in a few weeks, which solves all these problems.

That is actually very exciting news. I'd like to thank Gerald Richter for
his work and how available he is for all of us. I've never had a support
email go unanswered, so Gerald and the community around Embperl are
definitely at the heart of its success.

About Embperl being alive or not: My job is to maintain a tourism-related
system that is now about 15 years old.

As most Perl apps, it all started with a simple CGI .pl script which grew
and was divided into modules and became a whole app with time. In 2005 the
front end of the system was migrated to Embperl and we're still using it
to this day. In 2006 we migrated 90% of our PHP code into Embperl and Perl
modules. We're still unable to get rid of the PHP module in Apache,
because some of our users publish Wordpress blogs.

We feel that there are pros and cons in our deployment.

Pros: Embperl is extremely stable, well implemented and has been debugged
for years. We simply deploy and forget about it. The Embperl templating
system is well thought out, there is no strange crosstalk between tags,
there are no unexpected behaviors and dependency conflicts in between
Embperl sections even though some run at different times(no "magical" and
difficult to debug collateral effects, etc). When I did parallel
programming projects which used JSP or ASP, I immediately felt the
diffculty introduced by the excessive complication and bloat in those
technologies. Embperl is very Perl-ish, it makes easy things easy, hard
things possible.

When our app grew and a whole host of features were added such as a
DBIx::Class ORM backend(which in turn pulls in hundreds of modules) we had
absolutely zero problems with Embperl, it simply does not mess with the
rest of Apache and does not introduce any module incompatibilities to the
rest of our app. Apart from the infamous CGI.pm change in namespace which
broke our upload forms, we've never had an issue with the thousands of
modules running in the background at any given moment. This may seem
"obvious" but it's not, it is in fact quite improbable that with so many
dependencies to our app, that it actually runs so smoothly.

Cons/Ideas:

Book
Embperl could really use a book. There should be a "Camel book" for
Embperl IMHO, nowadays it could be an eBook, I'm sure the community would
buy it.

Config
The configuration directives currently have two versions, the environment
version and the Apache instruction, that was a source of confusion for our
team at some point. I think these days that could be unified into one
standard configuration system. One global config on a embperl.ini file and
a per-application config in a specific location would solve it, getting
rid of %ENV.

Perl JAR
Perl does not have a JAR-like packaging system, so deployments are always
tough, we can't just deploy a package that is then automatically started
as an application on the server. Right now we're using Amazon AMI's for
this job, we basically package a whole server as the application, to avoid
2 hours running CPAN compilations before a server can go up.

This, of course, is a Perl issue not Embperl, but if you're considering
Embperl for a project, you probably should consider this fact.

Another Con is, Embperl is very low level in order to achieve speed. This
couples it to the OS and to Perl very tightly, thus we get these issues
mentioned on this thread now and then, compilation is straight down to
platform-dependent binaries. A Embperl installation in our development
servers does not run on our production servers.

With the price of hardware being ridiculous these days, maybe it'd be a
good idea to abstract more of Embperl into pure Perl instead of C, we may
lose some efficiency but then again nowadays we're more concerned with
parallelism and being able to scale sideways.

Scaling horizontally is very difficult with Embperl. Unless you package a
whole server as the application, every new machine added to a pool will
have to run CPAN and update hundreds of modules, which may take hours.

So the main con against Embperl is not actually an Embperl issue: Perl
urgently needs an application packaging system like Java already has had
for 17 years. Upload a binary and the app is deployed, that's how simple
it should be in 2012. Nobody deserves to sit there and watch GCC
compilation messages scroll by in this time and age, IMHO. You can afford
it as a single developer, but when using Embperl for tens of deployments
that is simply undoable.

Aside from that, Embperl has survived this mess of "Web 2.0" booms and
busts for us. Our REST web services are implemented in Embperl, with JSON
in the back. The DBIx::Class ORM has held up to the test of time and our
migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth sailing.

So there's our story. Embperl continues to be alive and well for us and we
depend on it on a daily basis with historically near zero downtime due to
Embperl itself.

Cheers!

On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio
<embperl@thefreecat.org> wrote:

Le 03/09/2012 09:22, richter@ecos.de a écrit :



The good news is that I currently working on a payed project which
includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
be a new release in a few weeks, which solves all these problems.



Great news, be strong !

--
Jean-Christophe Boggio                       -o)
embperl@thefreecat.org                       /\\
Independant Consultant and Developer        _\_V



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org




Mime
View raw message