Hacker News Reader

Comment by tptacek | Hacker News Reader

For the kinds of applications people tend to build in PHP, PHP is probably a better choice than Go. I'd still do Django or Rails before PHP, but Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write.

View on HN

I have not written a new PHP app in years but recently I had a look at the latest and greatest from the PHP community and its pretty good. The frameworks and tooling look about as good as you will get anywhere and PHP appears to be fast now.

As someone who was about to ditch the PHP ecosystem 6 years ago for something like Rails... frameworks like Laravel absolutely changed the PHP ecosystem.

Also since the release of PHP 7.0, core development seems to have really picked up with good stuff in every release (7.3 was just released a few months ago).

I've used both Rails and Laravel fairly extensively. The Psy shell and Laravel collections library are quite nice, but not quite as versatile as Rails/pry. However, Ruby has a long way to go to catch up to the PHP interpreter's performance.

I just do not understand the fascination with Laravel. When the first version of Laravel was released Symfony was already lightyears ahead.

The only thing Laravel had going for it was that you could take more shortcuts, and it was a pain to integrate into any IDE if you wanted decent autocompletion.

I haven't touched symphony from 1.2 but laravel was a lot simpler to use, especially for begginers. no stupid yaml files, the need to definine everything in yaml before. simpler orm and so on.

When people talk about symfony now they usually mean version 2. Symfony 1 is not comparable to Laravel.

The main thing Laravel had going for it was good marketing.

I disagree. Laravel is much less verbose than Symfony and tries to optimize for developer happiness. Couple that with a kick ass video tutorials site (laracast.com) and that Laravel was started at the fall of CodeIgniter giving it a great boost in users.

Laravel is not what it used to be either -- Laravel 5 is far more capable/usable than Rails or Django. It's ecosystem is vaster, much stronger community, better docs, faster -- pretty much every state it's better than it's competitors.

Not an end-all be-all, but worth noting: https://github.com/topics/framework

Laravel may, may be better than Rails. But Django is better still.

How so?

Symfony and Laravel are really nice.

It's still a horrible abomination of a language that invites bugs and requires A LOT of care to not produce buggy code, though.

It is getting better though. I'm hoping that 8.0 can introduce some real BC breaks that will clean up the mess the language has created over the years.

Does it? If you declare strict, use strict comparison operators and typehint your arguments and returns, what more care do you need? These are not particularly onerous, the strict declaration is trivially templateable in any editor as it's the first line, you'd write types in any language and getting used to only use === !== and forget == and != is ... easy?

Type declarations definitely help a lot, but:

* touching basically any standard library function negates a lot of the benefit

* silent coercion still happens everywhere inside a function body

Even if strict comparison, you have to spend a lot of code validating the input and it's really easy to forget an edge case.

What's the equivalent of === for < and > in PHP?

Use < and > for numbers and strcmp for strings. A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?

>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't even pass the compiler!

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.

There is an absolutely phenomenal static analyser for PHP called enhanced inspections EA (free version and commercial very) that will flag == when === should be more appropriate (among many other things).

For people not using Intellij (or wanting a tool that can be used as part of commit/deploy setup there is phan which is well executed).

I've mocked PHP for a long time (been using it for various day jobs for over a decade) but they've made massive strides in the last 2-3 years to the extent where used properly it's approach 'not a bad' language status.

> what more care do you need?

1. Generic typehints, for one. Typehinting half the methods as returning a generic `array` is not fun.

2. And that's before you even remember that PHP's array is both a vector and a hashmap, so you need to install a PECL extension or a third-party library to get proper Map/Sequence/etc.

Flask is a good alternative to Django for building web apps with python on the backend. If I'm using react or vue with a JSON API, I don't need the form support in symfony or django.

However, deploying a Flask/Django/Rails app still is usually less fun than deploying a PHP app of the same spec written w/ Symfony or Laravel.

Configuring a service to monitor gunicorn, which itself took a bit to configure, before I begin configuring NGINX or Apache... it's really a pain in the butt.

LAMP/LEMP stacks just... are

Setting up and monitoring those apps are as simple as apt-get install uwsgi and writing 10 line /etc/uwsgi app.ini config file.

Deploying is as simple as touching a reload.wsgi file.

I'm working on an internal tool for our micro operation (we're 2 folks) built with Flask and it was my main concern.

