Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DotCloud releases support for Perl, aka Camel-as-a-Service

blog.dotcloud.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#31

Post by whiskeyjack »

bbbbbbbbb wrote: post #25
jpetazzo wrote: post #24

Earlier quoted context omitted.

Hi, Well, actually, we didn't pickup Plack from its author. When people started asking about Perl, we just replied with another question: "which framework? how? what?", and we tried extract the most common denominator. The vast majority told us about Mojolicious, Dancer and Catalyst. There seemed to be a pattern :-) Regarding the server interface, a lot of people seems to agree over Plack. We were the ones asking "he…

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea... ). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >So…

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone.

I'm REALLY looking forward to playing with DotCloud.

Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#32

Post by mst »

bbbbbbbbb wrote: post #25
jpetazzo wrote: post #24

Earlier quoted context omitted.

Hi, Well, actually, we didn't pickup Plack from its author. When people started asking about Perl, we just replied with another question: "which framework? how? what?", and we tried extract the most common denominator. The vast majority told us about Mojolicious, Dancer and Catalyst. There seemed to be a pattern :-) Regarding the server interface, a lot of people seems to agree over Plack. We were the ones asking "he…

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea... ). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >So…

If you have a problem with Catalyst dependencies, please report them to irc.perl.org #catalyst (I'm mst on there).

Any time anybody reports a problem with them, we go out of our way to solve it - avoiding wheel reinvention is important to us to speed development but we understand that using a module makes us responsible for it installing for end users.

if you really want CGI.pm, there are Plack modules to convert a PSGI environment to a CGI environment - descended roughly from the Catalyst::Controller::WrapCGI that Opsview sponsored Shadowcat to write years ago.

And remember, PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#33

Post by nmcfarl »

whiskeyjack wrote: post #31
bbbbbbbbb wrote: post #25

Earlier quoted context omitted.

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea... ). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >So…

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone. I'm REALLY looking forward to playing with DotCloud. Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

Likewise my company is 100% PSGI for the last year+, we're a mix of a good number of Catalyst and Dancer apps. We've had absolutely 0 problems here.

PSGI stable, sane and the way you want to be doing things.

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#35

Post by bbbbbbbbb »

mst wrote: post #30
bbbbbbbbb wrote: post #29

Earlier quoted context omitted.

Like FastCGI is... PSGI has been developed in 2009, then nothing for a long time (and as it hasn't spread as wild fire across providers i don't think there is enough real dev around it to assure that it is "stable" enough), now, a dev release, sure... the doc is unclear as to what it brings on the table, why it should be used, how to be used, the improvement it brings if any are really not clear... "you will be glad…

PSGI is not at the same level as FastCGI. Nobody in their right mind has been using CGI::Fast directly for years - we've done it via adapters through e.g. Catalyst::Engine::FCGI for Catalyst and equivalents for other frameworks. PSGI is just a means to present various HTTP bearing things to the app - in fact the FCGI.pm maintainers all now deploy their applications via Plack::Handler::FCGI. All perl frameworks of not…

> Nobody in their right mind has been using CGI::Fast directly for years

Could you extend on that? Been using it for years,just works fine.

>PSGI is just a means to present various HTTP bearing things to the app

I really still don't get the benefit though. But perhaps I should dig into it more (for now, the python implementation doc was helpful but still did not bring me that much clues as to the real benefits about it)

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#36

Post by bbbbbbbbb »

mst wrote: post #32
bbbbbbbbb wrote: post #25

Earlier quoted context omitted.

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea... ). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >So…

If you have a problem with Catalyst dependencies, please report them to irc.perl.org #catalyst (I'm mst on there). Any time anybody reports a problem with them, we go out of our way to solve it - avoiding wheel reinvention is important to us to speed development but we understand that using a module makes us responsible for it installing for end users. if you really want CGI.pm, there are Plack modules to convert a P…

>PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.

I see. Perhaps my vision of the state of PSGI is not right indeed. Nethertheless, my apps run under Fast::CGI and I really don't see the advantage of PSGI.

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#37

Post by bbbbbbbbb »

nmcfarl wrote: post #33
whiskeyjack wrote: post #31

Earlier quoted context omitted.

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone. I'm REALLY looking forward to playing with DotCloud. Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

Likewise my company is 100% PSGI for the last year+, we're a mix of a good number of Catalyst and Dancer apps. We've had absolutely 0 problems here. PSGI stable, sane and the way you want to be doing things.

As both of you have a good experience of Plack/PSGI, could you sum up the benefit you got from using it?

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#38

Post by bbbbbbbbb »

whiskeyjack wrote: post #31
bbbbbbbbb wrote: post #25

Earlier quoted context omitted.

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea... ). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development. >So…

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone. I'm REALLY looking forward to playing with DotCloud. Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

>Plack/PSGI has been embraced by almost everyone.

In your company or in general? Because if it's in general, I would be more than happy to see where you get your stats.

> You do Miyagawa a disservice implying he's pumping his own code.

Well, I do think that a not even 2yo spec,a set of modules that are 6~18 months old pushed on a cloud service like that with no back up plan for more "traditional" systems is a way to push its own system. we can agree to disagree on that. which percentage of providers offer plack with nginx nowadays compared to Apache with FactCGI?

Re: DotCloud releases support for Perl, aka Camel-as-a-Service

#40

Post by bulknews »

bbbbbbbbb wrote: post #29
perlgeek wrote: post #28

Earlier quoted context omitted.

What's devish about PSGI? Seems like exactly the right choice for the task.

Like FastCGI is... PSGI has been developed in 2009, then nothing for a long time (and as it hasn't spread as wild fire across providers i don't think there is enough real dev around it to assure that it is "stable" enough), now, a dev release, sure... the doc is unclear as to what it brings on the table, why it should be used, how to be used, the improvement it brings if any are really not clear... "you will be glad…

> the doc is unclear as to what it brings on the table, why it should be used, how to be used, the improvement it brings if any are really not clear.

I assume you're looking at the non-dev PSGI specification on CPAN. We're working on revising the documentation to upgrade the specification to 1.1, as well as improving the FAQ document.

Just to address your concern, I improved the part where it explains the benefits of switching to PSGI: https://github.com/miyagawa/psgi-specs/commit/e3e756cf1eebe8...

Also, for more generic overview and introduction of what PSGI is and why it is useful, take a look at my slides at OSCON 2010: http://www.slideshare.net/miyagawa/plack-at-oscon-2010

- miyagawa

Post reply on HN