Some Go web dev notes • Hacker News Board

Re: Some Go web dev notes

#121

Post by bbkane » Mon, Sep 30, 2024, 2:26 PM UTC

maleldil wrote: post #104

sureglymop wrote: post #88

Earlier quoted context omitted.

I would also say library quality can be generally low. E.g. there are numerous flag parsing libraries but not a single one comes even close to clap in rust.

spf13/cobra and urfave/cli are fine, I think. As sibling said, you can't expect Go to have something like Rust's clap because the metaprogramming capabilities are so different. On the other hand, I find it sad how terrible stdlib's flag library is. I'd love to have something like Python's argparse, which is not perfect but enough for most of the time. Go's flag doesn't even work well for small programs. It should've…

On the other hand, if you're looking for a side project, writing your own flag parsing library is a lot of fun! I've been sinking time into mine for a few years and it's always really satisfying to use in my CLIs

Re: Some Go web dev notes

#122

Post by peterldowns » Mon, Sep 30, 2024, 2:51 PM UTC

glenjamin wrote: post #111

peterldowns wrote: post #86

Earlier quoted context omitted.

I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your…

This looks excellent! The go tools for managing DB schema migrations have always felt lacking to me, and it seems like your tool ticks all of the boxes I had. Except for one: lack of support for CREATE INDEX CONCURRENTLY (usually done by detecting that and skipping the transaction for that migration). How do you handle creating indexes without this?

Thanks for taking a look!

Long-running index creation is a problem for pgmigrate and anyone else doing “on-app-startup” or “before-app-deploys” migrations.

Even at moderate scale (normal webapp stuff, not megaco size) building indexes can take a long time — especially for the tables where it’s most important to have indexes.

But if you’re doing long-running index building in your migrations step, you can’t deploy a new version of your app until the migration step finishes. (Big problem for lots of reasons.)

The way I’ve dealt with this in the past is:

- the database connection used to perform migrations has a low statement timeout of 10seconds.

- a long-running index creation statement gets its own migration file and is written as: “CREATE INDEX … IF NOT EXISTS”. This definition does not include the “CONCURRENTLY” directive. When migrations run on a local dev server or during tests, the table being indexed is small so this happens quickly.

- Manually, before merging the migration in and deploying so that it’s applied in production, you open a psql terminal to prod and run “CREATE INDEX … CONCURRENTLY”. This may take a long time; it can even fail and need to be retried after hours of waiting. Eventually, it’s complete.

- Merge your migration and deploy your app. The “CREATE INDEX … IF NOT EXISTS” migration runs and immediately succeeds because the index exists.

I’m curious what you think about this answer. If you have any suggestions for how pgmigrate should handle this better, I’d seriously appreciate it!

Re: Some Go web dev notes

#123

Post by peterldowns » Mon, Sep 30, 2024, 2:53 PM UTC

jrockway wrote: post #90

peterldowns wrote: post #86

Earlier quoted context omitted.

I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your…

I can definitely get behind using some other migration library! Thank you for writing and sharing this!

Thanks :) if you have the time, I’d sincerely appreciate feedback on it and especially on its docs/readme, even a simple github issue for “this is confusing” or “this typo is weird” would be really helpful.

Re: Some Go web dev notes

#124

Post by peterldowns » Mon, Sep 30, 2024, 2:55 PM UTC

domano wrote: post #100

peterldowns wrote: post #86

Earlier quoted context omitted.

I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your…

Bold of you to flat out drop down migrations. I guess having a new up migration to cover the case is better, but its nice to have a documented way of rolling back (which would be the down migration) - without applying it programmatically. But it helps if other team members can see how a change should be rolled back ideally.

Glenjamin gave a great answer. I’ll just add that in my experience (being responsible for the team’s database, at a few companies over the years), down migrations are NEVER helpful when a migration goes wrong. Roll-forward is the only correct model. Besides, there are plenty of migrations that cant be safely rolled back, so most “down migrations” either destroy data or don’t work (or both.)

Re: Some Go web dev notes

#125

