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

221–230 of 371 posts

Re: Moving from Go to PHP Again

#221

Post by eeeeeeeeeeeee »

jonwinstanley wrote: post #129
the_gipsy wrote: post #108

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.

I think you indicated the problem. You can be secure or insecure in just about any language, but the barrier to entry is so low in PHP that it is easiest for beginners to do a lot of damage while still launching an app.

I’d rather there be some learning curve so people understand what they’re doing (or not doing).

Re: Moving from Go to PHP Again

#222

Post by james_s_tayler »

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…

Totally agree with this.

The way I think about it is if you think through the entire software stack and all the instructions that get executed across all the machines and their operating systems and programs running underneath before things even get to your code and then all of the standard library and framework code plus your code. For just a simple loading a web page that is a trillion piece jigsaw puzzle and every single piece has to line up or the whole thing just doesn't work.

We do the humbling and the remarkable every day and trillion piece jigsaw puzzles are no joke. It's the exception that you get it right. Given all the pieces required that's a lot of sources of potential entropy and the more it increases the more the system destabilizes and/or becomes unworkable. Things like languages, libraries, frameworks etc make certain decisions on your behalf with the goal to contain some of that entropy within their given abstraction.

Re: Moving from Go to PHP Again

#223

Post by scarface74 »

hderms wrote: post #207
kristopolous wrote: post #153

Earlier quoted context omitted.

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

I think it depends on whether the library you're using is well designed and doesn't require contorting code around it. If it's a simple integration I don't see much of a point in abstracting it but if dealing with the library is painful on some level you'd maybe get some benefit from doing so. That being said this is somewhat orthogonal to the issue you're describing

I do have a *Utils module to wrap some calls to the AWS SDK but it’s not to protect from “lock-in” it’s a classic DRY principal of putting a code snippet in a function so I don’t have to remember how to do it every time.

Re: Moving from Go to PHP Again

#224

Post by xdfgd0ig0dg »

latch wrote: post #66
darkr wrote: post #61

Earlier quoted context omitted.

> Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write. Citation needed. I’ve had a very nice time. It’s statically typed, has excellent templating support, and is generally very productive.

Well, they thought Go would be an alternative to C++ (1) which has never really been the most popular website backend language. I'm glad it's working out for you, but I don't think it's a stretch to say it wasn't really designed for it. On its own, that doesn't mean it's a bad fit; but I agree with your parent and think it's awful for this type of stuff. (1) - https://commandcenter.blogspot.com/2012/06/less-is-expone…

Highly outdated to point out Go would be an alternative to C++.

It has been most popular in web-dev, with alot of people switching to Go from Python, PHP or Ruby.

Go does web really really well.

Re: Moving from Go to PHP Again

#225

Post by 12298765 »

rnvhhynr wrote: post #149
spdionis wrote: post #95

Earlier quoted context omitted.

use an IDE

What's a good IDE for Go? Something that's snappy and fast, no Java dinosaurs please

I mean GoLand is pretty good, but I do also like IntelliJ, so YMMV if you don't like the JetBrains products. And it isn't free.

VSCode is also really good for Go, I was surprised. There are plugins that massively help with testing, syntax checking, error handling, etc. I think it actually catches more issues than GoLand!

Re: Moving from Go to PHP Again

#227

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.

I wasn't trying to be helpful. I was trying to discourage stupidity ("very weird") by ridiculing it.

Re: Moving from Go to PHP Again

#228

Post by euph0ria »

eeeeeeeeeeeee wrote: post #218
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…

You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”

I really don't see how Wordpress is a valid argument here. We run several business systems in PHP serving hundreds of thousands of users. Last time I used Wordpress was over 10 years ago for my personal blog. Haven't used it for anything else. PHP is great for us, regardless of how Wordpress performs.

Re: Moving from Go to PHP Again

#229

Post by x0hm »

eeeeeeeeeeeee wrote: post #218
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…

You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”

Wordpress is written in PHP.

Wordpress is not PHP.

Post reply on HN