Goravel, Web framework inspired from Laravel in Golang
github.com
github.com
I would be interested to hear more.
A lot of good points are written down here: https://old.reddit.com/r/PHP/comments/131t2k1/laravel_consid...
In short, it just doesn't use good programming principles. It's not just easy to write code with bad principles, it's everywhere in the tutorials.
There's of course Laravel apps out there that do have good programming principles. It's very much possible to write good code with Laravel. It's just less common.
God help us if it this project becomes the normal way of writing http go servers applications. Maybe at that point it's time to become an embedded rust programmer or a monk.
But PHP has more to give than just as a birthing ground for teenage programmers.
When I many years later accepted a PHP job as a senior developer, PHP provided a consistent experience of "bad practice everywhere", a fractal of cringe I couldn't ironically reproduce. Working with this for a year taught me a lot about how to deal with critical legacy software beyond repair and being responsible with what you've got.
I think there is no better way to get your hands consistently dirty than with PHP.
Coincidence: I do embedded Rust, and my wife is a buddhist monk. ;-)
I feel most of the PHP community is pretty mature these days. More pragmatic than Rust, sure but that is a good point in my book. Though I am glad you found your enlightenment.
That stof guy was one of the worst. Inconsistencies, incompatibility. But the dogma was strong.
Indeed they wanted to be the Java of PHP. And so inefficient. Imagine duplicating all variables of a request context for dogmas sake. So you can later do Request->getVar() from their own copy. It shows a basic not understanding of the language.
I can be more specific: I'm identifying problems with the language ecosystem.
I deliberately didn't shit on the people involved; I'll definitely ride the #not-all-php-programmers (I've met some great ones), but it takes a broken mind to accept a toolchain this historically fallible as something with which you'd want to recreate the Java ecosystem. ;-)
Have you tried Java?
It's definitely a better Java than PHP!
Who gives a shit about SOLID or OO.
I used to love PHP for its simplicity. That was before zealots of your type flooded the ecosystem.
You wanted to apply what they taught you in uni, which was Java, to PHP. PHP was fine before. I earned good money with it and had fun doing so. Then 2010 the next generation of clueless devs enters the scene, polluting it with their nonsense.
Very much what's happening in Go right now with the cloud microservices fetish.
Can't you booksmart idiots STFU for once and let people do the pragmatic and sensible approach?
Fucking Hipsters
The people who care about and are tasked with maintaining a large long running code base.
> You wanted to apply what they taught you in uni, which was Java, to PHP.
Nope, that came after my time.
> Can't you booksmart idiots STFU for once and let people do the pragmatic and sensible approach? I earned good money with it and had fun doing so. Then 2010 the next generation of clueless devs enters the scene, polluting it with their nonsense.
Those OO & OOP principles are the pragmatic and sensible approach learned after cleaning up after "hipster" web "artisans". If we're going to throw around claims without knowing anything about the other person; you sound like the kind of dev who writes some code that works on the happy path, but is completely unmaintainable and non-extensible.
(But I know nothing about you, so I really have NFI, just like you have NFI about me and what I do)
Laravel was the first framework, that "just worked" and had everything, you need to make your first steps in a web application. Nowadays, people write PHP components that are usable in Laravel and that means a lot of code out there is compatible to a lot of other code. That alone did a lot to the PHP community. 2010 or so, the PHP landscape was much more scattered and things didn't look good.
Since then a lot happened and Laravel carries old stuff with it, and I'm very happy about that! I'd hate to be forced to do big refactoring work on every update of the framework. As strange as some decisions in Laravel are, they try new things, and they also try to stay compatible to the old stuff. Between Laravel 5.5 (released 2017) and 10 there were not much breaking changes. For a framework, this is a big plus.
My experiences with cake and zend back ... 10-12+ years ago... things 'worked' mostly, but there was often a lot of "you can do it any way you want", and often minimal examples for the cases I was trying to achieve. Testing... as much as it was there, my experiences trying to get decent testing never seemed to work very well; Laravel's testing experience felt better out of the box. Testing traits like 'useDatabaseTransaction' to rollback the db after each test seemed both useful and novel - I don't remember seeing things like that in Cake (at least not early on - haven't checked recently).
FWIW, I use Laravel a lot these days, but wasn't terribly 'trusting' of it early on. Started seeing it in what I guess were its 3.x days; then saw 4.x - big changes, and what seemed like a moderate amount of BC breakage, then again from 4-5. Around 5.x, it seemed to adopt a bit more of an incremental approach to changes, and I started using it more day to day in the 5 series.
Laravel was awful when everyone else were awful. But around Laravel 5.5 (and PHP 7) it was complete enough, documented enough and fast enough, that you could just start building stuff with it without having to think about it. Is Laravel the best Framework out there? Not at all! But is also not considered harmful, far from it.
- so. many. godobjects.
- I dislike ORMs. I could not put my finger on it, while using PHP frameworks, because they were omni-present; but after using Python, Go, and C#, I found it to be easier for me to just avoid the overhead of an ORM.
- Terrible structure. Sorting classes by type is something I have experienced to be generally less helpful than sorting by "topic" (not a native speaker, so this might not be the correct word for it. I recently heard it compared to collecting cars, then disassembling them and sorting by tires, steering wheels, seats, and so on)
- Too much magic™. I understand that many like this about it, but I found it harder to understand what exactly the program is doing.
It's not a lot, but after literally years of PHP and having these paper cuts almost weekly, I was at one point fed up. I first switched to CodeIgniter, which I found more pleasant, but still not even comparable to the comfort that cherry-picking components gets you (yes, you can by using composer, but most people I have spoken to discouraged that in favour of Laravel's built-in fun).
A technical decision should be done by weighting it's pros and cons, not just by looking at the pros.
Agree on the 'Sorting classes by types', it's something I've always found surprising too, and love the car-collection metaphor.
You can almost hear one of these dudes say it.
https://m.youtube.com/watch?v=njUa_1FY8rA&pp=ygUPVGhlIGhvYmJ...
Goooravell...
IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
The standard library defines some decent interfaces already around HTTP handling and SQL calls. Most libraries are built to integrate with them. Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses.
This means that usually you're composing libraries and some application code together, rather than building everything on top of some jack of all trades framework. You get to choose the best tool for each job.
Yeah, that’s not the hard part at all. What about routing, converting from/to json/params/cookies safely, sessions, authz/n..
> What about routing, converting from/to json/params/cookies safely All supported out of the box with the standard library. It's also table stakes, and not the hard part.
> sessions, authz/n
This is where you need to step out of the standard
genuinely interested in knowing why it is so. I quite like Go, but I also like Django, so I would like to know why a Django-like ORM would not be feasible.
The main reason, in my opinion, comes down to how Go as a language was designed. I have written some follow up posts to that, specifically this one: https://andrewpillar.com/programming/2022/10/24/a-simple-cru... wherein I explore creating an ORM-like library via generics in Go, this may be of interest to you if you want a better understanding of how some of these things would work in Go.
But if you look at how it works in Python, it's by taking over class definitions in such a way that a field can be both a description of the field and an actual value. That doesn't work in Go (explicit casting the fields at every place you use them could work, but is prone to errors). It "cleverly" overrules operators to turn something like the Python expression `age > 50` into the sql string `age > 50`. Can't be done in Go, unless you define functions for all operators and find a way to reflect on the field name and the current context (`gt("age", 50)`). That's a lot of work to turn one string into the same one. URLs can't be linked to a class by simply importing a file; you'd need to add quite a bit of scaffolding (a factory for each class with a common interface, I guess?). And there are other parts that rely on annotation and whatever that simply can't be ported to Go, so you'd have to turn them into function calls. And Django doesn't give you more than a glorified POST form app out of the box anyway. You have to add more views and serializers to turn it into a modern backend, so why not skip that and use libraries that implement the functionality you do need.
Ok, my dislike shines through, but the gist is that Go doesn't let other code take over the interpretation of the meaning of expressions and statements and inject things into classes like Python does. It all has to be done explicitly. So django-like functionality for Go would have to look very different.
I was just asking specifically about the ORM part. The subject of "use an opinionated framework vs. tie specialized libraries together" is a complete different debate.
But about this matter: I quite like to assemble libraries when I'm solo on a personal project. But that's definitely not something I want in a team. That's pretty much why we go with Django and not Flask or any of the "lightweight", "micro" framework things that are everywhere. "Just bring whatever ORM you want", "Use whatever template engine you like", etc. But that's a lot of decision making and integration with no added value for us. The fact that Go has such a comprehensive standard library is a good thing, but probably not enough because, like you wrote:
> you'd need to add quite a bit of scaffolding
(Which obviously contradicts the idea that Django brings just a glorified POST form app to the table)
As to why I'm interested in Go: faster execution, less memory, easier deployment... but as a small shop, team productivity still comes first.
But Go doesn't have one framework that pretends to do it all. And IMO, django just pretends. Want to turn your GET/POST-based views into JSON/REST-like endpoints? Add a library, and two extra modules per data type. Want to do something slightly more complicated with the database? Be prepared to write a bunch of code, or look for a library that understands tree/graph-structures. Want to integrate Angular or React? Add another library or two. File conversion? Charting? Monitoring? Repeated tasks? Packing static files? Moving images into the right place for deployment? You get the picture.
You may have to good reasons to pick django for your team, but it sounds a bit like you're outsourcing the architecture, hoping that django suffices and the community can support you. But if you understand the needs of your (web) service, flask or basic 'requests' or fastapi are not such bad starts. Once you're at that point, Go's web frameworks can look quite similar, so I'd recommend that if you ever take that step.
There are some well-established web frameworks for Go (e.g. https://github.com/gin-gonic/gin), but they are controversial too, as most Go developers seem to prefer libraries (that your code calls) instead of frameworks (that call your code and impose their structure upon it). So I don't think just cramming a framework from a completely different language into Go will fly...