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

Moving from Go to PHP Again

dannyvankooten.com

Post reply on HN
Print view View original

121–130 of 371 posts

Re: Moving from Go to PHP Again

#121

Post by Vinnl »

kristopolous wrote: post #113
coldtea wrote: post #94

Earlier quoted context omitted.

Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it co…

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…

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

Re: Moving from Go to PHP Again

#122

Post by andai »

mikl wrote: post #111
trixie_ wrote: 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…

This is pretty much a laundry list of anti-patterns for modern web development. Non-atomic deployments? Not using Composer to manage dependencies? No separation of concerns? Editing files directly on the production environment? I get that it's nice for beginners, but they're not benefits for professionals. We have better ways of doing things than Notepad and FTP.

vim and scp?

Re: Moving from Go to PHP Again

#123

Post by kristopolous »

coldtea wrote: post #118
kristopolous wrote: post #113

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…

> Incompetent people will create incompetent things regardless of the tool Which is neither here nor there. For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them. If only it was just "incompetent p…

Those mistakes aren't easy to spot or easy to fix.

It's about giving code sunlight so that action at a distance and other kinds of magic don't hide errors making them harder to find, get in your way of fixing them, making reproducibility a mess and confirmation simply guesswork.

Its the restrictive design trend of crippling languages which needlessly prevents the sunlight effect from happening along with "information hiding principle" gone completely amuck with the information successfully hidden in dozens of innocently named files with listeners, observers, watchers, triggers and who knows what else being mysteriously called based on reflective programming so not even grep will help you.

Static code analysis and seamless navigation is totally a thing of the past.

Instead, the errors will have the stack of the error handler and that's it. The debugger is useless because stepping through the code is 98% scaffolding.

All these fancy tools bludgeoning any introspection or diagnostic system so the only remaining workable debug system is printing debug variables and rerunning the code like I'm programming on a TI-81 (only that had debug and release run modes...features I can usually only dream of these days) Progress! Welcome to 2019!

It's crazy. This isn't how maintainable code is written

Re: Moving from Go to PHP Again

#124

Post by superasn »

pasta wrote: post #68

I agree with the author. Symfony 4 is the best PHP framework at the moment. Trying both Laravel and Symfony I think there is no need for Laravel (anymore). Laravel just has too much magic that will bite you later on. The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.

You are 100% right about that. I've nearly tried almost all PHP frameworks, quite extensively I may add and at the end of the day I found that the less framework I use the better and faster my dev is. Now I just use packages from composer as needed and never ever use them anymore.

For me Laravel was a nightmare to use with Vue. Both template engines (blade, vue) use moustache tags so everything has to be declared inside @vetbatim. Then mix doesn't even compare to ease of vue cli imo. Then the nested directory structure was so confusing (was it inside resource folder, or controller folder). I've never been happier since I ditched these opinionated frameworks

Re: Moving from Go to PHP Again

#125

Post by atsjie »

Oras wrote: post #117
atsjie wrote: post #103

Earlier quoted context omitted.

No. And there alternatives. The best known is probably Revel: https://revel.github.io For a doctrine (ORM) alternative you have for example https://github.com/jinzhu/gorm The point about Go; using those types of tools is generally frowned upon in the community. It's overkill for most (micro)services. But few gophers build a full-stack website in a single application. I'm a gopher; I wouldn't want to use Revel or Gorm…

Gorm is not bad but I don't think it is an alternative. To start with, the association requires some extra work to save/update which you have to do manually. In doctrine, this is done already. Documentation, maturity, and community behind doctrine are a lot better.

Funny this, +/- 6 years ago when I last worked with Doctrine I had the same feeling about Doctrine itself. I thought it was a poor replacement compared to Hibernate / JPA.

I'm getting old ;)

Obviously things will have matured since then.

Doctrine implements the Unit of Work pattern. From what you're saying GORM is more like an Active Record ORM.

You're right, that wouldn't make it a good direct alternative.

Re: Moving from Go to PHP Again

#126

Post by kristopolous »

Vinnl wrote: post #121
kristopolous wrote: post #113

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…

> 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 crap code all the way down.

It's made me want to return to Perl because honestly, it has everything and is somehow mostly idiot free. I probably should...

Re: Moving from Go to PHP Again

#127

Post by aikah »

Xeronate wrote: post #17

Why do so many companies keep moving to go? I tried to like it, but it was just so painful to write.

Go's a language for managers that don't trust their developers with their own intelligence. It's either a good thing or a bad thing.

Go is actually simpler than PHP as a language, once one understands "explicit" pointers (though PHP does expose pointers for a few things, arrays for instance since they are copied by default).

As for PHP, it's useful IN SPITE of itself, and that's the issue, the language works against the developer and only the tooling, frameworks and rigorous security practices can mitigate its flaws.

Re: Moving from Go to PHP Again

#128

Post by hazz99 »

12298765 wrote: post #52
Xeronate wrote: post #17

Why do so many companies keep moving to go? I tried to like it, but it was just so painful to write.

I'm curious, what is painful about it? I came to Go from mainly C++, Java, and Python background, and I feel like it's the best of all 3 (to me). It's compiled and really fast (like C++), it has a great set of libraries and community interaction/support (like Java), and it has simple syntax that is clear and quick to understand (like Python). It's not a perfect language (nothing can ever be), but it's become my favor…

Personally, I find the concurrency support quite lacking. Compared to Java/Javascript/Python/etc, it's great, but nothing compared to languages like Ada or Elixir.

I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).

Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.

Re: Moving from Go to PHP Again

#129

Post by jonwinstanley »

the_gipsy wrote: post #108
trixie_ wrote: post #64

Earlier quoted context omitted.

You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.

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.

Re: Moving from Go to PHP Again

#130

Post by Aeolun »

slezyr wrote: post #106
trixie_ wrote: 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…

Deployment of Go services is much easier. Try to deploy any self-hosted service like nextcloud, gitea. It was a nightmare to deploy nextcloud. Also it turned to be too slow for ONE USER.

Nextcloud is just a bad product :/ it’s hard to pin the blame on PHP.
Post reply on HN