Live data from Hacker News

Some Go web dev notes

jvns.ca

61–70 of 154 posts

Re: Some Go web dev notes

#61

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

Templ [1] is great!

Another go mod that helps a lot when massaging JSON (something most web servers end up doing sooner or later) is GJSON [2].

--

1: https://github.com/a-h/templ

2: https://github.com/tidwall/gjson

Re: Some Go web dev notes

#62
post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

You should never do blind retries in an infinite for loop, ideally it should be a generic retry function ( bounded ) that type check the error.

Re: Some Go web dev notes

#63

Earlier quoted context omitted.

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either. I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very har…

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

There is a world of difference between having to install python, libraries (some of them may require C-based libs and compiling, therefore also install gcc), then configure wsgi, hope it doesn't clash with other python versions or have docker and containers... or just generating a fat binary in go.

Re: Some Go web dev notes

#64
post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

Transactions are hard, and in reality there's a shit-ton of things people do that has no right to be close to a transaction (but still are), and transactions were a good imperative kludge at the time that has just warped into a monster that people kinda accept over the years.

A loop is a bad construct imho, something I like far better is the Mnesia approach that simply decides that transactional updates are self-contained functional blocks and the database manages the transactional issues (yes, this eschews the regular SQL interfaces and Db-application separation but could probably be emulated to a certain degree).

https://www.erlang.org/doc/apps/mnesia/mnesia_chap4.html

Re: Some Go web dev notes

#65
post #62
post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

You should never do blind retries in an infinite for loop, ideally it should be a generic retry function ( bounded ) that type check the error.

Yes, that's exactly what the linked code does: Calls your function, and if it returns an error, check through the wrapped errors to see if it's one of the SQLite errors which should be retried. If it is, try the transaction again; if not, pass the error up.

Re: Some Go web dev notes

#66
post #48
post #7

Earlier quoted context omitted.

I agree but those first 5 days are going to be a mixed bag as you pick through libraries for logging, database drivers, migrations, as well as project organization, dependency injection patterns for testing, organize your testing structure, and more. If you have a template to derive from or sufficient Go experience you'll be fine, but selecting from a grab bag of small libraries early on in a project can be a distrac…

I think 80% of this is people coming to Go from other languages ( everybody comes to Go from some other language) and trying to bring what they think was best about that language to Go. To an extent unusual in languages I've worked in, it's idiomatic in Go to get by with what's in the standard library. If you're new to Go, that's what you should do: use standard logging, just use net/http and its router, use standard…

I completely agree with the comment, except for the Flask example. Django would be a better example.

Both Flask and Golang's http package have simplicity and minimalism as their philosophy. Of course, most mature projects will eventually diverge from that. But both can start out as a single file with just a few lines of code.

Re: Some Go web dev notes

#67
post #3

What I love about Go is its simplicity and no framework dependency. Go is popular because it has no dominating framework. Nothing wrong with frameworks when it fits the use case but I feel that we have become over dependent on framework and Go brings that freshness about just using standard libraries to create something decent with some decent battle tested 3rd party libraries. I personally love "library over framewo…

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either. I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very har…

> (actually not very hard, but intimidating if you've never done it before)

These stuff are never really hard, but you will make countless vulnerabilities that way. The most important job of a good framework is cutting down significantly on the possible to get wrong use cases, exposing you to already safe APIs.

Re: Some Go web dev notes

#70
post #49

the whole gobin / gopath thing was annoying as a beginner: I just want to build this module and use that local module go build ./... Goes where ?

I believe it is recommended to not use gobin/gopath anymore. go test ./… tests all files in the project, so I assume build does something similar.

My experience with go build ./... is that it compiles everything but it doesn't make the binaries.

> When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.

From https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependenc...

A bit annoying when you want to build a bunch of executables, but it's not something I need often and it's easy to script.

Post reply on HN