Turns out, leveraging Dokku and having the right files, ie a Procfile to bind your app to Gunicorn and pushing the repo to the dokku instance was all it took.

Granted, it's for internal use so downtime isn't that big of an issue.

So ease-of-install beats code quality, code readability, security, future maintenance and better tooling. Dang.

LEPP (nginx, PostgreSQL, Python) stack seems to me an all-around better stack for most of the deployments people use LAMP for.

You have to make your own cost analysis to see what is most efficient for you.

Writing secure, readable, quality code in PHP is something I'm far more comfortable doing than deploying Flask or Django apps on a VPS. That's a function of my lived experiences.

YMMV, but I think declaring python/ruby on the backend is "the all-around better stack" for everyone is a bit short-sighted imho.

If you compare it to a generalized Lamp stack, sure. Compare it to Laravel, and you have no solid basis for "code quality", worse readability, it's Fortune 100-levle-secure, future-maintenance -- Laravel is more active than any other community out there, and has significantly more tooling.

https://github.com/topics/framework

Fortune 100 that uses Laravel isn't a large fraction of LAMP stack users, is it? Thus most LAMP stack users would benefit from picking another stack.

Rest API? Sure. Building webpages? I dont think it was made for that... Although Go templates can work, its still not as flexible as you might want it to be.

Then again these days maybe that is enough for some people. I know a lot of people are eschewing server side page generation entirely for some static js and assets sitting in an S3 bucket that talks to an API server. The only barrier now is SEO, and people are coming up with all sorts of creative solutions to deal with that, as the search engine bots themselves get better and better at indexing js content. That said, I sort of hate frontend js frameworks. You can do everything I just said without them, and really, we should have been doing it for years, like even pre-2010, but we were just too caught up in this markup = server side mentality to really operate that way. Part of it, I think, was that CDNs are a sort of recent thing, and before them you were always running a server anyway, so why not generate the page server side if you're going to go to that much trouble. Also client-side capabilities have dramatically increased, and then you have HTML 5 to consider.

It's pretty flexible in my opinion. And you can substitute go templates for another template library if you like.

Granted, we're talking about largely server side generated web pages and, haha, who does THAT still in 2019 : hangs head in shame :

It's true. I don't often do so at work anymore, either—except for utility pages.

But I am rewriting my personal site/blog in Go as a trial run/learning process. I've been critical of Go in the past so I thought I'd give it a... go.

So far I don't mind the experience. No server framework, either. The standard library is actually pretty good, at least for something simple like that.

The only [external] dependency I'm pulling in so far is `blackfriday` for parsing Markdown files (the posts) upon request— I'm much too lazy to write a Markdown parser myself for this purpose.

It's not finished yet, but it's on its way— https://github.com/robertfairley/rf-19-go

> 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-exponenti...

It turned out to be more of a replacement for Python for places where you need speed. Then again, a JVM or .NET language would probably be better.

In go, Querying SQL is very much like doing the same thing with the base libraries for mysql in C. Doing the same in most any other language is much much easier and just as safe.

Credentials: Worked mainly in go for 4 years... 18+ years coding in about 9 languages.

Yes I realized this is opinion.

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.

Buffalo has made it a pretty pleasant experience in the past year or so

Buffalo?

A go web development framework

The Buffalo Web Framework for Golang: https://github.com/gobuffalo/buffalo

Seems useful, but it’s yet another of those frameworks that introduce spurious CLI tools for „initializing“ the project by generating dozens of files that one either doesn’t need at all or has to replace anyway. I don’t need a tool to generate CSS boilerplate, I can just copy it from somewhere myself if I decide to use external CSS.

One of the reasons PHP was appealing initially was that all this boilerplate and extra files were unnecessary, you just wrote something in the .php file (in Apache’s hierarchy) and could load the web page. As problematic as that was, it let you focus on getting stuff done instead of overwhelming you with ad hoc conventions and dozens of files with no immediate use.

Go is a language with sane defaults and little boilerplate. It would benefit from a web framework with similar principles.

> but Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write.

Or anything else for that matter, maybe aside from some command line tooling.

> For the kinds of applications people tend to build in PHP, PHP is probably a better choice than Go.

Facebook goes into this category then, I presume?

Reply on news.ycombinator.com