Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

201–210 of 371 posts

Re: Moving from Go to PHP Again

#201
post #192

Earlier quoted context omitted.

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

Why do you want to run 3 functions in parallel?

It's an example. For example if each of these functions takes about 0.2 seconds to finish, it might make sense to run them in parallel

Re: Moving from Go to PHP Again

#202
post #173

Earlier quoted context omitted.

>> PHP simply managed to avoid some of the traditional monolith issues by design No - it didn't. PHP up to this day is a spaghetti mess it had always been.

I really don't see what makes php a spaghetti mess. Spaghetti code is a skill issue, not a language issue

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 order for that new code to become live? Well, I am going to be happy when your skill set is made redundant, because you are getting paid to know all of these quirks and they are not making the industry any better.

You can write good code in _anything_. You could even write it on paper and then expense that to a person working for $0.01/hour to execute it. The question is whether the liability of your methods is lower than the liability of other methods.

PHP is essentially the dinosaur from the times when SEO consultants made loads of money. They are still using PHP because they never knew anything better and the scale of the industry is enormous, so it's slow to change.

Re: Moving from Go to PHP Again

#203

In all seriousness... doees PHP have C# envy? With all of the stuff that has been put into PHP7 (like typed returns and typed arguments) and stuff being proposed (like annotations), PHP isn't that far off from being a interpreted brother of C#.

All OOP languages have C# envy, they just don't want to admit it.

Re: Moving from Go to PHP Again

#204

Um... “Just for fun, I compared apples and oranges again by benchmarking the login page (which doesn't hit any database) for both application versions using Siege. The Symfony application (PHP 7.3, OPcache enabled, optimized autoloader) handles about 1470 req/s. The Go application (compiled using Go v1.11) averages about 18600 req/s.”

I’d say that’s apples v apples.

Yes, but you’re more interested in fruit salad vs. fruit salad. Maybe they actually never have to handle more than a dozen logins. But they have to change the templates relatively frequently:

> it’s more maintainable for us to do it in PHP right now

Re: Moving from Go to PHP Again

#205
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 ins…

As for using Vue and moustache template engines: you can set the delimiters Vue uses:

   new Vue({ delimiters: ['${', '}']...

Re: Moving from Go to PHP Again

#207

Earlier quoted context omitted.

You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire…

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

Re: Moving from Go to PHP Again

#208

Earlier quoted context omitted.

Huh? How is database handling different in Go? You write a parametrized query, the driver prepares it and you deal with the response. MySQLd in PHP is a mirror process, and in fact retains the C function names.

I think the parent refers to lack of automated result to struct mappers, or maybe lack of decent orm... although it’s probably lacking not due to go features, it’s just that kind of magic is typically not the go way.

The lack of automated result > data model mappers is kind of by design with statically typed languages. IMO, Go's structs approach is much more lightweight than languages like Scala where large amounts of time can be spent defining exquisite types. Though - one option is to just accept a slice of `[]interface{}` (or an `Any` in Scala), but then you're negating the type-safety provided by statically typed languages.

WRT ORMs - Go has ORMs, some of them look reasonable. I'm not a big fan of ORMs in general though. IMHO the only valid use cases for ORM's are for applications that need to support multiple database technologies, or where the application developers don't know SQL.

Re: Moving from Go to PHP Again

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

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.

Re: Moving from Go to PHP Again

#210
post #65
post #19

Earlier quoted context omitted.

I am completely out of the loop here. All I know is that I really disliked Wordpress and really-really disliked Drupal back in the day. Can you mention some of the better alternatives? Once in a while a PHP CMS is what I gotta deal with and I dread it, because of the said systems.

As a developer use ProcessWire instead of all the others. Imho the best CMS for PHP.

Thats the problem when you view with the eyes of a developer and not with the eyes of a user.
Post reply on HN