111–120 of 170 posts
One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it. At the same time, my daily work demands Golang 80% of the time. I keep having mix feelings when having this dichotomy
> One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it Why can't you do that with anything?
Earlier quoted context omitted.
The ORM question is a very good example for the issue you describe. Laravel is great to get a CRUD app started right now , iterate very quickly, and leave implementation complexity to the framework. This isn’t the right tool for every job, but it shines at those where it is. For example, you can drop an engineer with Laravel experience in pretty much any Laravel codebase, since the conventions are so strong, they’ll…
> While you’re still researching the best SQL library for a project People do this? In every language I've worked with, there's practically just one SQL library to use. And you just write a query, execute it, and map some results. Very basic.
You manage (as few as possible) connections to a DBMS, create prepared statements, cache and transform results, lazily iterate over large result sets, batch writes, manage schema migrations, and more. It’s not very basic, unless you’re cobbling up a prototype.
> In every language I've worked with, there's practically just one SQL library to use.
Curious which languages that were. In practically all ecosystems I know, there are 2-4 contenders.
Earlier quoted context omitted.
Writing SQL against systems much larger than that used to be the norm. You are correct that "using the right tool at the right time" is important, and often, that right tool is SQL. Other times it's not. Unfortunately there are many developers who don't really know SQL, so every problem is ORM-shaped.
> used to be the norm. People also "used to" invest radioactive water and used radioactive cremes and toothpastes for health benefits in the 20's and 30's. So what's your point?
Moreover, any exaggerated example of a bygone time is unrelated, as many SQL-driven systems still exist today. I work on one such system which is much larger than the example given, and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against ActiveRecord, I use it regularly. It just takes a lot of discipline once you hit queries of a certain complexity.)
I love Go and I love Laravel, but I do find the naming an odd choice; it seems like borrowed clout. Especially so when Laravel's own name is a soft reference to the work of C.S. Lewis. Why not pick a unique, "Go-esque" name and still nod to Laravel in the title/description?
Goravel doesn't roll off the tongue either. They should have went with Gravel.
But... Yeah: I prefer "Gravel", too. Is there another project out there with that name?
/English nerd
I love Go and I love Laravel, but I do find the naming an odd choice; it seems like borrowed clout. Especially so when Laravel's own name is a soft reference to the work of C.S. Lewis. Why not pick a unique, "Go-esque" name and still nod to Laravel in the title/description?
Never got the point of porting X framework from Y language in order to > simplifying the learning curve for Y language developers You'll just end up writing the same old patterns in the new language as you did in the old one. Especially with Go, it's really easier to adopt the existing tooling (most of which is in the standard lib) than to port whatever concepts Laravel/PHP had.
Not sure there's a Go equivalent of Laravel, so not sure which tooling you suggest people adopt. If I want an all inclusive MVC (or similar) web development framework with all batteries included - why not build a Go Laravel? Python has Django Java has Spring (among others) C# has asp.net Ruby has Rails PHP has Laravel What does Go have?