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

281–290 of 371 posts

Re: Moving from Go to PHP Again

#281

Post by asark »

module0000 wrote: post #252
combatentropy wrote: post #36

Earlier quoted context omitted.

Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't u…

Apache is a robust piece of software, capable of more than the vast majority of users ever suspect.

You know, to this day, if someone came to me and said "we want to run a site for five years on an LTS Linux distro release on a fairly weak machine, with auto-updates to system packages but no other maintenance intended. We're not gonna bother with monitoring or whatever. It's mostly static but it'll have a small dynamic component, say 500 LOC worth, maybe. If we ever have to manually touch this thing aside from maybe bouncing it once or so a year we'll consider that a failure. What should we use?" I'd probably say... Apache and PHP.

Sometimes I'm in the middle of messing with the Lovecraftian horror that is the modern JS stack or screwing with extracting what I need from whatever awful request object someone cooked up or any number of other things that aren't accomplishing anything of business value and I wonder whether maybe somewhere we veered way in the wrong direction, as an industry.

Re: Moving from Go to PHP Again

#282

Post by pushtheenvelope »

acomjean wrote: post #50
ilovecaching wrote: post #21

Why not try out Hack? It's kind of a cross between PHP and Go. Hack has a real type system, and HHVM is incredibly fast.

There was a time when hack was new and it was so much faster than php. PHP really got their act together (nothing like a little competetive pressure) and made the 7 series that ran at almost the same speed as hack. People are inertial and won't change unless they have too or something is significantly better.

I fear you are conflating two things: Hack is the language (type system, syntax) while HHVM is the runtime (which can run Hack code, and could PHP until very recently). Your answer on the speed pertains to HHVM.

Re: Moving from Go to PHP Again

#283

Post by tomschlick »

spdionis wrote: post #246
Aeolun wrote: post #133

Earlier quoted context omitted.

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.

The main thing Laravel had going for it was good marketing.

I disagree. Laravel is much less verbose than Symfony and tries to optimize for developer happiness. Couple that with a kick ass video tutorials site (laracast.com) and that Laravel was started at the fall of CodeIgniter giving it a great boost in users.

Re: Moving from Go to PHP Again

#284

Post by pushtheenvelope »

kijin wrote: post #90
ilovecaching wrote: post #41

Earlier quoted context omitted.

> Perhaps because they don't want to incur technical debt to a language/runtime that could change at the whim of one company that probably doesn't have other companies' best interests in mind? How is Go any different?

Go has been well received outside of Google. Wikipedia even has a list of companies known to use Go. I'm not sure how up to date it is, but the list includes Cloudflare and Netflix. At least some of them might have the oomph to fork, take over, or otherwise influence Go if Google ever dropped the ball. Meanwhile, I can't think of any major online service that relies on Hack apart from Facebook and its subsidiaries.

Slack does.

But I agree with the original point about not fully relying on the whims of a major corporate promoter. Priorities can change within, without clear visibility on the outside.

Re: Moving from Go to PHP Again

#285

Post by x0hm »

eeeeeeeeeeeee wrote: post #253
x0hm wrote: post #229

Earlier quoted context omitted.

Wordpress is written in PHP. Wordpress is not PHP.

Did I say that? Please don't twist my words. I was responding to the OP who was talking about the WordPress plugin system, which allows just about anyone to add third-party PHP code into the system. And those plugins have access to everything in the WordPress stack (and the file system for that user). And I think you can definitely argue that a low barrier to entry means that it gives beginners a lot of power they do…

Again, those frameworks are written in php. They are not php.

You're trying to apply the problems of a framework/app to a language itself.

Re: Moving from Go to PHP Again

#286

Post by 52-6F-62 »

nkozyra wrote: post #140
diamondo25 wrote: post #8

Earlier quoted context omitted.

Rest API? Sure. Building webpages? I dont think it was made for that... Although Go templates can work, its still not as flexible as you might want it to be.

It's pretty flexible in my opinion. And you can substitute go templates for another template library if you like. Granted, we're talking about largely server side generated web pages and, haha, who does THAT still in 2019 : hangs head in shame :

It's true. I don't often do so at work anymore, either—except for utility pages.

But I am rewriting my personal site/blog in Go as a trial run/learning process. I've been critical of Go in the past so I thought I'd give it a... go.

So far I don't mind the experience. No server framework, either. The standard library is actually pretty good, at least for something simple like that.

The only [external] dependency I'm pulling in so far is `blackfriday` for parsing Markdown files (the posts) upon request— I'm much too lazy to write a Markdown parser myself for this purpose.

It's not finished yet, but it's on its way— https://github.com/robertfairley/rf-19-go

Re: Moving from Go to PHP Again

#287

Post by sacado2 »

mbrumlow wrote: post #259
sacado2 wrote: post #209

Earlier quoted context omitted.

This is so true. I love go so much, because deployment is so easy, but using it for end-user web content is a real PITA.

What makes it a PITA? I use go for building websites and it was the first time web development really made any sense. All the other systems out there require tons of tools, and lock you into doing things their way . So, what makes GO so much of a pain? Maybe ignorance is bliss for me?

I made a very simple webapp a few months ago, where students are proposed assignments and can rank them. For that, you need authentication, and DB management: a subject table, a student table, and a ranking table. You have to do all of that manually in go, while other languages have frameworks that take care of it.

Still did it in go because it was a very simple webapp and deployment is so easy with go, but for a more complex task I'm not sure I'd have used it.

Re: Moving from Go to PHP Again

#288

Post by combatentropy »

_0w8t wrote: post #167
combatentropy wrote: post #36

Earlier quoted context omitted.

Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't u…

nginx can also do it for any FCGI script.

I've seen that Nginx can remove the .php suffix, with its try_files directive. but I haven't see how it can handle PATH_INFO of arbitrary length. Can you point me to the documentation that you're thinking about?

Re: Moving from Go to PHP Again

#289

Post by 013a »

Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty great at CLI tools).

> They were a little surprised to hear our stack involved Golang and some flat out told us they’d prefer PHP, because that’s what most of our products rely upon.

I believe this is the real reason why, and everything else above it is pointless technical justification for a sound business decision. I also believe there's an unvoiced, even more powerful reason, in "I already know PHP and don't want to learn a whole new thing."

These are both sound reasons. The technical justifications are not.

Choosing Go for something like this was a bad decision. But choosing PHP is only slightly better. Opting for Django, Rails, or Phoenix would have better technical justification, but technical justification is rarely the real reason why we make decisions like these.

Post reply on HN