1. 8
  1.  

  2. 3

    36 MiB to 6 MiB is good, but I feel 6 MiB is still too big. I have the impression that Go toolchain is bad at linking, also known as tree shaking recently.

    1. 3

      This binary includes database drivers for Oracle, SQL Server, Postgres, MySQL, and SQLite (among many other things) so 6Mb is pretty amazing. The Node.js version of this Go code was like 800Mb (proprietary db drivers don’t have great dependency management practices).

      But yeah it’s just about your perspective.

      1. 2

        Oh wow, does Go have an independent database driver for Oracle? If so, that’s amazing. (That’s my guess because proprietary database drivers not having great dependency management would be exactly same for both Node.js and Go.)

        1. 1

          Oh wow, does Go have an independent database driver for Oracle?

          Yeah it does, but it’s not the most mature library. Some of their development practices are a bit surprising. Like commenting out tests and making new releases. Tests are not run automatically as far as I can tell.

          Still, impressive work on its own.

          https://github.com/godror/godror

          (That’s my guess because proprietary database drivers not having great dependency management would be exactly same for both Node.js and Go.)

          Snowflake brings in aws sdk on Node and on Go but the Node one is still an order of magnitude bigger IIRC.

          1. 2

            Huh, that’s not independent. It seems to use ODPI and ODPI is written by Oracle.

            1. 1
    2. 2

      While it won’t affect the size of binaries much, I would advise including the -trimpath when building to prevent information leakage: by default, full paths will be included in your traceback, and -trimpath ensures that only the parts of the path that are needed get included in your binaries.

      1. 1

        upx technically does make executables smaller, but it’s not as good as techniques that focus on removing junk/overhead from the executable in the first place. It’s going to have to uncompress before running.

        Usually packaged programs are compressed externally (tarball, etc.) and then upx doesn’t save transfer size, but adds startup overhead and taunts anti-virus software.

        1. 1

          Yeah good point. After zip compression there’s only a 2Mb difference in the resulting zip whether I use upx on the Go binary or not.

        2. 1

          Sentry’s Go client is not very good IMO. It’s not very Go-ish. It hides the actual network calls and any errors they produce. The actual system for building an error message is very convoluted. As the article says it’s a bit bloated. There’s a bunch of junk in its go.mod for no reason. I am torn between writing my own client that doesn’t suck and just finding a new service with a less bloated client.

          1. 4

            just write the client yourself because really, it’s just sending log lines and stack traces, the consumer needs to touch a very small number of API endpoints, but … this api documentation is just completely baffling, I can’t find the one endpoint that you would need to post an event. So I look through the source and …they’re not handling the error on sending an event, maybe they do something in the transport? Nope, they throw that error away too, which is weird because further down the page, they have a global logger. This is a carnival of horrors, absolutely not the sort of thing you want to see in the system that reports your errors, which is by definition critical. If you can figure out the API docs, then yeah, I’d write my own client for this if you’re beholden to keeping sentry, because this client is not code that I would run in production. Dangerous, dangerous, dangerous, and right in the spot that’s supposed to keep you safe.

            1. 1

              To be fair to Sentry,

              1. It was really designed to work with Python stack traces and everything else is kind of a square peg in a round hole. The devs seem to be applying Python patterns to Go in the client, so it ends up looking very strange from a Go perspective. They want a semi-magical “you don’t have to think about it” experience, so they end up doing weird stuff.

              2. It is genuinely unclear what you should do with an error made by a logger. Use your other logger to log it? But what about when the other logger fails, etc.? (For me personally, I would like to try to send Sentry failures to Slack as the backup logger, but I can see how that’s not the path they want you to go down.)

              But that still leaves me wishing for a more Go-like error logging service, even if I understand how they got to where they are.

              1. 1

                Okay, from here and here, it looks like they just POST errors to https://sentry.io/api/PROJECT_ID/store so an alternative method would be to just DIY. My guess is that this is deliberately not documented on the API website because they want us to use the official client, but ugh, this code was so clearly written by someone not very familiar with Go.

          2. 1

            Moving my original post-description-comment to an actual comment:

            The combo of -ldflags=”-w -s” and upx is pretty swanky. I just got one of my binaries down from 36Mb to 6Mb using both. And you don’t lose useful stacktraces.