Live data from Hacker News

Go with PHP

gowithphp.com

491–500 of 532 posts

Re: Go with PHP

#491
post #478
post #473

Earlier quoted context omitted.

PHP8 attributes are comments with a special format.

They are not. Attributes are metadata that can reflected/accessed at runtime: https://php.watch/versions/8.0/attributes

Comments can also be accessed at runtime :)

Re: Go with PHP

#492

Earlier quoted context omitted.

Correct. I had a use case where I needed to run an app on 30,000+ servers and the app would be updated regularly with new features. I wasn't going to use PHP for that because it would involve not only copying the PHP binary around (and maintaining that version), but also my own app code. golang ended up being a perfect solution because I could cut the binary down to about 3-4 megs with compression and build flags. Mo…

PHP has a way to compile entire applications into single files, for what it's worth. You can compile it all in your CI/CD and then push the PHAR file to all the servers (instead of the thousands of regular files). I don't know if it accomplishes everything you're after, but it's been a PHP feature for over a decade. https://www.php.net/manual/en/intro.phar.php

As the op said: "There are tools for creating stand-alone executables from PHP source code, but they're not as nice to use, compared to languages that were designed for this."

Re: Go with PHP

#493
post #445

Earlier quoted context omitted.

It sounds like you haven't touched PHP in a very long time. Your comment reads like a 2015 forum complaint - which, to your credit, certainly would have been all valid points 8 years ago. The language has evolved since. The ecosystem has evolved since. Most of the things you're complaining about are solved paradigms that no one does manually anymore unless they're trying to drastically improve on ecosystem tooling. E…

You've made a lot of claims here without providing evidence. Care to post some links like I did?

Sure.

