[tusharsoni]

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 fix the lack of good templating.

[melony]

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.

[jitl]

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.

[morelisp]

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.

[treis]

They need to solve the same problems. They don't have to solve them in the same way.