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

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

101–110 of 532 posts

Re: Go with PHP

#101

Post by myspy »

naiv wrote: post #82
acherion wrote: post #51

Earlier quoted context omitted.

> Laravel is [...] reasonably well documented Hard disagree. Sorry, I don't have a computer science degree, why does their documentation make that assumption. I find their docs very hard to grok. PHP.net docs are no-frills no-fuss, straight to the point. Other frameworks are documented very well too, CakePHP comes to mind (at least, when I was using it last in v2 and v3). I can't say I've read the absolute latest ver…

The documentation for Laravel is still unreadable. Guess that is why selling Laravel tutorials seems to be a fruitful business.

But why? I‘m working with it daily and what I learned is to read the docs properly. Usually it‘s me not reading correctly. There is some advanced stuff that‘s not covered in the docs, but not necessary to build an app.

Re: Go with PHP

#103

Post by kaba0 »

keyle wrote: post #17

As a fullstack developer who has worked many, many years in the javascript hellhole, I mean ecosystem, as well as the python ecosystem and .NET; coming back to PHP the last 2 years, working essentially in Laravel and the like - I couldn't approve more of this message. Seriously, PHP is the grand father that will drive you to class and you'll never be late, the car will never smell and everything will always just be f…

Agree, though I would put Java in the same category as well (and actually prefer that). Great ecosystem, great frameworks for every conceivable business case, excellent performance, tooling.

Re: Go with PHP

#104

Post by thomasfromcdnjs »

PrimeMcFly wrote: post #16

I see no argument at all for using Laravel over Django or Rails. PHP was always a mess. Why would I want to come back to it now on the off chance they don't screw things up again?

Exactly.

array_filter and array_map, have different order of arguments.

($array, $callback) vs ($callback, $array)

A small example of how inconsistent the language is from the ground up.

Most people can explain their respective web servers, but I've never heard anyone even come close to what PHP/Laravel is actually "doing".

Side Complaint: If you are working with Laravel Queue, it is such a hassle to reload your code changes when developing.

Re: Go with PHP

#105

Post by kgeist »

berkle4455 wrote: post #83
kgeist wrote: post #57

Earlier quoted context omitted.

I agree, the main problem with PHP in my experience so far has been that it's very memory-hungry and slow (even PHP7/8), especially when coupled with frameworks/ORM magic. I remember after spending some time with Go, I got used to being able to process tens of thousands objects in memory in milliseconds. When I proposed to do the same in PHP, during architecture review, PHP devs thought I'm out of my mind because tha…

You're doing something terribly wrong. Sounds like caching isn't setup and your http -> php handler is cold booting the interpreter for every single request. Check these Go vs. PHP benchmarks. PHP is quite fast and stands up nicely to the performance you get out of Go. https://www.techempower.com/benchmarks/#section=data-r21&l=z...

Isn't that synthetic benchmarks for toy projects? The amount of code which is run on every request grows with the size of the project in PHP/Symfony (which can take quite some time in a huge monolith), while in Go, everything is usually initialized once at startup.

Re: Go with PHP

#106

Post by devjab »

keyle wrote: post #17

As a fullstack developer who has worked many, many years in the javascript hellhole, I mean ecosystem, as well as the python ecosystem and .NET; coming back to PHP the last 2 years, working essentially in Laravel and the like - I couldn't approve more of this message. Seriously, PHP is the grand father that will drive you to class and you'll never be late, the car will never smell and everything will always just be f…

PHP has been a great language for a while, essentially since the world of enterprise became web based instead of application based. I suspect it’s not seeing too much adoption because it wasn’t always great, partly because a lot of enterprise is married to Java (which is frankly also in a decent state) and because JavaScript (with types) and Python lets your teams do a single language while also doing a react client or a lot of BI/ML.

Most mature programming languages are nice to work with these days though. At least in my opinion. About the only one I dislike is C#, and that is mostly because whenever I need to use C# I need to use it with a combination of libraries (Odata, Entity Framework, Asp.versioning) as an example which simply don’t work together unless you overwrite/extend half of them. Because for most use cases C# is as excellent as all the rest.

