Re:Show HN: Copper – A Go framework for your projects
by melony on Saturday July 02, 2022 @11:35AM
(#31959901)
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 is better by several orders of magnitude.
[ Parent
| on HN ]
Re:Show HN: Copper – A Go framework for your projects
by jitl on Saturday July 02, 2022 @12:27PM
(#31960361)
Models change pretty slowly, so codegen is a good solution! Ent uses codegen for its query API which looks pretty nice: https://entgo.io/docs/tutorial-todo-crud
I’m considering writing a Typescript clone of Ent with codegen powered by Typescript types. I like codegen over dynamic magic because the runtime behavior is often easier to understand. In Rails, I need to traverse a lot of space in Pry’s debugger mode to figure out WTF is happening. I would much rather have codegen.
Re:Show HN: Copper – A Go framework for your projects
by morelisp on Saturday July 02, 2022 @01:00PM
(#31960641)
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
by hrgiger on Saturday July 02, 2022 @01:12PM
(#31960725)
Agree reflection has (often big) trade offs but its not as bad as it was years ago, especially if its used during construct time rather than runtime, if you combine it with runtime caches you still get the benefits imo