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

331–340 of 371 posts

Re: Moving from Go to PHP Again

#331

Post by combatentropy »

sebcat wrote: post #319
combatentropy wrote: post #296

Earlier quoted context omitted.

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) ov…

MultiViews doesn't let HTML files have PATH_INFO by default. Only files that Apache considers "scripts" get PATH_INFO (e.g., .php). Therefore /index.html/a.srv would normally return 404 Not Found, even with MultiViews on.

They could have done further configuration to let HTML files take PATH_INFO, but this Rube Goldberg machine of multiple mistakes bears no more connection to MultiViews than mod_rewrite. In fact, I see no mention in the article of MultiViews or its module, mod_negotiation. So how do we know they were using MultiViews and not mod_rewrite, which people use much more often for this amount of indirection?

Either way, this exploit is impossible in the original suggestion, to just use MultiViews with PHP files to remove the ".php"

Re: Moving from Go to PHP Again

#332

Post by kristopolous »

hluska wrote: post #318
kristopolous wrote: post #126

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…

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 atti…

Using failure as infrastructure at a fast paced startups with shoestring budgets and then taking the resources to afford the luxury of a nurturing and caring mentorship for every teenager with a computer is a disaster.

Re: Moving from Go to PHP Again

#333

Post by heavenlyblue »

frenchy wrote: post #303
heavenlyblue wrote: post #202

Earlier quoted context omitted.

No, I am speaking about the ecosystem. Large, industry-grade projects developed in this language. What standards did Wordpress set a few years ago? Huge, disjoint sets of files spread throughout the themes folders. How much time does it take me to understand which of these files is causing the error? Do you still upload your code via FTP directly to the web server? Do you still reset the code cache for the PHP in ord…

> Do you still upload your code via FTP directly to the web server? It's pretty rare that this is even an option, since no one in their right mind would set up an FTP server with access to anything important. SFTP? I don't see why not. No need to make things more complex than is necessary. I don't remember any particular problems with code caching when I did PHP development, though maybe you use a different caching t…

>> SFTP? I don't see why not. No need to make things more complex than is necessary.

You are trying to argue definitions (SFTP vs FTP when FTP just means “any file transfer protocol”) instead of arguing that uploading any amount of files by any protocol that are immediately picked up by the interpreter introduces nondeterministic behaviour of the website where the users accessing your website only see a subset of the files you were trying to upload.

Doesn’t that just reinforce one’s confidence in the fact that PHP developers are generally quite amature in nature?

Re: Moving from Go to PHP Again

#334

Post by hluska »

kristopolous wrote: post #332
hluska wrote: post #318

Earlier quoted context omitted.

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 atti…

Using failure as infrastructure at a fast paced startups with shoestring budgets and then taking the resources to afford the luxury of a nurturing and caring mentorship for every teenager with a computer is a disaster.

That is true.

However, you can pursue a culture of excellence without being rude and toxic. You can be kind and humble without coddling.

Edit - I should have added that if teenagers with computers have a good attitude, feel engaged and feel cared about, they can be extremely productive members of a team. And they have a tendency to grow into really amazing engineers (and fine people).

Re: Moving from Go to PHP Again

#336

Post by sacado2 »

pjmlp wrote: post #262
sacado2 wrote: post #211

Earlier quoted context omitted.

> for many Go is the only compiled language they ever used That, or it can be read as "in the family of web-friendly languages". The only other "fast" language widely used for the web is Java.

C++, .NET also come to mind in the widely area, with OCaml, Haskell failing under the not so widely, but fast umbrella.

O'caml and Haskell are extremely niche in the web server world, and are not especially faster than go. C# is not blazingly fast either. They all seem to be in the same ballpark.

Re: Moving from Go to PHP Again

#337

Post by hazz99 »

grumpydba wrote: post #240
hazz99 wrote: post #128

Earlier quoted context omitted.

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…

> 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. Absolutely not. Locks/spinlocks are found in pretty much every significantly parallel software project. It is pretty arrogant to criticize almost all software architectures on earth.

> It is pretty arrogant to criticize almost all software architectures on earth.

Almost all software is programmed with modern languages, which all (imo) have extremely lackluster support for concurrency. It's not a symptom of the programmers, but the tools they work with. Who uses Ada these days?

Locks should only be used when other protection mechanisms are too slow.

Semantically, the critical region protected by a lock is not connected to the lock in any way. This can make debugging races super difficult, and you have to rely on everyone to lock everything at the right point.

Juggling multiple locks in complex concurrent processes is difficult, and prone to bugs.

I struggle to think of where a lock is required, barring the extremely hyperoptimised hot paths within operating systems, or similar applications.

Re: Moving from Go to PHP Again

#338

Post by cloverich »

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.

Because it works well at various levels and is good at producing low error maintainable code. It's also very stable and has a good stdlib so what's written five years ago is still working and makes sense. It's not really fun for me (yet?) and I think something like Django is more suitable in many cases, but choosing a core competency go is a pretty safe bet for medium or large company.

Re: Moving from Go to PHP Again

#339

Post by vesak »

dpcx wrote: post #214
vesak wrote: post #151

Earlier quoted context omitted.

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

I don't think the snark in this response is super helpful; a simple "Yes, throw a TypeError when the types are incorrect" would have sufficed.

Congratulations for being the last straw. I'm getting out of this site for good.

Re: Moving from Go to PHP Again

#340

Post by 013a »

exceptione wrote: post #291
013a wrote: post #289

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…

You are comparing frameworks with a language here. I think that if they choose to use a high-quality, modern php framework like Symfony, the technical decision would still make sense in the context of the alternatives you mentioned.

That comparison is intentional, for one reason: Go doesn't have any "frameworks", let alone frameworks that are remotely comparable to the productivity offered by Symfony, Django, or Phoenix. The language actively opposes the development of tools like these. At best, we've got libraries that wrap net/http, io/ioutil, etc and moderately increase developer productivity, but there's nothing holistic and opinionated. The closest you can get is something like gRPC, but its not even the whole story, and it also relies on codegen so that's a disqualification in my book.

This isn't just technical; its baked deep into the culture of Go. And that's fine. Its designed for something different.

Post reply on HN