Live data from Hacker News

Go with PHP

gowithphp.com

431–440 of 532 posts

Re: Go with PHP

#431
I built and maintained open source frameworks in both. I left PHP for Go.

1. with http://sqlc.dev I don't have to write ORM or model code anymore. Define all your SQL in an easy to audit file and all your models and interfaces are generated for you.

2. with http://goa.design I can have well-documented OpenAPI API's that any team can generate a client for in any language. It also generates the HTTP JSON and gRPC clients/servers for me so I can focus on my logic.

3. with https://github.com/99designs/gqlgen I can define GraphQL revolvers that play well with sqlc (any RDBMS) or I can use a key-value store.

4. speaking of key-value stores, Go allows them to be embedded! Even SQLite now has the https://litestream.io/ project to make it super simple to use a durable, always backed-up SQLite database even in a serverless context.

Go is faster, uses less memory, uses types, has built-in formatting, package management, benchmarking and testing. Go supports multiple cores in the same process, and has really-well designed stdlib without all the bugs I used to face trying to use the PHP stdlib.

After writing millions of lines of PHP for years, there is nothing I miss anymore. Laravel still wants me to write models, controllers and views by hand and make all the client changes as by-hand code refactors.

Go lets me focus on the actual logic instead of waste my time in PHP writing all the implementation details like controller requests handlers, db fetching logic, and input validation.

Re: Go with PHP

#432
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.

> The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Have you actually used Symfony? It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.

I have, though I admit it's been about 10 years since and my memory may be mixing in (pun intended) things from version 1.

Re: Go with PHP

#433
There's a lot of reasons to both use or not use PHP, but of all the ecosystems I've developed in, PHP has the most lovely dev tooling.

Every popular piece of dev tooling in the PHP ecosystem feels like it was made to solve a problem, do so as simply as possible and let you know all the information as cleanly as possible.

There's contemporaries to most of those tools in every other major language, and all of them have problems or annoyances that I feel simply don't exist in PHP's tools.

Re: Go with PHP

#434
post #212

> There is no need to compile anything. But I really like compilers, they catch a whole class of bugs, before I run things.

The compilation step, and the resulting binary, is also very useful if you need to distribute your software. As opposed to creating a ZIP file. 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. By distributing software I also mean making your latest code live in prod. I suppose the benefit of using PHP (or othe…

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. More importantly, it was just one thing to install and maintain.

Re: Go with PHP

#435

    $request->user()->orders->create($request->validated());
This looks so wrong from an architectural point of view! A request has a user (which in the context of HTTP should be more or less only an authenticated principal), which has orders, which are created from the same request, where the journey started. There is no separation of technical and business concerns.

See: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...

Re: Go with PHP

#436

Earlier quoted context omitted.

I guess I wasn't clear enough? I said "it makes complex tasks SEEM". My point being, they SEEM SIMPLE in a DEMO. But in real application it quickly turns into a quagmire, due to the problems I already listed. Oh look, you even say so in your own comment: "the specific code sample shown on this page shouldn't be treated as a practical example". So... you're saying the page makes it SEEM simpler than IT IS, hmm? Is thi…

I have one name for you: Symfony More or less directly opposite of what Laravel is preaching. It's the popular choice for anything that is being build long term. It is very popular in Europe and we have a far bigger community around it than Laravel does.

Symfony made many architectural mistakes early on, including with the way they used to do injection and so on, but to their credit, the community seems curious and strives for quality, so over time it has become a very interesting project. I stay away from frameworks, in general, but the Symfony components are excellent.

Re: Go with PHP

#437
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…

This 100%. It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP. The language has matured a lot and building stuff with it is simple, cheap, straightforward and fast. If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for th…

Ditto for any language. I think it is a good sign for someone to recognize the trade-offs a language makes, or even accept that they can complain about it while acknowledging they don’t understand the trade-offs.

But when a dev says X is objectively bad, that is not a good sign. Languages are tools, not a way of life.

Re: Go with PHP

#438
post #35

Earlier quoted context omitted.

Thus is why I wish titles quoted names, at least where is there is any possibility of confusion

Not sure how quotes would help? If referring to the go programming language, the title should say "golang with PHP" There is no other way to disambiguate one of the most commonly used English verb from the obscure (in relative terms) programming language.

> Go with "PHP"

And articles referring to Golang could read

> Go with "Go"

Re: Go with PHP

#439
post #171
post #122

Earlier quoted context omitted.

> The documentation reads like a tutorial, which is fine the first time you read it, and really annoying the next 99 times when you're just trying to find something. Ah yes, the Ansible approach. I've used it for a decade, and I routinely get lost in its utterly terrible by-example documentation. They are the golden standard on how not to write documentation. God, I hate the Ansible docs so much, they are the reason…

I think more documentation teams need to know of the concept of Diataxis [1] so they can invest in the 4 different kinds of documentation developers turn to for help when picking up a new technology: - tutorials; - how-to guides; - technical reference and; - explanation. 1: https://diataxis.fr

Thanks for this. This is something I kind of knew but would have been hard pressed to articulate, especially on the spot. Seeing it laid out like this is very useful.

Re: Go with PHP

#440
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…

I hold a center position on this. I think PHP is great for a lot of things (especially these days). I even agree about Swift. Love that lang.

But for web, I personally prefer Typescript frontend and backend combos. It's amazing to be able to write everything in one language. I largely tune out the arguments and new flashy frameworks, but I get why people call the JS ecosystem a hellhole. There are a lot of options out there. That being said, when your team is competent and balances functionality with new shiny stuff, it can be a real treat to have access to npm for frontend and backend.

Post reply on HN