Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

151–160 of 371 posts

Re: Moving from Go to PHP Again

#151
post #71
post #67

Earlier quoted context omitted.

What's the equivalent of === for in PHP?

Use for numbers and strcmp for strings. A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?

>A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?

Yes, which would make it behave exactly like probably every language with strong runtime typechecks. Very weird indeed. It's obviously much more preferable that the code sometimes does the wrong thing without warning.

And of course with static typing, it would be extremely weird since the code wouldn't even pass the compiler!

Re: Moving from Go to PHP Again

#152
post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

>Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. This doesn’t seem to be a language choice problem, it seems to be a monolith problem, where PHP simply managed to avoid some of the traditional monolith issues by design. Your CD pipelines in any micro service architecture should solve these problems, whether it’s using FaaS or containers,…

>> PHP simply managed to avoid some of the traditional monolith issues by design

No - it didn't. PHP up to this day is a spaghetti mess it had always been.

Re: Moving from Go to PHP Again

#153

Earlier quoted context omitted.

Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes. I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd. But after 20 years of bouncing around start…

You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire…

Suggesting to just manually go in and change the touchpoints over if the time comes is seen as uncouth, as if we're in an Oscar Wilde play and I'm some unwashed ruffian from the alley.

This is despite the fact that if you do it it'll take 40 minutes manually versus 10 minutes if the Rube Goldberg abstraction machine works as planned (it won't).

Since there's only about a 5% chance (max) that going from say S3 to Azure will ever happen, the extra cathedral of abstraction saves an actuarial 1.5min of dev time.

All that only for 2-4 days of development to make it and the added runtime at every request for the convenience. Genius!

Re: Moving from Go to PHP Again

#155

Earlier quoted context omitted.

These are things very specific to PHP. Yes, there are language-specific gotchas in many environments. But I'm criticising specific things that do exist and that I've seen causing issues in real deployments. Things that make PHP accessible make it also an excellent footgun.

These things are very generic and apply to both lua and asp. Invisible characters are a problem in every language, configuration file, file period, trying to suggest that its specific to php is just silly.

The difference is in handling though. If a config file runs into a BOM, it's likely to tell you on which column and row (0,1) it broke. Same when you compile something. Or it may even recognise the BOM and handle it transparently.

PHP does something different. It outputs it early and when you try to send a header it tells you that's too late. That error is in no way helpful to you at that point unless you already know about this issue, and it won't even help you figure out which file was affected. That part is specific to PHP.

I'm not familiar with Lua pages, but all I can find uses a http / fastcgi server with explicit routing. ASP classic has its own terrible ideas and it's close to death now - 2025 is the last year MS committed to support it, so I don't really think of it as an interesting language anymore.

Re: Moving from Go to PHP Again

#156
post #121

Earlier quoted context omitted.

> Incompetent people will create incompetent things regardless of the tool. I think I'm justified in calling myself competent. Nevertheless, with the wrong tools, the things I build are definitely worse than the things I can build with proper tools.

You've never had the reaction of "what on Earth is this crap doing?" And looked at the tool and been like "omg what kind of flunkie wrote this" and then end up forking the project, doing negative coding, fixing the issues, and then having to address the issues threads on GitHub yourself because the "maintainer" stopped responding a year ago? I mean it's just a huge waste of time. These modern stacks (mostly js) are c…

Hmm, I'm sorry... I'm having trouble understanding your point, and specifically how it relates to my comment.

Re: Moving from Go to PHP Again

#157
post #133

Earlier quoted context omitted.

As someone who was about to ditch the PHP ecosystem 6 years ago for something like Rails... frameworks like Laravel absolutely changed the PHP ecosystem. Also since the release of PHP 7.0, core development seems to have really picked up with good stuff in every release (7.3 was just released a few months ago).

I just do not understand the fascination with Laravel. When the first version of Laravel was released Symfony was already lightyears ahead. The only thing Laravel had going for it was that you could take more shortcuts, and it was a pain to integrate into any IDE if you wanted decent autocompletion.

I haven't touched symphony from 1.2 but laravel was a lot simpler to use, especially for begginers. no stupid yaml files, the need to definine everything in yaml before. simpler orm and so on.

Re: Moving from Go to PHP Again

#158
post #38

Earlier quoted context omitted.

Symfony and Laravel are really nice. It's still a horrible abomination of a language that invites bugs and requires A LOT of care to not produce buggy code, though.

Does it? If you declare strict, use strict comparison operators and typehint your arguments and returns, what more care do you need? These are not particularly onerous, the strict declaration is trivially templateable in any editor as it's the first line, you'd write types in any language and getting used to only use === !== and forget == and != is ... easy?

> what more care do you need?

1. Generic typehints, for one. Typehinting half the methods as returning a generic `array` is not fun.

2. And that's before you even remember that PHP's array is both a vector and a hashmap, so you need to install a PECL extension or a third-party library to get proper Map/Sequence/etc.

Re: Moving from Go to PHP Again

#159
post #156

Earlier quoted context omitted.

You've never had the reaction of "what on Earth is this crap doing?" And looked at the tool and been like "omg what kind of flunkie wrote this" and then end up forking the project, doing negative coding, fixing the issues, and then having to address the issues threads on GitHub yourself because the "maintainer" stopped responding a year ago? I mean it's just a huge waste of time. These modern stacks (mostly js) are c…

Hmm, I'm sorry... I'm having trouble understanding your point, and specifically how it relates to my comment.

I parsed it wrong. I thought you essentially said "the things I build are definitely worse then relying on a collection of random internet dudes code through npm." But yes, GNU make, emacs, yacc, lex, bison, ar, nm, there's lots of great tools.

It's 4am, I should sleep.

Re: Moving from Go to PHP Again

#160

Earlier quoted context omitted.

With PHP it is much easier to hit all of the above.

PHP is also easier to get started, easier to understand and easier to modify. So it's a trade off.

> PHP is also easier to get started, easier to understand and easier to modify. So it's a trade off.

And as a result also easier to achieve proficiency in.

Post reply on HN