4 ms·

It’s always interesting when people compare Go to other languages they always use file size of binary, as if that’s something that anyone in modern professional

It’s always interesting when people compare Go to other languages they always use file size of binary, as if that’s something that anyone in modern professional engineering considers. Another good example would be to statically cross-compile a non-contrived program into ARM64, 32-bit linux, and Darwin without needing google! And if you think you have your binary statically linked, go test it in the “scratch” docker image. You may be surprised at how difficult it really is.

pjmlp 6y ago
Sure we do, I have spent the last week trying to upload 10 MB files in a quite slow uplink, and yes in Europe, suburban area of a German town. First reason why people uninstall apps on mobile devices is app size.
- sk0g 6y ago
  Are mobile apps the target market for Go? CI/CD takes care of upload for the dev side at least. It would be handy to have a compile time flag indicating the desired file size optimisation level still, with tradeoffs being ease of debugging, and performance.
  - pjmlp 6y ago
    Given that gomobile exists, maybe. CI/CD is something almost unknown outside HN bubble. Also that was just two examples, here are another two, cost of production for USB Armoury keys running Go bare metal, or download costs for WebAssembly modules written in Tiny Go.
    - sk0g 6y ago
      Are you sure re: CI/CD? I was looking around the job market recently, and every role was interested in my experience in it, since they were using it too. To be honest, that could be self-selecting, as my resume likely attracts companies similar to ones I have worked at. I still do hear about microservices, CI/CD a whole lot in job descriptions etc, but whether they are already practicing it (well), is another question... I was going to suggest TinyGo! I mainly work on a backend system, so I guess we have different priorities and needs. The embedded work I have done has all been C/ ASM, though it could be fun to revisit with Go.
      - pjmlp 6y ago
        I still get to work on customers whose process is to compile on the IDE and manually copy a zip file into whatever environment they need to deploy. Companies whose main business is not selling software don't care much about whatever are best practices in software engineering.
      - sfkdjf9j3j 6y ago
        In terms of sheer numbers, I would guess that at least a plurality of websites are running old versions of PHP and are released via FTP. But I don't think that's really meaningful or interesting to worry about, since those services aren't even considering the tooling decisions we're talking about.
jchook 6y ago
AFAIK, if you deploy an app to an AWS auto-scaling group, then bundle size can very much impact your cold boot times, and therefore scaling agility.
- weego 6y ago
  Technically true but you're talking about sub-second figures that have no meaningful impact compared to the high and unreliable variable actual process of autoscaling booting a server and waiting until it gets a health check before adding it to the load balancer. If you were to attempt to optimise around that, or any other argument such as ingress to s3 etc etc you would quickly find that you'll never in thr lifetime of that codebase make the dev cost back in tangeable returns to your business.
  - jchook 6y ago
    Yes I mostly agree. Also I suspect a lot of the Go executable size comes from "initial" runtime overhead that does not scale linearly with the project size. Rapid scaling in a "Superbowl ad" or similar situation is affected heavily by cold boot time, which, as you point out, is a result of many factors, including your platform. If you use something like Lambda, your bundle size plays a much bigger role than if you fire up a new EC2 instance.
hu3 6y ago
Given Go was developed by Google to solve Google problems I would err on the side of no.
smabie 6y ago
If you're entire binary fits in L1, you're going to realize significant performance improvements over a 30mb binary. It's just that simple.
- ed25519FUUU 6y ago
  Does that include a dynamic linked library?
  - smabie 6y ago
    Yup. To absolutely maximize performance, you need none of your code paths to swap your binary out of L1. Of course, it's not the end of the world if one of them does (an occasional call to a large dynamic lib isn't too bad) but a small binary has important performance implications that most developers don't internalize.

pjmlp 6y ago

Sure we do, I have spent the last week trying to upload 10 MB files in a quite slow uplink, and yes in Europe, suburban area of a German town. First reason why people uninstall apps on mobile devices is app size.

sk0g 6y ago
Are mobile apps the target market for Go? CI/CD takes care of upload for the dev side at least. It would be handy to have a compile time flag indicating the desired file size optimisation level still, with tradeoffs being ease of debugging, and performance.
- pjmlp 6y ago
  Given that gomobile exists, maybe. CI/CD is something almost unknown outside HN bubble. Also that was just two examples, here are another two, cost of production for USB Armoury keys running Go bare metal, or download costs for WebAssembly modules written in Tiny Go.
  - sk0g 6y ago
    Are you sure re: CI/CD? I was looking around the job market recently, and every role was interested in my experience in it, since they were using it too. To be honest, that could be self-selecting, as my resume likely attracts companies similar to ones I have worked at. I still do hear about microservices, CI/CD a whole lot in job descriptions etc, but whether they are already practicing it (well), is another question... I was going to suggest TinyGo! I mainly work on a backend system, so I guess we have different priorities and needs. The embedded work I have done has all been C/ ASM, though it could be fun to revisit with Go.
    - pjmlp 6y ago
      I still get to work on customers whose process is to compile on the IDE and manually copy a zip file into whatever environment they need to deploy. Companies whose main business is not selling software don't care much about whatever are best practices in software engineering.
    - sfkdjf9j3j 6y ago
      In terms of sheer numbers, I would guess that at least a plurality of websites are running old versions of PHP and are released via FTP. But I don't think that's really meaningful or interesting to worry about, since those services aren't even considering the tooling decisions we're talking about.

jchook 6y ago

AFAIK, if you deploy an app to an AWS auto-scaling group, then bundle size can very much impact your cold boot times, and therefore scaling agility.

weego 6y ago
Technically true but you're talking about sub-second figures that have no meaningful impact compared to the high and unreliable variable actual process of autoscaling booting a server and waiting until it gets a health check before adding it to the load balancer. If you were to attempt to optimise around that, or any other argument such as ingress to s3 etc etc you would quickly find that you'll never in thr lifetime of that codebase make the dev cost back in tangeable returns to your business.
- jchook 6y ago
  Yes I mostly agree. Also I suspect a lot of the Go executable size comes from "initial" runtime overhead that does not scale linearly with the project size. Rapid scaling in a "Superbowl ad" or similar situation is affected heavily by cold boot time, which, as you point out, is a result of many factors, including your platform. If you use something like Lambda, your bundle size plays a much bigger role than if you fire up a new EC2 instance.

hu3 6y ago

Given Go was developed by Google to solve Google problems I would err on the side of no.

smabie 6y ago

If you're entire binary fits in L1, you're going to realize significant performance improvements over a 30mb binary. It's just that simple.

ed25519FUUU 6y ago
Does that include a dynamic linked library?
- smabie 6y ago
  Yup. To absolutely maximize performance, you need none of your code paths to swap your binary out of L1. Of course, it's not the end of the world if one of them does (an occasional call to a large dynamic lib isn't too bad) but a small binary has important performance implications that most developers don't internalize.