11 ms·

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 t

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.

weatherlite 2y ago
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?
- JodieBenitez 2y ago
  We now have GO's equivalent of Rails and Go's equivalent of Laravel. Apparently Go's way is "start with the standard lib and glue whatever you need on top".
- kflgkans 2y ago
  > If I want an all inclusive MVC (or similar) web development framework with all batteries included I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just get in the way.
  - weatherlite 2y ago
    > It's quite easy to do most things you would want by just writing some code OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build? Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.
    - kflgkans 2y ago
      I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).
    - desumeku 2y ago
      > I want a similar thing to ActiveRecord First of all, you shouldn't be using Go, because it's not the language where you do those kinds of things.
- todotask 2y ago
  JavaScript (Too many to list) TypeScript has NestJS (among others) Elixir has Phoenix
- anta40 2y ago
  Even when using frameworks, typically Go devs, from what I see, prefer something simpler, like Fiber or Echo. Then they plug any libraries the like on top of it.
- ayuhito 2y ago
  The standard library. It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.
  - 9dev 2y ago
    I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing other developers to get productive immediately. Comparing that to the go standard library is apples to skyscrapers.
    - ayuhito 2y ago
      Almost everything you listed already exists in the standard library. And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary. There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.
      - tredre3 2y ago
        > Almost everything you listed already exists in the standard library. That's a bold faced lie. In the list, the only things provided by Go are: - routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough). - template: it's not even close to laravel's blade capabilities, but yes Go has good enough templating for most tasks.
        ayuhito 2y ago
        > routing, middleware net/http (even middlewares are just http.HandleFunc) > database connections We were using database/sql for the longest of times before switching to pgx since we wanted some convenience functions. > email sending net/mail gets you far enough unless you want to scale it. > logging log/slog (which is actually production grade compared to log/log) > view template rendering text/template, but I also think Laravel is a better choice if that’s your main focus. Others either need an experimental standard library package (e.g. golang.org/x/crypto/argon2 for stuff like authentication) or finally need third party dependencies. DI is not enforced like other frameworks, but an extremely common pattern in Go. At this point, do I really want to bring out a whole framework just for the last few requirements?
- bborud 2y ago
  Go has a simpler approach that encourages you to express yourself more directly, does away with heavy frameworks that take longer to learn than the language itself, and it encourages you to structure solutions in mechanical sympathy with the problem rather than start with a solution and then try to adapt the problem to a given solution. Big frameworks are extremely limiting. They also make escape harder when you realize how limiting they are. I tried to like various frameworks during my time as a Java developer, but they always end up costing projects more than what they save. In terms of time, clarity, performance, adaptability and maintainability. Decades ago I too used to think they might help, but I was never able to observe any real positive effects over time. You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution. The reason Go feels more productive than Java is because in Go the community seems to understand this fairly well. So the whole ecosystem is built around libraries that are easy to compose rather than frameworks that try to coerce you. Big frameworks are not really helpful. At best, they are occasionally fashionable, which tricks people into thinking they are better off solving problems the wrong way around.
  - halfcat 2y ago
    This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes. The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you need to split from the framework’s convention, you have unlimited escape hatches. If you want a case study, see Instagram.
    - bborud 2y ago
      > “we don’t need a package manager, we write everything ourselves” vibes Then I'm afraid you misunderstood. Frameworks is not the only way to build things efficiently. It is actually possible to build things using libraries and consistent ways of structuring things. Also, we're talking about Go, so please use Go examples. Django isn't interesting in this context. Have a look at how you'd leverage the standard library, and perhaps a couple of libraries in Go to do the same.
- 7bit 2y ago
  I live Django, but you cant compare it to Latavel, which is much more extensive
- reactordev 2y ago
  Go has go. You don’t need a framework when http can do pattern routing and cookies, database/sql can do data, and json is baked in. It was literally designed to do away with this choice confusion and provide one path to servicedom.
- debuggerpk 2y ago
  go has go, and for ORM, it is better to go with sqlc.
