You can make anything with anything, but Rails is the closest thing to an Aspect Oriented Programming environment that I’ve seen in the wild. It’s not easy to replicate that type of ecosystem with any other framework. I’ve spent ample time on teams using Go, Python, PHP, Java and C#.
There’s just no comparison vs what a small Ruby team can accomplish.
I was trying to do that on my first big PHP project, and got called out. The architect said "your code is too good, PHP is for writing crap". If you are going to write good code, you should do it in another language.
Symfony framework is a great example of a PHP framework written by Java programmers. All the same verbosity as Java, but without the benefits of Java.
Yes, you can write bad code in any language.
PHP makes it hard NOT to. The footguns are all sitting out in the open, loaded, and the safeties are off.
As a counter-point, the biggest disasters I've seen has been involving either C++ or C#, but in the end I think the reason they were disasters were because of the programmers (and their ego) rather than the programming languages they worked with. C++ is plenty open and without safeties, but that doesn't mean you have to use it like that.
Jokes aside, Laravel is probably a more likely contender to provide a Rails experience for PHP.
And it's easy to get clouded by anecdotal data, I'm sure I'm biased as well. But after some time in the industry, it matters more who the person is that is using the framework, than the framework itself. If you put an equally skilled developer with the same amount of experience in either Symfony or Rails, I'm sure they can be as productive as the other. But then skilled developers tend to gravitate towards Rails more than Symfony, so hard to judge in the real world.
I would say it is as productive as rails too.
There is no ActiveRecord and way way less magic which slows (initial) development speed but it pays off in less bugs to fix.
So overall development speed is roughly the same. But with Go you gain co routines and nice performance which can make life a lot easier.
Gos type system, while somewhat poor, still helps too.
The worst part of the whole thing is actually the weird Go std lib templating.
Problems usually come from when teams start with point 3 and 2 when in reality they should stay lean in the beginning.