Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Go web dev notes

jvns.ca

Post reply on HN
Print view View original

81–90 of 154 posts

Re: Some Go web dev notes

#81

Post by zaptheimpaler »

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 adopted option types but instead we are back to this 90s bullshit of conflating error types with valid values. If you're programming defensively, every single object reference anywhere has to be checked for nil or risk panicking now.. like why, after we literally named this a billion dollar mistake in Java, why would anyone fucking do this again?

We have helper methods in our codebase just do to this:

    fn checkThingIsA(ctx) {
      thing := ctx.get(thing)
      if thing == nil || thing != Thing.A {
        return false
      }
      return true
    }
In any sane language this is one line:

  ctx.get(thing).map(|x| x == Thing.A).unwrap_or(false)
In Go, we have to make helper methods for the simplest things because the simplest 1-liner becomes 4 lines with the nil/error check after. We have 100 helpers that do some variation of that because everything is so verbose that could would become unreadable without it.

I hate that they made and popularized this backwards dumpster fire of a language when we should know much better by now.

Re: Some Go web dev notes

#82

Post by mekoka »

gwd wrote: 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…

It's controversial for many good reasons. You make the general claim that retrying a db transaction should be the rule, when most experts agree that it should be the exception. Just in the context of web development it can be disputed on the account that a db transaction is just a part of a bigger contract that includes a user at the other end of a network, a request, a session, and a slew of other possible connected services. If one thing shows signs of being unstable, everything should fail. That's the general wisdom.

More specific to the code that you linked to, the retry happens in only two specific cases. Even then, I personally don't find what it's doing to be such great engineering. It hacks its way around something that should really be fixed by properly setting the db engine. By encroaching like this, it effectively hides the deeper problem that SQLite has been badly configured, which may come to bite you later.

Failing transactions would raise a stink earlier. Upon inquiry, you'd find the actual remedy, resulting in tremendous performance. Instead, this magic loop is trying to help SQLite be a database and it does this in Go! So you end up with these smart transactions that know to wait in a queue for their turn. And for some time, nobody in the dev team may be aware that this can become a problem, as everything seems to be working fine. The response time just gets slightly longer and longer as the load increases.

Code that tries to save failing things at all cost like this also tends to do this kind of glue and duct tape micromanaging of dependencies. Usually with worse results than simply adjusting some settings in the dependencies themselves. You end up with hard to diagnose issues. The code itself becomes hard to reason about as it's peppered with complicated ifs and buts to cover these strange cases.

Re: Some Go web dev notes

#83

Post by sethammons »

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…

Sounds like you are storing interfaces in the context. I wouldn't do that. I do hit the occasional nil reference error, but it is usually very rare. If you deal with concrete types, not interfaces, you don't have to worry about that very weird nil but not nil thing. And always use constructors.

Re: Some Go web dev notes

#84

Post by tacticus »

tmpz22 wrote: post #7
voigt wrote: post #2

> In general everything about it feels like it makes projects easy to work on for 5 days, abandon for 2 years, and then get back into writing code without a lot of problems. To me this is one of the most underrated qualities of go code. Go is a language that I started learning years ago, but did't change dramatically. So my knowledge is still useful, even almost ten years later.

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 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.

So the same as every other language that lacks these in the standard lib?

Re: Some Go web dev notes

#85

Post by cle »

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…

> The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all

HTTP headers in Go are maps, which have a built-in mechanism for checking key existence, which distinguishes b/t empty and missing. No nils involved.

  if vals, ok := headers["Content-Length"]; !ok {
    // no content-length header was passed
  }

Re: Some Go web dev notes

#86

Post by peterldowns »

jrockway wrote: post #54
tmpz22 wrote: 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 really think the library search is more of something you inherit from other languages, though database drivers are something you need to go looking for. The standard library has an adequate HTTP router (though I prefer grpc-gateway as it autogenerates docs, types, etc.) and logger (slog, but honestly plain log is fine). For your database driver, just use pgx. For migrations, tern is fine. For the tiniest bit of sug…

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 endpoints return `(result *T, error)` and your tests can avoid worrying about serde/typeasserting the results.

[0] https://github.com/peterldowns/pgmigrate

Re: Some Go web dev notes

#87

Post by WuxiFingerHold »

voigt wrote: post #2

> In general everything about it feels like it makes projects easy to work on for 5 days, abandon for 2 years, and then get back into writing code without a lot of problems. To me this is one of the most underrated qualities of go code. Go is a language that I started learning years ago, but did't change dramatically. So my knowledge is still useful, even almost ten years later.

Absolutely, but not really underrated. The large and useful std lib plays an important role in the long term stability.

Re: Some Go web dev notes

#88

Post by sureglymop »

tmpz22 wrote: post #7
voigt wrote: post #2

> In general everything about it feels like it makes projects easy to work on for 5 days, abandon for 2 years, and then get back into writing code without a lot of problems. To me this is one of the most underrated qualities of go code. Go is a language that I started learning years ago, but did't change dramatically. So my knowledge is still useful, even almost ten years later.

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 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.

Re: Some Go web dev notes

#89

Post by WuxiFingerHold »

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…

Go as a language is not fun at all. Nor very good. Weaker type system and less language features that increase productivity and readability than C#, Java, Kotlin and Typescript, no null checks.

Go as a runtime is outstanding.

Go's tooling, stability and governance are very good.

Nothing is perfect. Enter into your compromise.

Re: Some Go web dev notes

#90

Post by jrockway »

peterldowns wrote: post #86
jrockway wrote: post #54

Earlier quoted context omitted.

I really think the library search is more of something you inherit from other languages, though database drivers are something you need to go looking for. The standard library has an adequate HTTP router (though I prefer grpc-gateway as it autogenerates docs, types, etc.) and logger (slog, but honestly plain log is fine). For your database driver, just use pgx. For migrations, tern is fine. For the tiniest bit of sug…

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!
Post reply on HN