Mojolicious – Perl real-time web framework(mojolicio.us)
mojolicio.us
Mojolicious – Perl real-time web framework
http://mojolicio.us/
89 comments
Granted, the object-orientation [in Perl] felt more like a hack than a normal language feature (because it was one)...
Perl's OOP is definitely a hack! But it's a clever and elegant hack, and younger languages can learn a lot from studying how an awk++ managed to evolve support for all these new programming paradigms, without being totally co-opted by the ones which turned out to be fads. (When these languages are Perl's age, will they have evolved as successfully?)
Take OOP support in Perl. Prior to that, Perl had references, which could point to other basic value types, and it had packages, which were namespaces in the symbol table. Only two small changes were necessary for OOP.
First, a new built-in function `bless` was added which marked a reference as associated with a certain package. Second, a new binary operator for dispatch was added, the familiar `->` from other languages. The dispatch operator looked up a package from the reference on the left hand side, looked up a symbol within that package given by the right hand side, and pushed the reference onto the front of the argument list in the subsequent function call. In the called function, the initial reference argument became the equivalent of `this`, by convention.
Modulo some discussion of @ISA, that's it. You now understand Perl's implementation of OOP.
The elegance of this approach finally hit home for me when building transparent RPC for Perl and other languages. On the client side, when you dispatch a function call on a "stub" object, you'd like to dispatch a real function call on a remote object. In Python, you have to worry about whether you're calling a "bound function" on the remote object, versus calling a static method of the remote object, versus calling a "free function" defined at module scope (how do you address these?), and so on. In Perl, these are all effectively the same thing because the dispatch operator is so simple, and there's no extra OOP structure baked into the language itself like there is with Python.
Disclaimer: I mostly write Python 2.x now, but things like the complicated object runtime and the general uselessness of lambdas strike me as places where the language has stumbled.
Perl's OOP is definitely a hack! But it's a clever and elegant hack, and younger languages can learn a lot from studying how an awk++ managed to evolve support for all these new programming paradigms, without being totally co-opted by the ones which turned out to be fads. (When these languages are Perl's age, will they have evolved as successfully?)
Take OOP support in Perl. Prior to that, Perl had references, which could point to other basic value types, and it had packages, which were namespaces in the symbol table. Only two small changes were necessary for OOP.
First, a new built-in function `bless` was added which marked a reference as associated with a certain package. Second, a new binary operator for dispatch was added, the familiar `->` from other languages. The dispatch operator looked up a package from the reference on the left hand side, looked up a symbol within that package given by the right hand side, and pushed the reference onto the front of the argument list in the subsequent function call. In the called function, the initial reference argument became the equivalent of `this`, by convention.
Modulo some discussion of @ISA, that's it. You now understand Perl's implementation of OOP.
The elegance of this approach finally hit home for me when building transparent RPC for Perl and other languages. On the client side, when you dispatch a function call on a "stub" object, you'd like to dispatch a real function call on a remote object. In Python, you have to worry about whether you're calling a "bound function" on the remote object, versus calling a static method of the remote object, versus calling a "free function" defined at module scope (how do you address these?), and so on. In Perl, these are all effectively the same thing because the dispatch operator is so simple, and there's no extra OOP structure baked into the language itself like there is with Python.
Disclaimer: I mostly write Python 2.x now, but things like the complicated object runtime and the general uselessness of lambdas strike me as places where the language has stumbled.
Perl OOP is a hack, but coming from university where they taught Java, suddenly it made the whole thing obvious and transparent (to me at least).
Inheritance was no longer a black box, but just a way of working out where to look for the method and execute it.
Inheritance was no longer a black box, but just a way of working out where to look for the method and execute it.
Great answer, thanks for explaining this! I'm curious about how much this approach differs from the one pursued by Javascript, which seems pretty similar to me.
Javascript lacks the "packages" part of the mix, it uses Prototypal inheritance rather than Class based inheritance.
If you squint you can view prototypal inheritance as class-based-inheritance-where-everything-is-a-singleton ... but you really need some alcohol to deal with the headache you get from squinting that much.
If you squint you can view prototypal inheritance as class-based-inheritance-where-everything-is-a-singleton ... but you really need some alcohol to deal with the headache you get from squinting that much.
> ... the general uselessness of lambdas ...
This sounds interesting. Why do you feel this way?
This sounds interesting. Why do you feel this way?
'sigil' referenced Python with "uselessness of lambdas", not Perl.
(If you still wonder -- from your comment history you shouldn't -- try Google: python lambda broken)
(If you still wonder -- from your comment history you shouldn't -- try Google: python lambda broken)
[deleted]
If you haven't played with Perl lately, it's worth looking into Moose, an object system for Perl. It not only offers a much nicer syntax for making objects, but provides features like read-only accessors, roles, introspection, and even types! http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod
I work with Perl professionally now after having spent most of my self-taught programming education using Python, and I've been pleasantly surprised with the language. I'm both coding new projects and working with a more than decade old code base, and I've found that Perl code is as good as the programmer.
Yes, like any decades old language it has its warts, but Perl 5 itself is still being developed and improved upon. For those who know another scripting language, the free book Modern Perl is a great place to start learning: http://modernperlbooks.com/books/modern_perl_2014/
I work with Perl professionally now after having spent most of my self-taught programming education using Python, and I've been pleasantly surprised with the language. I'm both coding new projects and working with a more than decade old code base, and I've found that Perl code is as good as the programmer.
Yes, like any decades old language it has its warts, but Perl 5 itself is still being developed and improved upon. For those who know another scripting language, the free book Modern Perl is a great place to start learning: http://modernperlbooks.com/books/modern_perl_2014/
Moose is very clever, but all that cleverness has a cost.
One of the things I like about Perl is that it offers tremendous performance, in addition to having an actually-useful debugger.
Subroutine calls in Perl aren't free; in fact they have a significant performance penalty if overused. And that's exactly what Moose uses, in droves.
Making Perl act like Ruby will also make it as slow as Ruby, and as difficult to debug.
One of the things I like about Perl is that it offers tremendous performance, in addition to having an actually-useful debugger.
Subroutine calls in Perl aren't free; in fact they have a significant performance penalty if overused. And that's exactly what Moose uses, in droves.
Making Perl act like Ruby will also make it as slow as Ruby, and as difficult to debug.
Both Moo and Moose generated inlined versions of their constructors and accessors that mean that there's only a single method call being involved.
As such, runtime is just as fast as any other perl code that uses accessor methods rather than poking into its own internals.
Plus, of course, once you've got a Devel::NYTProf profile showing that a particular accessor is a hot spot, you can still poke into your own internals for that particular purpose to resolve the bottleneck.
So, no, not really; generally you only pay a cost for the pieces of cleverness that you actually use, especially given the existence of Moo for fast-startup code where you don't need the MOP.
As such, runtime is just as fast as any other perl code that uses accessor methods rather than poking into its own internals.
Plus, of course, once you've got a Devel::NYTProf profile showing that a particular accessor is a hot spot, you can still poke into your own internals for that particular purpose to resolve the bottleneck.
So, no, not really; generally you only pay a cost for the pieces of cleverness that you actually use, especially given the existence of Moo for fast-startup code where you don't need the MOP.
Yes, so you can use Moose if you feel that it is necessary, Moo if you want something more lightweight, or nothing if you want speed. Just like there are modules for parameter type checking and all sorts of other nice features. My point is that Perl OO has some alternatives available from within Perl.
I don't know enough to vouch for Perl's performance vs other scripting languages, but I do know my boss (a very experienced Perl hacker) has a favorite saying: "If you wanted performance, why did you pick Perl?" :)
I don't know enough to vouch for Perl's performance vs other scripting languages, but I do know my boss (a very experienced Perl hacker) has a favorite saying: "If you wanted performance, why did you pick Perl?" :)
They are looking to move part of Moose into the core I think. I haven't kept up much lately. They are also optimizing things in the newer versions.
> an object system for Perl. It not only offers a much nicer syntax for making objects, but provides features like read-only accessors, roles, introspection, and even types!
and even metaobject protocol
and even metaobject protocol
I've heard a lot of good things about Moose, the Modern Perl effort & so on. Enough that I periodically think about jumping back in the Perl waters. However, I always wonder if it's worth it, because Perl 6 is always "not far from release", so I figure I'll wait to check things out again.
Until the Perl community resolves the issues with Perl 6, the waters are too murky for a lot of otherwise would-be JAPHs.
Until the Perl community resolves the issues with Perl 6, the waters are too murky for a lot of otherwise would-be JAPHs.
Don't think of Perl 5 and Perl 6 as being like the Python 2 vs Python 3 situation. Perhaps a better comparison would be that of C vs C++: the latter is inspired by the former, but not everyone who uses the former has any interest (or needs to have any interest) in the latter.
Perl 6 is worth paying attention to, but not as "something which will make Perl 5 obsolete". Don't let the status of the various P6 distributions stop you from using P5 to make cool stuff today. :)
Perl 6 is worth paying attention to, but not as "something which will make Perl 5 obsolete". Don't let the status of the various P6 distributions stop you from using P5 to make cool stuff today. :)
Perl5 and Perl6 are separate languages. Best thing is just to pretend that Perl6 doesn't exist. God knows everybody else does.
Those are separate languages, they shouldn't even have named "Perl 6" with "Perl" in it.
> Moose, the Modern Perl effort & so on.
That's mostly just a marketing ploy by a few people trying to make money off books and speaking fees. Ignore it.
That's mostly just a marketing ploy by a few people trying to make money off books and speaking fees. Ignore it.
Slightly off-topic, but I can't help but commenting on your statement:
> To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code
I've been a part of an awful lot of different programming communities over the years. And somehow each one has a different set of languages they know and favor and have learned in the past.
What's more, they seem to think this same experience more universal than not. I've heard whole groups of people who claim in three part harmony that they love [X], and don't know anyone who's ever used [Y].
Every time I see a comment or blog post or tweet that mentions "that [Z] language and/or tool that we all know and love", I can't help but wonder which gated community they're a part of. It's just automatic now. Kind of like how every time I hear Canon in D, I remember the Pachelbel rant on youtube.
> To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code
I've been a part of an awful lot of different programming communities over the years. And somehow each one has a different set of languages they know and favor and have learned in the past.
What's more, they seem to think this same experience more universal than not. I've heard whole groups of people who claim in three part harmony that they love [X], and don't know anyone who's ever used [Y].
Every time I see a comment or blog post or tweet that mentions "that [Z] language and/or tool that we all know and love", I can't help but wonder which gated community they're a part of. It's just automatic now. Kind of like how every time I hear Canon in D, I remember the Pachelbel rant on youtube.
The "installation" instructions wgets a script (over http) which in turn curls a raw github link of cpanminus which is "a script to get, unpack, build and install modules from CPAN" which then downloads and installs the perl module.
How many developers or "power users" would have just ran that command without even thinking about it?
I guess signing packages with trusted keys and serving them over https is far too lame for devs these days.
(Not that I'm calling out this particular project, it's seems to be crazy popular to offer "curl some.script | bash" as installation instructions lately for some reason.)
How many developers or "power users" would have just ran that command without even thinking about it?
I guess signing packages with trusted keys and serving them over https is far too lame for devs these days.
(Not that I'm calling out this particular project, it's seems to be crazy popular to offer "curl some.script | bash" as installation instructions lately for some reason.)
Hopefully, most people would check their package managers first. Debian and Centos both have packages for it at least.
Distro packages are often a bit behind the official releases. I prefer to develop in the most recent version of a framework / library, as it generally makes things a bit more future proof.
What collyw said. And most people prefer to use their own installation of Perl (see perlbrew) instead of the system Perl for development. The same seems to go for other scripting environments.
nope, cpan is a fast changing target. You can make it easy on yourself by building your own perl (with perlbrew, super easy) and managing your cpan modules with cpanminus. The system perl is for the system, your perl is for you.
This is a fully open source project. And that, includes all the packaging and deployment tools involved and available (tons of options).
Big corps (and users which avoid smartphones, certain social networks, marketing campaigns, etc, like me), should develop their internal git mirrors, cpan mirror, build systems, etc. As usual.
Many developers reproduce the same issue with node, python, ruby etc. That does not remove LOVE from this beautiful framework.
I can state that the mojolicio.us "web development can be fun again" is true for me.
Just go for it, check yourself the docs and the source, hack, and judge by yourself.
We are talking about that, not about the lack of common sense of many developers, when the topic is about systems, security and operational tasks.
Perl apps can be deployed securely after auditing them. What knowledge do you lack about this defocus topic ?
Big corps (and users which avoid smartphones, certain social networks, marketing campaigns, etc, like me), should develop their internal git mirrors, cpan mirror, build systems, etc. As usual.
Many developers reproduce the same issue with node, python, ruby etc. That does not remove LOVE from this beautiful framework.
I can state that the mojolicio.us "web development can be fun again" is true for me.
Just go for it, check yourself the docs and the source, hack, and judge by yourself.
We are talking about that, not about the lack of common sense of many developers, when the topic is about systems, security and operational tasks.
Perl apps can be deployed securely after auditing them. What knowledge do you lack about this defocus topic ?
These instructions are for people unfamiliar with perl and CPAN.
Developers are supposed to do "cpanm Mojolicious", like for any other perl module.
Developers are supposed to do "cpanm Mojolicious", like for any other perl module.
So the people least equipped to evaluate the security implications of the friendly instructions are the ones who are most encouraged to do something awful?
"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"
"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"
That is a big leap in logic really.
Whats awful about it? I don't understand the difference in security vetting between that installer or the code its installing.
What I'm getting at is its probably easier for me to get this line of source code added to a perl module:
# Don't actually run this in a Perl interpreter, esp not as root, OK?
`rm -Rf /`;
It would be harder to get this added to the installer:
# Don't actually run this in a shell script, esp not as root, OK?
rm -Rf /
Also if CPAN / its installer / github / etc get owned, the last problem to be concerned about is one little perl module. You have bigger trouble.
What I'm getting at is its probably easier for me to get this line of source code added to a perl module:
# Don't actually run this in a Perl interpreter, esp not as root, OK?
`rm -Rf /`;
It would be harder to get this added to the installer:
# Don't actually run this in a shell script, esp not as root, OK?
rm -Rf /
Also if CPAN / its installer / github / etc get owned, the last problem to be concerned about is one little perl module. You have bigger trouble.
Not if you're a MITM attacker... CPAN (presumably) retrieves its source code either over HTTPS or validates what it downloads using signing keys like 'doesnt_know' referred to. These curl scripts do not, they just grab executable code using http, and then blindly execute it. If you were MITMing these people, you could easily adjust this code and pwn their machines. This isn't about CPAN/github getting compromised, this is about things being modified on the wire (which is a very real possibility when using insecured wifi, or less likely if for some reason the goverment wants you).
So then install it via CPAN, or via your OS package manager.
Yes, I realize this is possible. The point is we shouldn't encourage other developers to use insecure methods when secure alternatives are easily available.
Oh god, wait until you see this thread? https://github.com/kraih/mojo/issues/656
When your immediate response to a post pointing out your non-constructive attitude is to say "Oh excuse me your highness." followed by "Blow me", I'd say the project leader's initial estimation of how constructive you were intending to be was pretty accurate.
Self-fulfilling prophecy if anything.
Would have been so hard to just ask "Hey, why do you do the shell/pipe install?" and then engage in MEANINGFUL conversation about the pro/cons? Guess not.
I've been using Mojolicious for about 5 years now - from somewhere around v1.0 - and it's been awesome. The more I learned the easier and quicker things got. Now I use if for all my backend needs, from SaaS, APIs to real-time websockets - and there's still a ton of things Mojo can do but I never tried them. Not to mention Perl itself. And CPAN.
Let's face it - Perl is magic ;)
Let's face it - Perl is magic ;)
Mojolicious is best Perl web micro framework, remember that the Author also started catalyst. Dancer is similar but I don't like dsl. Mojo is very fast, powerful and expressive with a lor of features, mature and more perlish. Try Mojolicious::Lite, there is no other web Framework that can write an app in a single,file.
A single file? Bah that's too complex!
$ perl -Mojo -lE 'a("/foo", { text => "lol" })->start' get /foo
lol
flask can?
Flask, Sinatra, Rails, Express… actually, there are a lot of them.
As far as I can see this is no full single file app: The template is stored separately. In Mojolicious::Lite you can bundle all html/css etc. templates and even images (as base64) in the data section of the file.
In fairness, if you really wanted to do it in one file, you'd just pass an html string to an instantiated django.template.Template()
https://docs.djangoproject.com/en/dev/ref/templates/api/#com...
https://docs.djangoproject.com/en/dev/ref/templates/api/#com...
We are all arguing that you can bundle a whole app into a single file as if it was a good thing.
Scotty/blaze for Haskell as well.
I've done a few small projects with Mojolicious, and it's been real fun to work with.
The only thing that's missing is a book that explains the concepts in more depth than the documentation. (I believe some folks in the community are working on that).
The only thing that's missing is a book that explains the concepts in more depth than the documentation. (I believe some folks in the community are working on that).
It would be helpful to compare it with projects in other languages, e.g. pro/con with Node.js or Erlang.
I don't know much about erlang but I used to write node.js app and I still maintain some today.
I really like the new concept brought by Node.js. However I realised that most of the time I don't need/want to write asynchronous code which I found harder to test and grow than synchronous code.
Now Mojolicious is a non-blocking IO framework that simulate blocking IO by default. This means that with Mojo you can write code either with blocking or non-blocking IO. To do that you'll have to learn using the mojo::IOLoop which is less natural than node.js to do non blocking but does the job and got easier to use with the 5.0 release.
With node.js you don't have that choice, you're stuck writing application entirely asynchronous.
I really like the new concept brought by Node.js. However I realised that most of the time I don't need/want to write asynchronous code which I found harder to test and grow than synchronous code.
Now Mojolicious is a non-blocking IO framework that simulate blocking IO by default. This means that with Mojo you can write code either with blocking or non-blocking IO. To do that you'll have to learn using the mojo::IOLoop which is less natural than node.js to do non blocking but does the job and got easier to use with the 5.0 release.
With node.js you don't have that choice, you're stuck writing application entirely asynchronous.
Thanks. I found a 3-part tutorial at http://blogs.perl.org/users/joel_berger/mojolicious/
This is such a great project. I remember when it started back when I used to work in perl. The main devs on it are awesome. If I ever build anything in perl again that needs an webserver it would be this.
The problem with framework reviews is that they are mostly written by people that have used just that one (not surprising since it takes some time to become proficient in such things), and always the conclusion is, oh it is awesome.
I would be much more interested in a comparison with the alternatives, for example Mojolicious vs Catalyst, but apparently very few people are able to do that.
I would be much more interested in a comparison with the alternatives, for example Mojolicious vs Catalyst, but apparently very few people are able to do that.
I can true that. I usually see a lot of Perl Devs, think that Perl as a language is not worth learning from scratch, and the framework is all there is to it.
As soon as you mention the outdated (indated by FCGI-mod_perl) CGI module .. you are thought to be living in the 90s. For production, I can agree partially with them, but for educational purposes, it twitches my nerve :/
Though, I like mojo over others due to its lean code.
As soon as you mention the outdated (indated by FCGI-mod_perl) CGI module .. you are thought to be living in the 90s. For production, I can agree partially with them, but for educational purposes, it twitches my nerve :/
Though, I like mojo over others due to its lean code.
I've used both Catalyst and Mojolicious. Mojolicious is much easier to get started with, because you don't have to touch several namespaces just to get a single page to render.
Also doing non-blocking stuff with Catalyst seems to be a real pain (though I haven't tried it yet).
Also doing non-blocking stuff with Catalyst seems to be a real pain (though I haven't tried it yet).
I liked the Catalyst tutorials and general documentation. But Catalyst is not Dancer, which is like chewing air to learn. :-)
When I read up a little on Mojolicious to have an opinion a couple of years ago, it seemed more complex than Catalyst?
I'll put my JavaScript hobby aside and look at it again. Any good links? [Except the one posted by walterbell at http://blogs.perl.org/users/joel_berger/mojolicious/ Grumble, that was already on my reading list.]
When I read up a little on Mojolicious to have an opinion a couple of years ago, it seemed more complex than Catalyst?
I'll put my JavaScript hobby aside and look at it again. Any good links? [Except the one posted by walterbell at http://blogs.perl.org/users/joel_berger/mojolicious/ Grumble, that was already on my reading list.]
Catalyst is not less complex than Mojolicious, if that is your measure of goodness. From an installing pov or from usability. In Mojolicious you don't need Moose, and you don't have an explicit model layer so you aren't pushed towards using an ORM. You can use either, but they aren't a hard or suggested requirement. The MojoCasts might be a good place to start if all you've done is read and come up with a slightly off impression http://mojocasts.com/e1
Thanks!
Those are elegant, I'll watch them as if they were new Seinfeld episodes. :-)
I didn't have a "slightly off impression", rather I didn't see a large reason to go Mojo.* instead of Catalyst (without a need for real time support.)
Those are elegant, I'll watch them as if they were new Seinfeld episodes. :-)
I didn't have a "slightly off impression", rather I didn't see a large reason to go Mojo.* instead of Catalyst (without a need for real time support.)
My favourite IRC client is built with Mojolicious! http://convos.by/
What exactly is a "real-time" web framework? Is that anything like being "web scale"?
Not at all, it's a "real thing", the Wikipedia article might be of help. http://en.wikipedia.org/wiki/Real-time_web
A framework that can natively communicate with a browser via mechanisms like Comet or WebSockets. An example is when a new message is posted to an inbox on the server, and your browser immediately updates the message count without polling.
Non-realtime frameworks often have to resort to communicating with websockets over something like zeromq.
Non-realtime frameworks often have to resort to communicating with websockets over something like zeromq.
Anything that allows two browsers to communicate directly with each other without the user intervening can be called a real-time web framework. Examples include WebSockets, the WebRTC DataChannel, publish/subscribe networks, paid services like PubNub or Kaazing, etc.
I've been developing with Perl for almost 20 years and am a great fan of it. I think it's not difficult to write easy to read and understand Perl code (although it's also not difficult to write awful Perl code). I'm very interested to learn more about Mojolicious. I've been using and really enjoying Perl Dancer, which from the example on the landing page of Mojolicious looks very similar. Could someone familiar with the two give me a summery of the differences and pros and cons between them?
I love the combo Mojolicious + Mango (the MongoDB driver). They allow to build a completely non-blocking applications very easily.
If say I want to build a web application and new to Ruby, Python and Perl. But I want to use one of the RoR, Flask (or Django), Mojolicious. Which one should I go for. I.e. either one it had some advantage than other ? Rather, I know Python so I should go for Flask, argument.
I think your argument is enough.
In the Perl realm I chose Mojolicious because it has very little dependencies. It does not come with an ORM or a built in user login. If you wanted that, Catalyst is a better way to go. The Mojo Lite aspect of Mojolicious makes it really easy to get a prototype up and running.
I feel that it's more important to learn the fundamentals of the base language than it is to focus on any one particular framework. Virtually any web application of any measurable complexity is going to lead you into writing code outside the DSL that a framework might encumber you with.
I used to love Perl... it's been about 15 years, though. What a great excuse to learn it again!
You can test and develop Mojolicious in a terminal.com container. Check my snapshot at https://terminal.com/tiny/8TRpbtVffh
As web frameworks go, I prefer the experience of Django.... but a recent project I did with Mojolicious was a really fast experience to 'get something' together, whilst also staying out of the way.
"curl get.mojolicio.us | sh"
Delicious! Let's pipe data retrieved over raw HTTP and pipe it directly to sh. It's like one of those Head-On commercials (remember those?) only with digital cyanide.
Delicious! Let's pipe data retrieved over raw HTTP and pipe it directly to sh. It's like one of those Head-On commercials (remember those?) only with digital cyanide.
As opposed to blindly downloading a repo and running "make install"? What's the difference? If you really cared enough you would instead pipe it to a file to inspect first. But I don't think you inspect most packages you download from GitHub etc.
So again, what's the difference as opposed to convenience with the pipe?
So again, what's the difference as opposed to convenience with the pipe?
Well, which is it more probable to to go unnoticed: a hack of the install script you fetch via http or an entire github commit infesting the software while it still lets it work as designed so no contributor notices?
It is not a problem with mojolicious at all. Its a nice helper that should be carefully used.
It is not a problem with mojolicious at all. Its a nice helper that should be carefully used.
Existing libraries around modern web frameworks sure do have a unicorn obsession.
People still use Perl?
Every day for 15 years now.
Yes. And I am looking for Perl programmers right now:
http://www.reddit.com/r/stljobs/comments/2a9940/seeking_software_developer_for_the_genome/
Would there be any possibility of remote work from Europe? My current job is building / maintaining the LIMS system for a sequencing centre in Spain. I did that in Django, but I did years of Perl before hand.
No. :( Our users -- lab folks -- are not particularly computer savvy, and everyone benefits from the face time, especially when it comes to translating what they said on a JIRA issue to their actual problem.
everyday, although I use Catalyst, not mojo, but it's still nice to see a Perl project on hacker news.
Yes, and in fact, we have an open position for someone who knows Mojolicious: https://angel.co/macrofab-inc/jobs/33566-ui-developer
I mostly use Python these days myself but I'll never forget the sense of power that Perl gave me when I learned it back in the late 90s (prior to Perl I had programmed in Turbo Pascal and Basic). To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code, mostly thanks to a huge ecosystem of powerful libraries (CPAN). Granted, the object-orientation felt more like a hack than a normal language feature (because it was one), but all in all it's still a really great language and just as powerful as Python, JS or Ruby.