1. SQLC is little more than a template generator for Prepared Statements wrapped in a class. [https://www.php.net/manual/en/mysqli.quickstart.prepared-sta...]. It's not exactly a mind bending or time saving tool.

2. There are multiple OpenAPI generators for PHP, in fact, they existed from nearly the start of the OpenAPI protocol (formerly Swagger) when Go was barely a year old. Here's a current popular one: https://openapi-generator.tech/docs/generators/php/]

3. PHP also, (unsurprisingly given the origination point of the spec) has many GraphQL implementations that support any database driver over ODBC, key-value stores, or even flat files. Here's one that plugs into Laravel [https://lighthouse-php.com/]

4. PHP has many mature, modern embedded KV store options... but it's also had one in the standard lib since years before Go even existed, or the concept of KV stores was even popular. [https://www.php.net/manual/en/class.splobjectstorage.php].

On your non-numbered points...

Go and PHP are fairly similar in raw processing speed since the JIT was added to PHP. However raw number crunching is rarely realistic when most applications are going to be using databases, stores, etc. So why not look at a benchmark of popular frameworks in both languages - which shows, again that the two are fairly similar in performance. [https://www.techempower.com/benchmarks/#section=data-r21&l=z...]

PHP has also had types for about 4 years now. It's not statically typed, but that's a preference, not a pro/con situation.

Built-in formatting is also a preference, not a pro/con situation. Many developers strongly dislike languages like Go and Python for this.

PHP has had one of the most powerful and useful package management ecosystems in the entire open source world since composer mostly replaced PEAR nearly a decade ago. It also has mature and well loved testing tooling. Neither of which are built in, because why would you need to build in tools that the community already creates and maintains for free?

I don't know what "bugs" you faced in the PHP stdlib, but I will concede that it is painful to use. Most of the stdlib is little more than a wrapper around C functions of the same name, and they inherit the frustration of using those C functions.

Laravel does allow you to write things by hand. You can also just define them ahead of time and have the Migrations, Models, Controllers, Views, Transformers and more generated for you automatically. [https://blueprint.laravelshift.com/]

There you go, there's your links. But frankly, you didn't need them. There's little you mentioned that's unique to Go at all, you just named a bunch of things that have become popular tools for most modern languages still being actively developed. I'm not sure why you think any of these things are Go-specific - some of them are maintained by the Go core team, like other newer languages have started doing, but that's it.

Re: Go with PHP

#494

Earlier quoted context omitted.

Hi! I'm looking for advice on how Rails vs Laravel compare (as I'll have to pick one of them soon for a project). Assuming the same knowledge and familiarity on both of them, why would you prefer Rails over Laravel? Thanks!

The reason why I stuck with Rails is because I am already a Ruby user. I like PHP and all but I am way more comfortable with Ruby. I don’t think there is anything Rails can do that Laravel cannot and wise versa. It’s about taste. I think Rails + hotwire hit the sweetspot for me!

In general I think there’s something to be said for sticking with languages that match your model of approaching a problem. DHH gave a good, albeit a bit rambly, keynote on this topic once. He compared some of the tools selection conversations to the equivalent of people comparing gaming consoles purely by specs when in reality, picking a console mostly boiled down to what you subjectively enjoyed more. I like that idea as a rule of thumb and encourage people to start there and go with what feels right for them before making deeper choices. (Lots of nuance here, don’t want to delve too deep so please view from that context :) )

Re: Go with PHP

#495

Earlier quoted context omitted.

FWIW: There are a bunch of ways to "do" php execution, and a lot of them are wrong. That's not exactly PHP's fault, just that there's been a lot of blind-leading-the-blind. Assuming that you're not spinning up and tearing down a container for every request, you want to be sure you're running php with a php-fpm configuration (preferably talking over a unix socket) -- this is the fastcgi process manager, which maintain…

My experience is that Symfony, in its fat, batteries-included form, does take quite long time to initialize on cold caches. The first request can take hundreds of milliseconds but usually the very next request is in the normal 10ms range. This is especially noticeable on (cheap) shared hosting which has always been a common place to run PHP. I've never found it to be a problem on a VPS but if you're developing on som…

IIRC back in symfony 1 part of it was becasue symfony used the first request to write optimized versions of the code into a folder that I cannot remember the name of.

I think there was a way to do this up front in Symfony 1 and there might be some way to do this as part of a build and deploy step. Of course on applications with less traffic and less strict requirements just hooking something up to run a request immediately after deploy might work just as well, but if it runs across n small pods it might be a much better idea to do it on a beefy build machine instead of on n resource constrained pods causing slow loading for n customers.

Re: Go with PHP

#496
post #232

Earlier quoted context omitted.

> Oh and some still argue over setters and getters. Serious question, what does that argument consist of ?

Whether to use them or not. Petty endless debates over their benefits and drawbacks. Literarily for as long as i worked with php devs in all teams there was someone debating this pattern. As php is not strongly typed these can help with data type validation, can perform some logic when setting values, while others say it’s inefficient as thats an unnecessary method call, or that no logic should be performed in them.…

class variables can be typed now though, so the data type validation argument doesn't hold at least for basic type system validation

Re: Go with PHP

#497
post #317

Earlier quoted context omitted.

I am afraid that if you think that then there is no help.

Umm... are you serious? I could believe you perhaps with your criticism but then you say this is the future of web design? The site you held up as the example I should emulate feels like some kind of terminal from the 80s movie "Hackers"... are we "hacking the gibson"? It features white text on a black background, overlaid on animated white text on a black background... Then you scroll down, and it has TEXT IN A GIAN…

You cant take this stuff personally. I think people just try to help. I dont think payloadCMS site is some kind of incredible achievment but its very well done site in line what developers are used to. Qbix website in my opinio has so many issues it is hard to point out which one to fix and how. Sorry but i think is simply a mess. There is too much information crammed together, to many various elements that dont really fit together and it makes is for anyone that visits the site really harder than it needs to be.

But what i meant is that with that defensive approach you have… it is going to be tough to make it better.

Re: Go with PHP

#498
post #292

Earlier quoted context omitted.

> magic framework stuff that Laravel/Symphony provide The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.

I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses

Sure, but it does exist frameworks that uses minimal amount of magic.

It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.

Re: Go with PHP

#499
post #479

Why do most PHP related posts on HN read like repentance ? If you want to promote the language -to the point of buying a domain and making a webpage-, please show interesting stuff, not something that is equally trivial to solve in gazillions of web frameworks written in gazillions of languages.

I don’t get that feeling. And I like that people are doing their best to try to improve the reputation of the language. The reality is that modern php is very decent, but a lot of people that have never used it or have used a very old version mock or look down upon it for no apparent reason. It’s important to try to improve the reputation so that it gets new developers interested in it in order for the language to ke…

You just prove my point... you start your post with something that reads like "it's decent now, please look at PHP again". But:

    - you make bold claims about PHP OO
    - you make downright false points about other languages
    - you nitpick things that are non-issues in other languages
All in all, nothing in your post really seals the deal about PHP. It's not about mocking or looking down on PHP for no apparent reason. I'm pretty sure most of us on HN have used it already and most of us have followed its development. I sure did. And every time a new version comes out, I welcome the improvements although it's just mostly catching up with the competition. So what compelling reason do I have to use it again in 2023 for greenfield projects ? None. It used to be "the web specialist", but now all platforms have great web frameworks along their distinctive features.

Re: Go with PHP

#500

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…

Laravel focus a lot on branding & communication to create a hype by overselling their functionality, you are a "Web artisan" when using it, the ORM is not like other ORMs, it is an Eloquent ORM etc.
Post reply on HN