todotask 2y ago
In my experience building the site with Go (Echo) with Postgres and a vanilla frontend from scratch, I realised that maintaining my codebase as a solo developer for a medium-sized platform was challenging. At one point, it became unmaintainable, and I had to rewrite it three times. The third time? I switched to the Astro web framework, and it solved all my problems. Go is indeed easy to get started with, but it's different when dealing with server-side rendering and not a single-page application where Go is a backend.
- bborud 2y ago
  Can you go into a bit more detail about what became challenging and what Astro helped you solve?
  - todotask 2y ago
    At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a buggy Marvelous app. Managing both sides while constantly adapting to shifting requirements became exhausting. To ease the burden, I introduced Alpine.js, which helped, but the real challenge was juggling Go and TypeScript for different parts of the stack. When the team decided to revamp the site with a new Figma design, I switched to Astro after the release of Astro 2.0—it simplified frontend development and allowed me to gradually move away from Go. This wasn’t just about adopting a new language with old patterns; it was about making my workload sustainable while improving maintainability. A month later (after three years), bad news—they ran out of funding and had no time for marketing. On top of that, I have vision problems (genetic and post-cataract surgery), making job options limited. But one thing I’ve gained from this experience is a strong grasp of frontend performance optimisation—JavaScript, Tailwind CSS, HTML, and responsive images. There are millions of poorly optimised websites that Astro could improve. At least in Singapore, where we have great internet connectivity, I can keep refining my skills. Astro solved: - Same codebase: Both frontend and backend with TypeScript, meaning I no longer have to write routers whenever we add a new category. - Optimisations: Reducing JavaScript and loading JavaScript as a module for better security. - Maintainability: Go HTML templating was harder to maintain; I prefer Astro’s JSX-like syntax. - Performance: If I need performance, Bun can be as performant as Go, which is a bonus. - Reusability: Lots of UI and Astro components can be reuse. - Productive (Future): I’m waiting for Vite (Rolldown) to speed up my build times. Evan You has lots of ideas for Rolldown plugins. - Community: Of course, an active community that is improving Astro so we don’t have to reinvent the wheel, with lots of sensible features by default, including Starlight for docs. I proposed to the Echo maintainer to adopt it over Docusaurus, but I was turned down.

weatherlite 2y ago

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?

JodieBenitez 2y ago
We now have GO's equivalent of Rails and Go's equivalent of Laravel. Apparently Go's way is "start with the standard lib and glue whatever you need on top".
kflgkans 2y ago
> If I want an all inclusive MVC (or similar) web development framework with all batteries included I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just get in the way.
- weatherlite 2y ago
  > It's quite easy to do most things you would want by just writing some code OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build? Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.
  - kflgkans 2y ago
    I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).
  - desumeku 2y ago
    > I want a similar thing to ActiveRecord First of all, you shouldn't be using Go, because it's not the language where you do those kinds of things.
todotask 2y ago
JavaScript (Too many to list) TypeScript has NestJS (among others) Elixir has Phoenix
anta40 2y ago
Even when using frameworks, typically Go devs, from what I see, prefer something simpler, like Fiber or Echo. Then they plug any libraries the like on top of it.
ayuhito 2y ago
The standard library. It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.
- 9dev 2y ago
  I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing other developers to get productive immediately. Comparing that to the go standard library is apples to skyscrapers.
  - ayuhito 2y ago
    Almost everything you listed already exists in the standard library. And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary. There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.
    - tredre3 2y ago
      > Almost everything you listed already exists in the standard library. That's a bold faced lie. In the list, the only things provided by Go are: - routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough). - template: it's not even close to laravel's blade capabilities, but yes Go has good enough templating for most tasks.
      - ayuhito 2y ago
        > routing, middleware net/http (even middlewares are just http.HandleFunc) > database connections We were using database/sql for the longest of times before switching to pgx since we wanted some convenience functions. > email sending net/mail gets you far enough unless you want to scale it. > logging log/slog (which is actually production grade compared to log/log) > view template rendering text/template, but I also think Laravel is a better choice if that’s your main focus. Others either need an experimental standard library package (e.g. golang.org/x/crypto/argon2 for stuff like authentication) or finally need third party dependencies. DI is not enforced like other frameworks, but an extremely common pattern in Go. At this point, do I really want to bring out a whole framework just for the last few requirements?
