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

311–320 of 371 posts

Re: Moving from Go to PHP Again

#311

Post by msie »

enz wrote: post #22
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…

Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?

Hmmm Symfony uses routes declared in a file...

Re: Moving from Go to PHP Again

#312

Post by lwansbrough »

KerryJones wrote: post #299
52-6F-62 wrote: post #294

Earlier quoted context omitted.

I'm not all out against PHP. I've used, and still do, on occasion for simple things and prototyping. That said, I'll never go out of my way to use it for much else—let alone serving and routing something public-facing ever again.

Checkout Laravel, it powers some Fortune 100 sites -- it's definitely "large-site" capable.

Laravel performance is abysmal, though. You're gonna spend 10x on server costs if you use a fully featured framework in PHP.

Re: Moving from Go to PHP Again

#313

Post by pjmlp »

grumpydba wrote: post #310
pjmlp wrote: post #264

Earlier quoted context omitted.

Memory hog only by those that don't know what they are doing and happilly new everywhere. Yes it is hard to tune, but not so much different than playing with C or C++ compilation switches, across each compiler that is being used in production.

> Memory hog only by those that don't know what they are doing and happilly new everywhere. Go uses an order of magnitude less memory for most type of workloads though. Also you don't tune c++ binaries delivered to you. You have to tune the JVM's option to death for big apps. I can't count the number of incidents "solved" by raising the Xmx param.

I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment.

The big question is how properly those big apps were coded.

Go doesn't run Fintech servers, while Java keeps replacing C++ servers. Yes, one needs to code Java with low level tricks like C++, but it is possible and there are many performance experts doing it.

How many Fintech servers are running on Go?

Re: Moving from Go to PHP Again

#314

Post by moojd »

EZ-E wrote: post #192
no_gravity wrote: post #188

Earlier quoted context omitted.

One easy way to do multiple http requests in parallel are the curl_muli functions: http://php.net/manual/en/function.curl-multi-init.php

Thanks, that's one solution if making multiple calls is needed. That was mostly an example though, for example if I wanted to run 3 functions in parallel, I don't find any "easy" and elegant way. Some libraries exist like amp, but it seems a bit heavy handed as the language itself doesn't have great tools for it https://github.com/amphp/amp

Neither amphp or reactphp will let you start running blocking functions in parallel out of the box. They basically just provide syntactic sugar for making single-threaded, cooperative multitasking easier by wrapping php's native ability to read/write to sockets asynchronously (or by using pecl extensions.)

So you can respond to websocket messages or http requests asynchronously but you're not going to be able to implement anything like a parallel merge sort were you offload work to other threads. Things like general purpose file IO are not easy at the moment either.

Amphp might seem a heavy handed because they've taken the monorepo approach. ReactPHP on the other hand has broken everything up into individual components. For example, you can get started with ReactPHP by just pulling in the event loop https://github.com/reactphp/event-loop. All the heavy lifting for the native loop is https://github.com/reactphp/event-loop/blob/master/src/Strea... and the API is tiny as well https://github.com/reactphp/event-loop/blob/master/src/LoopI...

Re: Moving from Go to PHP Again

#315

Post by davidsawyer »

jimmy1 wrote: post #176
joaodlf wrote: post #98

I love Go, for many situations, but definitely not for a typical user facing website. The community seems bent on the whole "all you need is net/http", but that just isn't practical in modern web development. People like ORMs, easy to handle html forms, security as a default, easy session/cookie handling etc. In the end, web developers want ease of life. Go is a great language for many things, but if it's going to ta…

> but that just isn't practical in modern web development People always use this modern term as if it implies something significantly different or more "advanced". The web hasn't changed much. It's still data over tcp sockets to a contained runtime -- a web browser. > People like ORMs People in my experience are starting to dislike ORMs. If you have done this for long enough, you realize they are great for getting of…

Speaking as someone who moved from a company that heavily leaned on an ORM to a company that is using jOOQ (a thin Java wrapper around SQL) for everything, not being able to use an ORM is pretty painful.

I greatly miss the nice, clean ORM experience. It's so much better for developer efficiency.

Re: Moving from Go to PHP Again

#316

Post by pjmlp »

grumpydba wrote: post #309
sacado2 wrote: post #251

Earlier quoted context omitted.

Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).

Don't forget that you also have to install and update the JVM. We admins don't like that.

Only those that don't know how to bundle the JVM with the application or make use of a commercial AOT compiler to native code.

Re: Moving from Go to PHP Again

#317

Post by oconnor663 »

apta wrote: post #271
agnivade wrote: post #75

Earlier quoted context omitted.

> I found it too easy to accidentally forget to check an error Use https://github.com/kisielk/errcheck for that. Or prefer https://staticcheck.io/ for a larger set of checks.

fmt.Println("foo") I don't see errcheck complaining there how about (taken from here: ( https://www.reddit.com/r/programming/comments/ak305l/goodbye... ): r1, err := fn1() r2, err = fn2() if err != nil { return err } err check doesn't complain either

That second example is really surprising. This sort of thing happens all the time in production when lines get moved around. Does anyone know why errcheck misses it?

Re: Moving from Go to PHP Again

#318

Post by hluska »

kristopolous wrote: post #126
Vinnl wrote: 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…

I have never had that reaction because frankly, I don't think it's appropriate to call people who know less than I do 'flunkies'. Sometimes, I like to approach the situation with humility and ask questions. Other times, I quietly ignore the situation. And other times, if it's a particularly egregious error, I'll write code and explain why I think it is better. But I never call someone a flunkie because words and attitudes like that are incredibly rude and toxic.

The moment you convey that sort of attitude, two things happen. The person you called a flunkie will not learn a goddamned thing from you. And, if they happen to be right, you won't learn a damned thing either. Great choices.

Re: Moving from Go to PHP Again

#319

Post by sebcat »

combatentropy wrote: post #296
sebcat wrote: post #69

Earlier quoted context omitted.

Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this. [1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...

If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't. 1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists. 2.…

> It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin

The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.

a.srv ended up in PATH_INFO because index.html existed.

The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.

Re: Moving from Go to PHP Again

#320

Post by chiefalchemist »

KerryJones wrote: post #299
52-6F-62 wrote: post #294

Earlier quoted context omitted.

I'm not all out against PHP. I've used, and still do, on occasion for simple things and prototyping. That said, I'll never go out of my way to use it for much else—let alone serving and routing something public-facing ever again.

Checkout Laravel, it powers some Fortune 100 sites -- it's definitely "large-site" capable.

I did one project in Laravel. I was impressed. That said, it takes WP to the opposite extreme. That is, it is has little regard for backwards comparability. Finding answers / examples via The Google is messy and frustrating, at least for someone who was new to Laravel.

I like that it's forward-thinking, but it moves so fast that it has negative impact on user (i.e., dev) experience.

Post reply on HN