←back to thread

The Rise of Hybrid PHP: Blending PHP with Go and Rust

(yekdeveloper.com)
133 points avan1 | 5 comments | 30 Aug 25 19:02 UTC | HN request time: 1.045s | source
Show context
liampulles ◴[30 Aug 25 23:17 UTC] No.45078861[source]▶
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them.

It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing things with the god framework, because each project has to deal with a niche infrastructure environment and/or business context that requires some hack or additional dependency. Then when you need to, say, upgrade a language version, you can't follow the god framework's guide for doing this (if there even is a decent one) because it will break your workaround. So you end up with this hodgepodge which never gets updated until it reaches a critical point where it cannot continue to run on your infrastructure, and it forces a big migration project.

Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.

I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.

replies(10): >>45079009 #>>45079250 #>>45079251 #>>45079544 #>>45079627 #>>45079933 #>>45080311 #>>45080715 #>>45082526 #>>45083171 #
evantbyrne ◴[31 Aug 25 02:53 UTC] No.45079933[source]▶
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
replies(2): >>45080212 #>>45083933 #
1. liampulles ◴[31 Aug 25 15:28 UTC] No.45083933[source]▶
I think the Java stream API is amazing, and I do like that.

Not having the equivalent of hibernate level ORMs is not a disadvantage for me personally, just because I don't like ORMs - Asking chatgpt to spit out some SQL and mapping code for me and being able to tweak the actual SQL over time is preferable (but again that is just my preference).

I don't really agree with the idea that Go has an underdeveloped type system, I think its contraints lend itself to productivity in other ways. Of the various languages I've worked with, Go programs I expand have the highest chance of working the first time I run them, because the compiler and language server A) give meaningful indications of mismatched usages and B) older Go projects have a very good chance of just working, without me having to worry about getting them going with my IDE again. B is a product of the fact that they have been very conservative with the language.

replies(1): >>45092876 #
2. evantbyrne ◴[01 Sep 25 14:20 UTC] No.45092876[source]▶
Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily return a result type, but what if I also want to handle validation of input before the query and then later return a HTTP response? Well to chain a result type end-to-end in Go requires it to have knowledge of all the different types/interfaces that it could map to, which I believe is way too broad of a responsibility for one type, even though all of those features feel as though they could very naturally chain together and reduce down to a single error. These kinds of type limitations effectively force Go libraries to live on their own islands where they don't compose with one another.
replies(1): >>45103003 #
3. liampulles ◴[02 Sep 25 13:42 UTC] No.45103003[source]▶
The "Go-ithic" way to write a library is to be strict with its API and place the onus on the consumer to do the work to map to and from it. So if I understand your example correctly (I might not), then it would be totally acceptable and in fact preferable for a Go codebase to map between the validator, then the query builder, and then the http response. Its preferable because I want libraries to have a thin API and be focused on doing one thing well, and I also want to have it clearly presented to me how I am mapping to and from an external dependency.

Another way of putting is that the Go philosophy is not to abstract details away or try and hide them, its to make the actual control flow of the program as plain and obvious as possible.

replies(1): >>45103070 #
4. evantbyrne ◴[02 Sep 25 13:47 UTC] No.45103070{3}[source]▶
I understand that is the Go philosophy. I care more about what is practical than dogmatic. It seems clear to me as a complex library author that the type system leads to way too much glue code, which is expensive to write and maintain.
replies(1): >>45104921 #
5. liampulles ◴[02 Sep 25 16:05 UTC] No.45104921{4}[source]▶
As a Go developer of a few years now, I don't find it that way. I've found it to be very easy to write the glue code, because its largely the same as other glue code, and I find it easy to maintain because the plain control flow makes finding bugs easy. But perhaps the takeaway here is that, because Go certainly is opinionated, its a way of doing business that works for some and not others. And that's cool.