bborud 2y ago
Go has a simpler approach that encourages you to express yourself more directly, does away with heavy frameworks that take longer to learn than the language itself, and it encourages you to structure solutions in mechanical sympathy with the problem rather than start with a solution and then try to adapt the problem to a given solution. Big frameworks are extremely limiting. They also make escape harder when you realize how limiting they are. I tried to like various frameworks during my time as a Java developer, but they always end up costing projects more than what they save. In terms of time, clarity, performance, adaptability and maintainability. Decades ago I too used to think they might help, but I was never able to observe any real positive effects over time. You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution. The reason Go feels more productive than Java is because in Go the community seems to understand this fairly well. So the whole ecosystem is built around libraries that are easy to compose rather than frameworks that try to coerce you. Big frameworks are not really helpful. At best, they are occasionally fashionable, which tricks people into thinking they are better off solving problems the wrong way around.
- halfcat 2y ago
  This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes. The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you need to split from the framework’s convention, you have unlimited escape hatches. If you want a case study, see Instagram.
  - bborud 2y ago
    > “we don’t need a package manager, we write everything ourselves” vibes Then I'm afraid you misunderstood. Frameworks is not the only way to build things efficiently. It is actually possible to build things using libraries and consistent ways of structuring things. Also, we're talking about Go, so please use Go examples. Django isn't interesting in this context. Have a look at how you'd leverage the standard library, and perhaps a couple of libraries in Go to do the same.
7bit 2y ago
I live Django, but you cant compare it to Latavel, which is much more extensive
reactordev 2y ago
Go has go. You don’t need a framework when http can do pattern routing and cookies, database/sql can do data, and json is baked in. It was literally designed to do away with this choice confusion and provide one path to servicedom.
debuggerpk 2y ago
go has go, and for ORM, it is better to go with sqlc.

todotask 2y ago

In my experience building the site with Go (Echo) with Postgres and a vanilla frontend from scratch, I realised that maintaining my codebase as a solo developer for a medium-sized platform was challenging. At one point, it became unmaintainable, and I had to rewrite it three times. The third time? I switched to the Astro web framework, and it solved all my problems. Go is indeed easy to get started with, but it's different when dealing with server-side rendering and not a single-page application where Go is a backend.

bborud 2y ago
Can you go into a bit more detail about what became challenging and what Astro helped you solve?
- todotask 2y ago
  At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a buggy Marvelous app. Managing both sides while constantly adapting to shifting requirements became exhausting. To ease the burden, I introduced Alpine.js, which helped, but the real challenge was juggling Go and TypeScript for different parts of the stack. When the team decided to revamp the site with a new Figma design, I switched to Astro after the release of Astro 2.0—it simplified frontend development and allowed me to gradually move away from Go. This wasn’t just about adopting a new language with old patterns; it was about making my workload sustainable while improving maintainability. A month later (after three years), bad news—they ran out of funding and had no time for marketing. On top of that, I have vision problems (genetic and post-cataract surgery), making job options limited. But one thing I’ve gained from this experience is a strong grasp of frontend performance optimisation—JavaScript, Tailwind CSS, HTML, and responsive images. There are millions of poorly optimised websites that Astro could improve. At least in Singapore, where we have great internet connectivity, I can keep refining my skills. Astro solved: - Same codebase: Both frontend and backend with TypeScript, meaning I no longer have to write routers whenever we add a new category. - Optimisations: Reducing JavaScript and loading JavaScript as a module for better security. - Maintainability: Go HTML templating was harder to maintain; I prefer Astro’s JSX-like syntax. - Performance: If I need performance, Bun can be as performant as Go, which is a bonus. - Reusability: Lots of UI and Astro components can be reuse. - Productive (Future): I’m waiting for Vite (Rolldown) to speed up my build times. Evan You has lots of ideas for Rolldown plugins. - Community: Of course, an active community that is improving Astro so we don’t have to reinvent the wheel, with lots of sensible features by default, including Starlight for docs. I proposed to the Echo maintainer to adopt it over Docusaurus, but I was turned down.