3 ms·

Relative to Kubernetes (well, specifically OpenShift, which is Kubernetes packaged with a lot of commonly-needed extra functionality / tools) A "hello world" w

Relative to Kubernetes (well, specifically OpenShift, which is Kubernetes packaged with a lot of commonly-needed extra functionality / tools) A "hello world" written in Go is 2mb to begin with so ~4mb is a bit unrealistic for any substantial piece of software written in Go. Although if that colors your opinion of Go itself, you're certainly allowed to have that opinion :)

latchkey 5y ago
Your logic doesn't work because adding functionality doesn't necessary translate to a huge increase in binary size. The complex app (15k lines of code) that is distributed to these machines, written in Go, is just over 3mb compressed with xz. Plus this is still many orders of magnitude off with trying to get 160mb off to mobile devices per the image in the article. It is a non-starter.
- deleted 5y ago
  [deleted]
- dralley 5y ago
  I'm going to take a guess that even a "mini" distribution of Kubernetes is more than 15k lines of code though. k3s is quite a bit smaller than this but it's still only described as "<50 megabytes"
  - latchkey 5y ago
    I'm not sure the point of your argument. Somehow we should just accept 160meg downloads to a phone, because why?
    - dralley 5y ago
      I don't understand the point of your argument, because nobody (including the announcement above) is talking about phones. From the post: > Imagine one of these small devices located in a vehicle to run AI algorithms for autonomous driving, or being able to monitor oil and gas plants in remote locations to perform predictive maintenance, or running workloads in a satellite as you would do in your own laptop. Now contrast this to centralized, highly controlled data centers where power and network conditions are usually very stable thanks to high available infrastructure — this is one of the key differences that define edge environments. > Field-deployed devices are often Single Board Computers (SBCs) chosen based on performance-to-energy/cost ratio, usually with lower-end memory and CPU options. These devices are centrally imaged by the manufacturer or the end user’s central IT before getting shipped to remote sites such as roof-top cabinets housing 5G antennas, manufacturing plants, etc. > At the remote site, a technician will screw the device to the wall, plug the power and the network cables and the work is done. Provisioning of these devices is “plug & go” with no console, keyboard or qualified personnel. In addition, these systems lack out-of-band management controllers so the provisioning model totally differs from those that we use with regular full-size servers. I don't read this and think "phones". This sounds like it's targeted at embedded industrial / telecom devices. (At least based on the examples they chose, I'm sure you could use it for other things). The word "mobile" doesn't actually appear anywhere on the page so I'm not sure where you got "mobile devices" from.
  - jrockway 5y ago
    I recently wrote a single-process k8s distribution (for tests). Compiled into a linux/amd64 binary with no special settings it's 183M with go1.18beta1. Kubernetes is a lot of code, plain and simple.
    - hrez 5y ago
      I found go compiler isn't very efficient in not linking in the dead code. I ran into it by switching from aws-sdk-go to aws-sdk-go-v2 and the binary jumped from 27Mb to 66Mb [1] Granted fully featured app will likely use all of the module's code so it's not a factor. [1] https://github.com/aws/aws-sdk-go-v2/discussions/1532 https://github.com/aws/aws-sdk-go-v2/discussions/1532
      - jrockway 5y ago
        Yeah, I have a feeling that these giant autogenerated clients are tough to optimize. Too many layers of indirection; even the compiler is confused and just crosses its fingers and hopes it doesn't have to investigate too much.
    - smarterclayton 5y ago
      If you use the reflection package in Go, the dead code elimination optimization step does not run if you use reflect.Method to look up a method because you can use reflect to reach those methods and the linker preserves the possibility. Unfortunately, almost every large client library has public methods AND references someone who calls the reflection method somewhere, so in many cases you get the full tree of dependencies. It’s unfortunate because any one dependency can bring in reflect and trigger the behavior. It hurts large generated method libraries the most since you usually only use a small subset. See https://go.dev/src/cmd/link/internal/ld/deadcode.go https://go.dev/src/cmd/link/internal/ld/deadcode.go line 318
      - jrockway 5y ago
        That makes sense. Reflection is the enemy of anyone trying to produce a compact binary (or webpack bundle). A quick grep of the k8s codebase and there are plenty of situations that kill the dead code elimination: staging/src/k8s.io/apimachinery/pkg/runtime/scheme.go: if m := reflect.ValueOf(obj).MethodByName("DeepCopyInto"); m.IsValid() && m.Type().NumIn() == 1 && m.Type().NumOut() == 0 && m.Type().In(0) == reflect.TypeOf(obj) { That's quite the line of code too.
- The_Colonel 5y ago
  > The complex app (15k lines of code) I would argue that 15K lines of code is far from a complex app as is normally understood. It's a rather small app, especially in Go which isn't exactly the most expressive language out there.
- dark-star 5y ago
  They reported the 160mb as uncompressed (and probably unstripped?) size. If you compress that it will be aroudn 50mb, still more than your 3mb xz example but at least you're now comparing apples to apples

latchkey 5y ago

Your logic doesn't work because adding functionality doesn't necessary translate to a huge increase in binary size. The complex app (15k lines of code) that is distributed to these machines, written in Go, is just over 3mb compressed with xz. Plus this is still many orders of magnitude off with trying to get 160mb off to mobile devices per the image in the article. It is a non-starter.

deleted 5y ago
[deleted]
dralley 5y ago
I'm going to take a guess that even a "mini" distribution of Kubernetes is more than 15k lines of code though. k3s is quite a bit smaller than this but it's still only described as "<50 megabytes"
- latchkey 5y ago
  I'm not sure the point of your argument. Somehow we should just accept 160meg downloads to a phone, because why?
  - dralley 5y ago
    I don't understand the point of your argument, because nobody (including the announcement above) is talking about phones. From the post: > Imagine one of these small devices located in a vehicle to run AI algorithms for autonomous driving, or being able to monitor oil and gas plants in remote locations to perform predictive maintenance, or running workloads in a satellite as you would do in your own laptop. Now contrast this to centralized, highly controlled data centers where power and network conditions are usually very stable thanks to high available infrastructure — this is one of the key differences that define edge environments. > Field-deployed devices are often Single Board Computers (SBCs) chosen based on performance-to-energy/cost ratio, usually with lower-end memory and CPU options. These devices are centrally imaged by the manufacturer or the end user’s central IT before getting shipped to remote sites such as roof-top cabinets housing 5G antennas, manufacturing plants, etc. > At the remote site, a technician will screw the device to the wall, plug the power and the network cables and the work is done. Provisioning of these devices is “plug & go” with no console, keyboard or qualified personnel. In addition, these systems lack out-of-band management controllers so the provisioning model totally differs from those that we use with regular full-size servers. I don't read this and think "phones". This sounds like it's targeted at embedded industrial / telecom devices. (At least based on the examples they chose, I'm sure you could use it for other things). The word "mobile" doesn't actually appear anywhere on the page so I'm not sure where you got "mobile devices" from.
