Live data from Hacker News

Show HN: Copper – A Go framework for your projects

github.com

51–60 of 86 posts

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

#51

Earlier quoted context omitted.

You definitely don't need a framework to get the user name out of a URL, you need one line of code.

And what would that line of code be? As far as I am aware you have to parse the URL string, and it only gets more complicated when you add more URL parameters. Which definitely leads to boilerplate code shared across projects.

It's also not especially performant to do the naive (i.e. short) implementation like this, since you'll likely end up parsing/processing path elements left-to-right rather than in whatever order makes the most sense for your loading.

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

#52
post #27

Earlier quoted context omitted.

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.

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

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

#53

Earlier quoted context omitted.

You definitely don't need a framework to get the user name out of a URL, you need one line of code.

And what would that line of code be? As far as I am aware you have to parse the URL string, and it only gets more complicated when you add more URL parameters. Which definitely leads to boilerplate code shared across projects.

Assuming the url is formatted correctly:

  strings.Split(urlString, "user/")[1]
https://go.dev/play/p/tWi-Ge0CA1X

That's one way to do it.

>more URL parameters

I thought thats what http.Request.ParseForm() was for (assuming correct formatting)

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

#54

Earlier quoted context omitted.

And what would that line of code be? As far as I am aware you have to parse the URL string, and it only gets more complicated when you add more URL parameters. Which definitely leads to boilerplate code shared across projects.

Assuming the url is formatted correctly: strings.Split(urlString, "user/")[1] https://go.dev/play/p/tWi-Ge0CA1X That's one way to do it. >more URL parameters I thought thats what http.Request.ParseForm() was for (assuming correct formatting)

> Assuming the url is formatted correctly

... is like, a core job of an HTTP router? You're not just begging the question, you're beating someone up and rifling through their pockets for it.

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

#55

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…

A rails-like framework will never happen in a language that doesn’t have the same meta programming capabilities as Ruby. Rails exists because Ruby exists not because DHH just happened to be a Ruby programmer. There is a reason people have tried to recreate it in other languages and it always feels jank - because Rails is designed specifically and enabled by the Ruby language.

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

#56

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…

A rails-like framework will never happen in a language that doesn’t have the same meta programming capabilities as Ruby. Rails exists because Ruby exists not because DHH just happened to be a Ruby programmer. There is a reason people have tried to recreate it in other languages and it always feels jank - because Rails is designed specifically and enabled by the Ruby language.

Code generation provides the same kind of flexibility you get with meta programming, you just need to do more work to keep generated code in sync and out of the way.

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

#57
post #29

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.

SQL is an incredible language with decades of theory and implementation behind it. I have never found an ORM to be better or faster or more useful than hand-written SQL for anything but the simplest of queries, and even then the benefit is debatable.

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

#58

Cool project. I'm currently building something similar to hacker news using only the standard library. How could this project help me? The way I use the standard library is like a super condensed version of React. Templates are my components. Since templates can be nested, templates can be used to build "components" and those components can be stored in separate files and compiled together at run time with a "model"…

In what sense is this like React? Incremental re-rendering using html/template or text/template was virtually impossible last time I looked into it (for improving performance of some report generation), let alone getting any kind of DOM tree structure out.

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

#60
post #29

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.

Orms are a huge mistake.

SQL is already a very high level API that compiles to low level algorithms? Why put another very high level API on top of that?

To top it off SQL is a leaky abstraction by nature. Two high level SQL queries with equivalent results can both compile into algorithms with COMPLETELY different performance profiles. You have to manipulate the SQL query to generate the correct performance profile. This means understanding things below the SQL abstraction.

You put a ORM or any new abstraction on top of that guess what? That abstraction must compile into hacked SQL. You have to be able to manipulate the ORM such that it generates the correct SQL such that the correct SQL generates the algorithm with the correct performance profile. The leak from the sql abstraction must propogate into the ORM layer which in itself must be a leaky abstraction. It's like dealing with a leaky pipe embedded within another leaky pipe.

Optimizing SQL is already a domain knowledge thing. Now you have to use new tricks to optimize the abstraction on top of it. Two Leaky abstractions on top of each other and both very high level is a bit of a head scratcher.

Why do people even make these abstractions that only make life harder? I think it's an illusion. It's to satisfy an OCD thing but people don't realize the OCD is an illusion. People want to deal with a single language, not have strings of another language living in the code. For example, SQL strings are seemingly kind of ugly in something like GO code.

Databases are the classic bottleneck of web development in terms of speed. Optimization is a very important part of writing SQL queries as a result. Having orms and other high level abstractions on top of this area is much much more harmful then it otherwise would be if databases did not exist in this bottle-necked area of web development.

In actuality it's also questionable whether or not a leaky abstraction in the first place was the right design decision. Is SQL the right abstraction for database queries? Or should we design another high level API that has a more 1 to 1 correspondence with optimization as in a High level API that's not leaky, like What Rust is to systems programming.

Post reply on HN