Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously (2016)

slack.engineering

Post reply on HN
Print view View original

61–70 of 150 posts

Re: Taking PHP Seriously (2016)

#61

Post by cogman10 »

paxys wrote: post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

Really depends on what the business is doing.

Chewing through TBs of data every hour? Probably not a good idea to use Ruby.

Doing a bunch of really heavy math? Probably not a good idea to choose PHP.

Doing a SaaS service? C++ probably isn't a good choice.

There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply them everywhere.

Re: Taking PHP Seriously (2016)

#62

Post by namanaggarwal »

okareaman wrote: post #55

I've used a lot of PHP in my life and now feel Go is better suited for my needs. My gut tells me Go libs are written by professionals, while there is a ton of PHP code written by amateurs to contend with. I'll know more once I get further into Go.

That's an unfortunate comparison. Go came around 10 years back and has started to become mainstream fairly recently. PHP has been around for 25 years. So ofcourse the number of libraries you see in PHP are much more and hence much more "amateur" libraries. The professionals writing go code today are the same professionals who wrote PHP code few years back.

Re: Taking PHP Seriously (2016)

#63

Post by munk-a »

fiddlerwoaroof wrote: post #44
munk-a wrote: post #26

Earlier quoted context omitted.

Close I think - the best language to use is the one you will have the easiest time hiring good talent for. If you found a startup and all really love and are fluent in COBOL that's great but... good luck when it comes time to hire another employee.

This is strange to me because I’ve taken and succeeded at two positions now where I didn’t know the language going in.

I just wanted to clarify that I specifically called out how easy it is to hire for. A lot of developers are pretty quick when it comes to adapting to a new language and there are virtues that lean in favor of a language being easy to pickup: sharing a paradigm with popular language, sharing conventions with popular languages and good documentation.

I have yet to work a day job in Rust, but I've worked in Java, C++ and Go so I'd be quite confident applying to a Rust position as long as it wasn't specifically security focused... I would be less confident in how quickly I could pickup Prolog - I think my brain works well for the nuances of the language but I'm less certain.

Re: Taking PHP Seriously (2016)

#64

Post by i_like_to_post »

rabuse wrote: post #10

This seems to be an unpopular opinion in the tech world, but I honestly enjoy working with PHP. It's such a simple, robust language, and you can use it in many different ways, depending on what you're building (OOP, scripting, microservices, etc).

It's a technology that mostly gets out of the way and allows you to get stuff done, even fairly quickly.

Re: Taking PHP Seriously (2016)

#65

Post by edoceo »

i_like_to_post wrote: post #60
throw_m239339 wrote: post #56

Earlier quoted context omitted.

> Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures. I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overr…

> As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content I lol'd. SPAs are a fad. Apps that rely heavily on REST API and browser rendering rank terribly on Google. Create a SPA and help your customers discover your competitor on the first page of Google.

This assumes Google can't figure out crawling SPA.

Re: Taking PHP Seriously (2016)

#68

Post by munk-a »

cogman10 wrote: post #61
paxys wrote: post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

Really depends on what the business is doing. Chewing through TBs of data every hour? Probably not a good idea to use Ruby. Doing a bunch of really heavy math? Probably not a good idea to choose PHP. Doing a SaaS service? C++ probably isn't a good choice. There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply…

I would mention that you're not bound to a single language so writing the guts of the business logic in something like PHP, Ruby or server-side node might be fine - you'd just hook up the performance sensitive bits up to a library written in a compiled language.

In fact I think there are certain organizational benefits to partitioning your language use by skills required to maintain that section of code. When you're a startup there's no benefit at all, but as companies grow you can use that to smoothly transition into separate teams with different expectations around testing and feature flexibility.

Re: Taking PHP Seriously (2016)

#69

Post by rjyoungling »

munk-a wrote: post #26
paxys wrote: post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

Close I think - the best language to use is the one you will have the easiest time hiring good talent for. If you found a startup and all really love and are fluent in COBOL that's great but... good luck when it comes time to hire another employee.

COBOL.. lol so spoiled. It's machine code or gtfo! /s

Re: Taking PHP Seriously (2016)

#70

Post by haffla »

The argument that you don't have to restart the server after editing a file? I mean I've used a couple of web dev environments and I know for a fact that Rails, Django and Express all come with some sort of automatic reloading in development - provided by the framework itself or by a library. Quite sure there is a solution for most environments.
Post reply on HN