So it's been awhile since I switched from PHP to Golang.

At first I missed PHP a lot, but golang really has some advantages, so its fine.

But over time, and when the project grows in features, I more and more and more start to miss more and more at least basic classes / inheritance and abstraction friendly stuff from php.

Im finally reaching the point where I start to truly miss php, I can't stop myself after writing a feature to think how much less work that would be in php.

Call me crazy, but damn, it's real.

What about the performance differences? I bet it's an enormous difference..

Come back to us, don't deny the benefits of the almighty elephpant

@SuspiciousBug i replaced a bunch of old scripts that were shitty that we had with go executables at work, while it is nice, the performance upgrade ain't really that noticeable, specially with the php execution model on web servers.

I solely believe that one needs to be using google level services to the masses for it to be that much of an impact.

I would argue the same for many other tools. Managing a large properly coded php project is easier to reason than the pointer manipulation shit that I have seen on some golang projects. I still love Golang and will continue to use it at work though, but PHP seems to continue to thrive, and PHP8 soars in terms of speed

Php performance aint that bad as people think. If you take at least minimal care about performence in php it will perform very well, especially on fpm setup, or even better, react php app (not react js, react php is a thing).

But forced simplicity of golang is 'sexy' at the beginning but at least for me it got old and ugly.

I ended up on golang only because there are very domain specific libraries i need while on php side of things there are some, but they are... Bad.

@DubbaThony That's the thing with Go. It sometimes takes dogma a few steps too far. Yeah I think we can all agree Java EE business software OO monstrosities suck but that doesn't mean the only way to write maintainable software is to go back to the stone ages

@12bitfloat it's not that bad to be honest. You can easily build all the abstractions you need even things like inheritance (well composition but it gives the same main functionality of inheriting the fields and methods) and generics are there.

That said just using Go for the sake of using Go is stupid (you can replace Go see with any tool here). PHP has super high performance. Look at the event based workerman for example. However most software is not thread safe.

@hjk101

Well its luckly not go for sake of go, but i really wish they would allow me to have services in mixed languages. The layer that **actaully** needs go could be shrunk down to like few RPC calls, and all other buissness logic is your typical generic buissness logic.

It struck me today as i was trying to write something and all it was hacks with reflect that could be so easy solved with more (still fairly simple IMHO) language features. And i still like both languages (uhh, php more lol) a lot, just oversimplification with go... Painfull

Comeback to the elephant side. Sure it was easy to write bad codes with PHP. I have seen a lot of noobs posted their horribly written PHP code online, asking for help, but nobody helped. Why no help? Because it's horrible beyond salvation.

But if you can write good codes with it, it really makes your life easier. I came from C# side, and now I hate how convoluted it is. I will never use C# for web. I will use it only if somebody asked me to make native windows app.

@DubbaThony that sucks! It still doesn't sound like you can use the right tool for the job. Mixing is super easy. You can do UNIX socket programming with PHP for IPC if you have to (if latency is a big deal else two services with msg queue is recommended).

I've written many things in Go from services that handle millions of requests to simple executables. None of them require reflection code that we have written. Some did at first but always could be refactored. We do use some standard libs that do use it under the hood like JSON parser but even that is not strictly necessary.

When I started out in Go I've found myself combating the type system a lot. Most of the time I was just doing it wrong. Now with generics it's possible to do more things wrong again. It also allows for more deduplicated code and replacing code where reflection is used to support multiple types.

@hjk101 Hmm, I don't know about being able to build all the abstraction I would want

But to be fair I'm a bit spoiled

@12bitfloat yeah you probably can but not the way you want to do it.

I always try to do things the most idiomatic way of the language (given I'm proficient enough). With Go sometimes it's beautiful and simple but sometimes a little magic/sugar can go a long way. You probably need some sugar to get the rush.

@hjk101 My issue is that -- from what I've seen -- the idomatic Go was is often unnecessarily verbose which kinda defeats the purpose of the abstraction in the first place

Iterators before generics were introduced for example. You /could/ make it work with channels and stuff but it's just not... great

@hjk101

IPC/unix socket itself is out of question, since they would't share containers, but implementing JSON RPC is trivial and effective way to go about it. And if it goes on some heavy usage and becomes a problem, it's not like there is plethora of solutions to pick and choose from...

About generics in golang - I use them for simple helper functions, not being able to use them on struct is kindda sus IMHO. And ye, I could do a hax or two to force it to do more but nah. I dont find them as useful as I was hyped for. Sure, there are many cases where they make life easier, but still far cry from what I would like it to be.

@12bitfloat

Right on the money of root cause of why Im getting so tired of golang

@DubbaThony Yeah that is the best way to go about it unless you have the latency/performance problem.

To use UNIX socket I did exactly that: share a container. The base image is PHP. But there is a builder stage that builds the Go executable. The process that is started is PHP and that creates the socket and starts/manages the Go process. This way it doesn't break the single responsibility principle. The Go part is just a worker. Extra care has to be taken for graceful shutdowns but that's about it.

I can definitely see the limitations of Go generics implementation. Most of it is by design assume are side effects that need to be addressed in later versions.