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

Lumen – A micro-framework by Laravel

laravel-news.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: Lumen – A micro-framework by Laravel

#51

Post by conradfr »

xrstf wrote: post #37
wesray wrote: post #7

The drop in functionality right into the full framework is fantastic. Really like the ability to write API's with much less overhead, which was a factor that came into play for me recently. Nicely done Mr. Otwell.

The same holds true for Silex[1], the Symfony Components-based micro framework. Silex and Lumen look very similar (not only because Laraval/Lumen use Sf Components as well), not only because both use (just as Laravel) Sf Components. Slim 3 seems to move in the same direction of modern PHP frameworks, where you return a response from your controller, instead of setting up some global state (the main thing I don't like…

I've done some projects with Silex and it's not bad but I've found myself losing quit a bit of time because you can never really use most components exactly like in the Symfony standard distribution but the docs mostly show you that way.

Also you have to be careful with dependencies version or you're quickly in Composer hell (because Symfony moves forward so fast).

Always wanted to compare it with Slim but didn't take the time.

Re: Lumen – A micro-framework by Laravel

#52

Post by jonkiddy »

mmmm wrote: post #28
sergiotapia wrote: post #26

How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP. Has the experience remained the same? PHP was incredibly simple to deploy.

Yes, and even more so with https://envoyer.io/ - according to the website a Laravel product.

How is this different from Laravel Forge? https://forge.laravel.com/

Re: Lumen – A micro-framework by Laravel

#53

Post by scott_karana »

xorcist wrote: post #44
vectorpush wrote: post #35

Earlier quoted context omitted.

> I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more…

PHP the runtime was built with a reload on every page load in mind, so a lot of cleaning up simply didn't need to happen. If it's in the runtime or how it's used doesn't matter. It was a big deal when transitioning to the FPM runtime. That's why persistent PHP runtimes like FPM still have the option to completely reinitialize itself after a set number of pageviews. It's a bit like fixing leaks by rebooting, but it's…

Admittedly, the "restart server process after N connections" method of dealing with memory leaks is not specific to just PHP.

It's also present in Apache, and thus mod_rails and mod_wsgi, by default[1], is an option in Gunicorn[2], and a gem is also available to provide the same in Unicorn.[3]

1 http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequ...

2 http://gunicorn-docs.readthedocs.org/en/latest/settings.html...

3 https://github.com/kzk/unicorn-worker-killer

Re: Lumen – A micro-framework by Laravel

#54

Post by darkstar999 »

cweagans wrote: post #36
sergiotapia wrote: post #26

How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP. Has the experience remained the same? PHP was incredibly simple to deploy.

Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.

You mean that you think it's not hip to use FTP? Because people definitely still do this.

Re: Lumen – A micro-framework by Laravel

#55

Post by Dasuchin »

cweagans wrote: post #36
sergiotapia wrote: post #26

How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP. Has the experience remained the same? PHP was incredibly simple to deploy.

Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.

I wish I could say that's true, but it's not.

Re: Lumen – A micro-framework by Laravel

#56

Post by giaour »

JimmaDaRustla wrote: post #50

They compare it to Slim 3, which isn't completed yet, sitting in a development branch... Slim 3 will also be PSR-7 compliant, I don't see anything about that anywhere in these Lumen docs.

The framework's author addressed this on reddit: http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microf...

Re: Lumen – A micro-framework by Laravel

#57

Post by deweller »

conradfr wrote: post #49
smt88 wrote: post #38

Earlier quoted context omitted.

I wouldn't be surprised if those memory leaks were due to an older version of PHP (GC was recently improved a lot to clean up circular references) or a poorly-written framework, which most of them are. Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. I've used PHP a few times in the past…

> Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory. IIRC arrays are always passed by reference and only duplicated if you modify the data inside the called function (if not passed with '&' of course) ?

Correct. The runtime uses a copy-on-write implementation when you pass an array by value.

Duplicating an array in memory every time it is passed to or from a function would be awful.

Re: Lumen – A micro-framework by Laravel

#58

Post by vectorpush »

pyre wrote: post #42
vectorpush wrote: post #35

Earlier quoted context omitted.

> I've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more…

> What does it mean for a language to have memory leaks? I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. Seeing as for a long time there was a single runtime paired with the language (I'm 99% sure that PHP4 didn't have alternate runtimes), I think that equating bugs in the runtime with bugs in the langua…

> I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced.

So are you talking about the default PHP 4 runtime or the default PHP 5.3 runtime or the default PHP 5.4 runtime etc? These versions are very different beasts, so levying a vague "memory leak" criticism at PHP without substantiating it via code or even a version makes the criticism pretty meaningless.

> I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things.

I asked for clarification because I was unsure what you were referring to. For example, about a month ago I was tasked with debugging a memory leak in a legacy Ruby application where I eventually discovered that the developer had used a proc in such a way that it prevented the GC from freeing variables that had been referenced in the closure. It was an issue somewhat similar to the examples described in this blog post:

http://victorarias.com.br/2013/08/13/leaky-ruby.html

I wouldn't attribute this memory leak to the Ruby langauge but more to a Ruby idiom that developers should take care to avoid. That's the type of clarification I'm looking for, but it appears that you don't really have anything to offer the discussion in this regard.

> And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks.

I have no emotions tied up in this discussion, I'm trying to make a point that your criticism is just anecdotal hearsay without any way for someone to verify if what you're saying is actually true. I didn't suggest that you ask your colleagues to file bug reports, I was simply pressing you for more details since your vague anecdote runs counter to my own experiences with PHP as I relate it to the rest of the imperative scripting landscape.

> Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap

Yes, that is pretty much the definition of "devoid of substance". "In the trenches" is a subjective description that doesn't mean anything. You presume they know what they're talking about, but maybe they actually don't, but we'll never know either way because all you've done is recount nebulous secondhand generalizations. You're not even asking me to take your word for it, you're asking me to take your word for their word. Can't you see why that's a little dubious?

Re: Lumen – A micro-framework by Laravel

#60

Post by hising »

hising wrote: post #8

Looks nice, I really like Slim Framework, this looks a lot like Slim from what I could tell. Gonna be interesting to see how (if at all) this will effect some performance focus from the Slim developers.

Official blog post on Lumen on the Slim Framework website:

http://www.slimframework.com/2015/04/14/lumen.html

Post reply on HN