Post by sureglymop » Mon, Sep 30, 2024, 4:00 PM UTC

maleldil wrote: post #104

sureglymop wrote: post #88

Earlier quoted context omitted.

I would also say library quality can be generally low. E.g. there are numerous flag parsing libraries but not a single one comes even close to clap in rust.

spf13/cobra and urfave/cli are fine, I think. As sibling said, you can't expect Go to have something like Rust's clap because the metaprogramming capabilities are so different. On the other hand, I find it sad how terrible stdlib's flag library is. I'd love to have something like Python's argparse, which is not perfect but enough for most of the time. Go's flag doesn't even work well for small programs. It should've…

I have tried all of these. They all have their niceties but they also have their problems. They do not come close to clap in flexibility though. Argparse from python is nice, you're right. Thanks for explaining that, i'll look into how different the metaprogramming capabilities are.

Re: Some Go web dev notes

#126

Post by avinassh » Mon, Sep 30, 2024, 4:01 PM UTC

yegle wrote: post #13

It's sad https://pkg.go.dev/embed was not mentioned in a post about web development in Go :-) Having a true single binary bundling your static resources is so convenient.

it does mention it:

there’s just 1 static binary, all I need to do to deploy it is copy the binary. If there are static files I can just embed them in the binary with embed.

Re: Some Go web dev notes

#127

Post by sureglymop » Mon, Sep 30, 2024, 4:03 PM UTC

demi56 wrote: post #91

sureglymop wrote: post #88

Earlier quoted context omitted.

I would also say library quality can be generally low. E.g. there are numerous flag parsing libraries but not a single one comes even close to clap in rust.

You can’t just compare a library from another language, because they’re different, if all flag parsing library were inspired by Clap it’ll be a living nightmare for language that isn’t rust

Why can't I compare a library from another language? I have spent a significant amount of time with all of the popular flag parsing libraries in Go and none were as flexible yet easy to work with as clap. Anyway, I am not necessarily talking about syntax but moreso about the feature sets and overall quality.

Re: Some Go web dev notes

#128

Post by tomerbd » Mon, Sep 30, 2024, 4:29 PM UTC

zaptheimpaler wrote: post #81

I've been using go for a month now in a new job and hate it. It feels like they learned nothing from the past 20 years of language development. Just one huge problem is that they REPEATED Java's million/billion dollar mistake with nulls. The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all because the method returns "nil" for both these cases. They could've…

Not to talk about the lack of sake error handling in Go.

Re: Some Go web dev notes

#129

Post by coffeeindex » Mon, Sep 30, 2024, 5:12 PM UTC

sethammons wrote: post #79

trustno2 wrote: post #56

Other note Sooner or later you will hit html/template, and realize it's actually very weird and has a lot of weird issues. Don't use html/template. I grew to like Templ instead

I am just trying Templ. I like what I am seeing for the most part. There are some tooling ergonomics to work out. Lots of "suddenly the editor things everything is an error and nothing will autoimport or format" back to mostly working. Click to definition goes to the autogenerated code instead of the templ file. Couple things like that. But soooooooooo much better to deal with code gen than html/template. That thing…

What’s so bad about html/template?

Re: Some Go web dev notes

#130

Post by leetrout » Mon, Sep 30, 2024, 5:20 PM UTC

pepelotas wrote: post #38

leetrout wrote: post #21

Earlier quoted context omitted.

I really don't understand the hate for a framework in "the community". I had stayed away from Go for about 3 years and I posted on r/golang asking if anything had popped up like a django in go and got nothing but hate. I chock it up to people enjoy writing the same boiler plate stuff over and over in their paid jobs where they have the time to do it. To your point, I've got my own set of libraries that I think are Th…

I liked gomega and ginkgo when I worked with it. But by virtue of running tests serially, the race detection becomes useless during testing, and I think it's a must have. Has it changed?

I have no idea. I never considered that it would affect using the race detector and it's been so long now I don't know that we cared / ran into this issue so no clue if it has been fixed.

Thanks for opening my eyes to this shortcoming.