Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Copper – A Go framework for your projects

github.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Show HN: Copper – A Go framework for your projects

#41

Post by xyzzy_plugh »

melony wrote: post #29
swagonomixxx wrote: post #26

Earlier quoted context omitted.

Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things. Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on. Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on. In my 8 years of writing Go, I w…

Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.

As the post you're replying to describes, magic is antithetical to Go idioms. An ORM is basically database-as-magic, every ORM in Go is just a nightmare.

Something like sqlc[0] is leagues better than any ORM in terms of simplicity, complexity and maintainability.

0: https://github.com/kyleconroy/sqlc

Re: Show HN: Copper – A Go framework for your projects

#42

Post by tusharsoni »

synergy20 wrote: post #31

So go is trying to be a server-side-render framework here, what about the SPA style in that go is a simple json-api server, and let SPA to do all the template and render, is gin the best framework for that? new to golang here.

I think that remains a very valid use case. In Copper, you can create one of those with the CLI. For example `copper create -frontend=vite:react github.com/nasa/starship` will create a react app with a JSON backed API ready to go

Re: Show HN: Copper – A Go framework for your projects

#43

Post by tusharsoni »

andrewstuart2 wrote: post #40
melony wrote: post #29

Earlier quoted context omitted.

Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.

If you're using postgres, I'm a major fan of the anti-ORM (ROM?) that is sqlc. Nothing I've used comes in Go close in productivity or safety (and ability to write proper queries but use them very simply, and stay up-to-date without too much extra toil). Last I checked they're also working on adding sqlite support. https://github.com/kyleconroy/sqlc/

They're on top of my list to add to Copper. As soon as we get sqlite support!

Re: Show HN: Copper – A Go framework for your projects

#44

Post by matthewmueller »

melony wrote: post #29
swagonomixxx wrote: post #26

Earlier quoted context omitted.

Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things. Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on. Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on. In my 8 years of writing Go, I w…

Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.

I think an ORM like https://github.com/xo/xo with https://sqlc.dev/ as a fallback for complex queries will be a killer combo!

Re: Show HN: Copper – A Go framework for your projects

#46

Post by synergy20 »

dangelov wrote: post #34
synergy20 wrote: post #31

So go is trying to be a server-side-render framework here, what about the SPA style in that go is a simple json-api server, and let SPA to do all the template and render, is gin the best framework for that? new to golang here.

I've been using Mux & sqlc in a few projects and it's working out great.

both look interesting, "Mux is looking for new Maintainers"

Re: Show HN: Copper – A Go framework for your projects

#48

Post by morelisp »

lordofgibbons wrote: post #33
melony wrote: post #29

Earlier quoted context omitted.

Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.

What about the Ent ORM library? https://entgo.io/

Ent can replace an ORM in your architecture, and it's easiest to explain in two seconds as "an ORM for Go", but it's not really that. It's a way to describe a persistent object graph, without any reference to persistence or mapping details. When your chosen persistence layer is an RDBMS, as it often is, then it uses an ORM - but you rarely interact with it at that level even when specify your entity schemas. You can back it with an object DB or REST API instead and then it wouldn't need the RM part at all.

Re: Show HN: Copper – A Go framework for your projects

#49

Post by morelisp »

melony wrote: post #27
tusharsoni wrote: post #23

Earlier quoted context omitted.

This is a good observation. One trend I'm noticing is that the "old way" (PHP, Rails, etc.) of doing things is making a comeback. Go is very well positioned for this but lacks the frameworks. I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to f…

Go and Java can never use the same framework patterns as Python/Php/Elixir/Ruby/JS because they are not dynamic enough. The Rails-style request mapped dispatching into active record ORM pattern requires a lot of flexibility on the host language side. For Go and Java, you basically end up with code generation or reflection, and the latter is a killer for performance. On the other hand, the performance of Go and Java i…

Reflection is killer for performance because it brings Java/Go down to the level of a JIT-less language like Python (and ORMs aren't too kind to JITs in e.g. Ruby/JS either). The problem with reflection in Go/Java is mostly that it's hard to read, since the reflection-ful APIs are hosted rather than native syntax.

Re: Show HN: Copper – A Go framework for your projects

#50

Post by matthewmueller »

bestinterest wrote: post #22

So many frameworks in other languages are trying to get to the productivity of Rails but they just don't have the same spark imo. There is no Rails equivalent in JS, theres lots of competitors that feel years away like SailsJS, the new Deno Fresh one etc, Adonisjs... Is NextJS/SvelteKit/RemixRun considered also? I don't even know if they have a standardised background job processor in JS land. Java's solutions are dr…

Bud author here, thanks for including Bud on your list. That's a really good overview of the landscape!

My take is that Remix + Next.js + SvelteKit are going to continue to innovate fast in the Frontend and "Backend for Frontend" space. Rails and Laravel don't hold a candle to the experience you get in that ecosystem.

But the JS ecosystem is massive and, as a result, fragmented. As you mentioned, there's no consensus on ORMs, mailers, queues, etc.

I don't see those frameworks trying to push too far in that direction, they'll remain "UI focused". This is nice for their focus, but not great for someone who wants to launch a web app and doesn't want to figure out all the surrounding ecosystem tooling.

This is where Laravel, Rails (and soon Bud) (and I assume Copper) will shine. They provide more tools and interfaces out of the box for building full-featured backends. These frameworks definitely need to keep an eye on the best ideas coming out of the JS framework ecosystem though!

Post reply on HN