Not sure I agree with most of this, but it's interesting to see another's approach to dealing with complexity.
The article correctly identifies complexity as the biggest problem with writing complex long-lived web applications, but then presents a series of ad-hoc solutions to specific problems (problems caused by the structure they have chosen) as the best answer. It would probably be better titled 'Things I learned writing go' or something similar, rather than attempting to frame different decisions trade/offs as anti-patterns.
To take one example, having one user model is good in that it is easier to maintain and less complex to think about, but the author advocates having a write model and an api model - in some circumstances that might be useful (where there are many private fields which must never leak to the view or require processing before presentation), but most of the time it's overkill and needless complexity.
I don’t understand why people try to unit test handlers. Use integration tests for this and the real services you depend on, use unit tests to test functions and business logic, not glue code like handlers. If you build a vast complex web of mocks attempting to reproduce behaviour you’ll only test the happy path and failures you can think of. It’s lots of work for no benefit.
This is interesting, but seems a little unnecessarily complex in places. Not sure they need to stray so far from Go. You can pretty much do exactly the same thing in golang just with a check(err) function which panics instead (tried to paste this into this comment as code but the formatting wasn't so good (no newlines)).
which is pretty superfluous I agree and nice to ditch (but could be handled by a preprocessor for scripts). And a line of error handling, which I much prefer explicit in pure go like this:
f, err := os.Create("hello.txt") check(err)
Now a check function that just panics is only useful on short scripts, but it would seem easier to have explicit error handling than produce an entire new dialect for this.
This page seems to be blank?
The article correctly identifies complexity as the biggest problem with writing complex long-lived web applications, but then presents a series of ad-hoc solutions to specific problems (problems caused by the structure they have chosen) as the best answer. It would probably be better titled 'Things I learned writing go' or something similar, rather than attempting to frame different decisions trade/offs as anti-patterns.
To take one example, having one user model is good in that it is easier to maintain and less complex to think about, but the author advocates having a write model and an api model - in some circumstances that might be useful (where there are many private fields which must never leak to the view or require processing before presentation), but most of the time it's overkill and needless complexity.
Crazy!
Nice. Very circular! Shame you can't go get using the gopher protocol.
What can this be used for? Is it useful for the web yet? Surely browser need to support it for that?
Nice. Interesting to see people exploring building a new container host rather than just using docker.
Didn't know reddit used Go, everyone seems to now!
I don’t understand why people try to unit test handlers. Use integration tests for this and the real services you depend on, use unit tests to test functions and business logic, not glue code like handlers. If you build a vast complex web of mocks attempting to reproduce behaviour you’ll only test the happy path and failures you can think of. It’s lots of work for no benefit.
Still broken for me.
This is interesting, but seems a little unnecessarily complex in places. Not sure they need to stray so far from Go. You can pretty much do exactly the same thing in golang just with a check(err) function which panics instead (tried to paste this into this comment as code but the formatting wasn't so good (no newlines)).
func main() {f, err := os.Create("hello.txt")check(err)