- jrockway 5y ago
  I recently wrote a single-process k8s distribution (for tests). Compiled into a linux/amd64 binary with no special settings it's 183M with go1.18beta1. Kubernetes is a lot of code, plain and simple.
  - hrez 5y ago
    I found go compiler isn't very efficient in not linking in the dead code. I ran into it by switching from aws-sdk-go to aws-sdk-go-v2 and the binary jumped from 27Mb to 66Mb [1] Granted fully featured app will likely use all of the module's code so it's not a factor. [1] https://github.com/aws/aws-sdk-go-v2/discussions/1532 https://github.com/aws/aws-sdk-go-v2/discussions/1532
    - jrockway 5y ago
      Yeah, I have a feeling that these giant autogenerated clients are tough to optimize. Too many layers of indirection; even the compiler is confused and just crosses its fingers and hopes it doesn't have to investigate too much.
  - smarterclayton 5y ago
    If you use the reflection package in Go, the dead code elimination optimization step does not run if you use reflect.Method to look up a method because you can use reflect to reach those methods and the linker preserves the possibility. Unfortunately, almost every large client library has public methods AND references someone who calls the reflection method somewhere, so in many cases you get the full tree of dependencies. It’s unfortunate because any one dependency can bring in reflect and trigger the behavior. It hurts large generated method libraries the most since you usually only use a small subset. See https://go.dev/src/cmd/link/internal/ld/deadcode.go https://go.dev/src/cmd/link/internal/ld/deadcode.go line 318
    - jrockway 5y ago
      That makes sense. Reflection is the enemy of anyone trying to produce a compact binary (or webpack bundle). A quick grep of the k8s codebase and there are plenty of situations that kill the dead code elimination: staging/src/k8s.io/apimachinery/pkg/runtime/scheme.go: if m := reflect.ValueOf(obj).MethodByName("DeepCopyInto"); m.IsValid() && m.Type().NumIn() == 1 && m.Type().NumOut() == 0 && m.Type().In(0) == reflect.TypeOf(obj) { That's quite the line of code too.
The_Colonel 5y ago
> The complex app (15k lines of code) I would argue that 15K lines of code is far from a complex app as is normally understood. It's a rather small app, especially in Go which isn't exactly the most expressive language out there.
dark-star 5y ago
They reported the 160mb as uncompressed (and probably unstripped?) size. If you compress that it will be aroudn 50mb, still more than your 3mb xz example but at least you're now comparing apples to apples