But PHP was essentially build for the modern use case of everything being web-based and it’s weird to see the reputation it still has. Then again, django is also an excellent tool for most modern work that doesn’t see the adoption it should. I’m so sick and tired of having to deal with things like umbraco failing at things that have been a fundamental part of django for longer than some of the people reading this post have been alive. :p

But I guess its all those things that keep me well paid. So maybe I shouldn’t be too angry about it.

Re: Go with PHP

#107

Post by kaba0 »

keyle wrote: post #36
nstart wrote: post #23

Earlier quoted context omitted.

There's javascript in the back. And there's javascript in the front. Curious what you use for application development on the frontend and if you have some recommendations for that? Thanks in advance!

Most of the stuff we do now we do with "Laravel Livewire". It's quite brilliant really, even for modals etc. "look ma, no javascript!". Of course it does JS for you, you just don't see it. That's my favourite kind of Javascript - someone else's problem. Livewire is a mid-way between front-end backend, it's a progressive back-end with long polling like NextJS I suppose. From your end though, it takes care of all the s…

> it's a progressive back-end with long polling like NextJS I suppose

It’s kind of funny that this is the new best thing, when this is almost the same model JSF did decades ago.

Re: Go with PHP

#108

Post by ofrzeta »

acherion wrote: post #99
dotancohen wrote: post #80

Earlier quoted context omitted.

What "computer science terms" did you encounter, that you did not understand? I also do not have a CS degree, but every term that I've encountered in the Laravel docs I found easy to search for. Just don't rely on Wikipedia for explanations, for CS (and mathematics) subjects Wikipedia seems to be useful only to those already versed in the field.

I struggled with sorting out Contracts vs Facades vs Traits. I graduated from university 20 years ago with a software engineering degree, where it was drummed into me that simpler often is better, and much more robust. Reading the Laravel docs however, leaves more questions than I started off with. eg. https://laravel.com/docs/5.8/contracts – talks a lot about how Contracts are powerful additions (like all the other…

The project is in a constant state of flux. So for example the Contracts you cited are in version 5.8 but they are no longer in the current versions.

EDIT: I just noticed that Contracts are still in the current version just got moved in the docs, so I your point still stands.

Re: Go with PHP

#109

Post by athrun »

zdragnar wrote: post #76
sockgrant wrote: post #37

Earlier quoted context omitted.

Gotta love engineers. 45 minutes of reading 12 years of someone’s work and the first thing they say is “yeah I’d rewrite it”. Every. Dang. Engineer. It’s crazy. I try to work in a codebase for 3-6 months before coming to any wild conclusions. Usually you find that there’s some warts but it does the job and there’s complexity that was solved that you hadn’t originally noticed, and it’s not worth rewriting it just need…

A clean rewrite is almost always going to produce better code than what already exists in a project that has grown organically. The current project has had numerous iterations on requirements over the years, changes in project leadership, paradigm fads come and go, and all that time accumulating cruft and layers. Looking at it at a single moment in time, you have a fixed set of current requirements where all the disc…

Ideally, you want people deeply familiar with the original codebase doing the rewrite.

What usually happens instead is that the rewrite happens because the original code has been handed off to a new set of people. They're not deeply familiar with the code. It's confusing to them. It's not obvious why things have been done in a specific way. And so they decide rewriting it from scratch is the better option.

Unfortunately, they're not in the best position to come up with a solution that incorporates the right lessons from the original design.

Re: Go with PHP

#110

Post by acherion »

ofrzeta wrote: post #108
acherion wrote: post #99

Earlier quoted context omitted.

I struggled with sorting out Contracts vs Facades vs Traits. I graduated from university 20 years ago with a software engineering degree, where it was drummed into me that simpler often is better, and much more robust. Reading the Laravel docs however, leaves more questions than I started off with. eg. https://laravel.com/docs/5.8/contracts – talks a lot about how Contracts are powerful additions (like all the other…

The project is in a constant state of flux. So for example the Contracts you cited are in version 5.8 but they are no longer in the current versions. EDIT: I just noticed that Contracts are still in the current version just got moved in the docs, so I your point still stands.

Right, but this is a discussion about their documentation, not whether Feature X in a version of Laravel is still around in the latest version. I'm not attacking the framework, as I said I love using Laravel. I just have criticism about their documentation.
Post reply on HN