4 ms·

> A new time/tzdata package was added to allow embedding a static copy of the time zone database in executables. This is a BIG improvement. One of the big bene

> A new time/tzdata package was added to allow embedding a static copy of the time zone database in executables. This is a BIG improvement. One of the big benefits of Go is static binaries. Having the TZ data includes will make deploying even easier.

jfkebwjsbx 6y ago
What do you mean by a benefit? Most compiled/native languages can make static binaries.
- TheDong 6y ago
  To paraphrase rob pike incorrectly from an only mildly misleading quote, "The key point here is our programmers are not researchers. They learned java, python, javascript. They're not capable of understanding a brilliant language, so we built go". The comparison isn't other compiled languages that can easily produce static binaries (like ghc/haskell, rust, c++ (with about 2000 lines of meson or cmake or makefile, ...), etc). The comparison is other languages Go programmers might use, like python and javascript. If someone cared about having a good type system, they wouldn't be using Go, so we have to compare Go's capabilities to other languages that are targeted at people who don't want any brilliance or type-theory, but just want a "simple language" where it's accepted as part of the "programmer condition" that you write bad code and get things done. However, in reality, it's worth pointing out that there are very few other languages that have as seamless a static linking experience as Go. Sure, it's quite possible to statically link C(++), rust, etc, but it's more involved than it is for go. Furthermore, for those languages, there's a larger library ecosystem that dynamically depends on C libraries, so i.e. in rust you may have trouble linking any crate that depends on openssl (which quite a few do transitively). Go is the only language I know of that's created an entire culture of eschewing the C ABI as much as possible, that uses linux's syscall interface even though that means there are various things that are just plain broken (like nsswitch). So yeah, while it's true that go isn't the only language that can be statically linked, it's one of the few that focuses on it to such an (arguably unhealthy) extreme.
  - zaphirplane 6y ago
    What’s the actual quote ?
    - pjmlp 6y ago
      "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Sources: https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
  - pjmlp 6y ago
    The irony here is that Go type system is weaker than any of those three languages on their latest versions. So while they learned Java, Python, JavaScript, according to Pike they are still not good enough at their skills, so they must downgrade to Go.
  - jfkebwjsbx 6y ago
    > c++ (with about 2000 lines of meson or cmake or makefile, ...) Making an static binary in C/C++ is a single command-line parameter in most compilers.
- 3fe9a03ccd14ca5 6y ago
  The word "can" is very different than "does by default". Even just doing a static binary for windows and osx will require some VERY complex build systems for most languages. Not with Go. It's simple. I hope other languages put as much effort as Go has into static linked binaries.
TheDong 6y ago
The heck? This seems silly, and like an active nuisance. Timezone data changes multiple times each year. You can see this by the tz-announce email dates [0] Why would I want to have to update recompile and deploy a go binary 2-10 times a year just because Morocco decided to remove DST from one of its regions? I'd much rather the go authors not encourage me to do something dumb like encode tzdata in a nonstandard un-updateable location in my binary rather than having it in a standardized location that the OS will update for me as appropriate. [0]: https://mm.icann.org/pipermail/tz-announce/ https://mm.icann.org/pipermail/tz-announce/
- ithkuil 6y ago
  First point: making something possible doesn't necessarily mean encouraging it (unless you meant it in the "slippery slope" sense). Second point: The way many people use containers (especially when using minimal images meant to "just run a static binary") effectively boils down to the same thing: having a "un-updateable" blob that you need to rebuild in order to get an updated version thereof. If you have an OS with a package manager, that runs without being "reimaged" for weeks, months, years, then having a process that keeps the "OS" up to date (TZ data, security updates of shared libraries, ...) is good idea. If you have a static binary in a minimal image, running in an environment where any software update entails "re-imaging" your machine (VM, container, ...), then your process already has to consider that running the same binary for months and years without any updates is very bad idea. Statically linking critical components like your crypto libraries already begs for a timely and automated rebuild process. The TZ data fits the same pattern as shared libraries. There are points to be made in favour and against shared libraries. Whatever your position is on that topic, I think it can be transferred directly to TZ embedding.
- 4ad 6y ago
  Go will use the system timezone data, this is just a fallback the programmer must opt-in.
  - 3fe9a03ccd14ca5 6y ago
    Tz data is not always available (see alpine base image, or scratch). When it is available, it may be out of date. It may never get updated in fact.

jfkebwjsbx 6y ago

What do you mean by a benefit? Most compiled/native languages can make static binaries.

TheDong 6y ago
To paraphrase rob pike incorrectly from an only mildly misleading quote, "The key point here is our programmers are not researchers. They learned java, python, javascript. They're not capable of understanding a brilliant language, so we built go". The comparison isn't other compiled languages that can easily produce static binaries (like ghc/haskell, rust, c++ (with about 2000 lines of meson or cmake or makefile, ...), etc). The comparison is other languages Go programmers might use, like python and javascript. If someone cared about having a good type system, they wouldn't be using Go, so we have to compare Go's capabilities to other languages that are targeted at people who don't want any brilliance or type-theory, but just want a "simple language" where it's accepted as part of the "programmer condition" that you write bad code and get things done. However, in reality, it's worth pointing out that there are very few other languages that have as seamless a static linking experience as Go. Sure, it's quite possible to statically link C(++), rust, etc, but it's more involved than it is for go. Furthermore, for those languages, there's a larger library ecosystem that dynamically depends on C libraries, so i.e. in rust you may have trouble linking any crate that depends on openssl (which quite a few do transitively). Go is the only language I know of that's created an entire culture of eschewing the C ABI as much as possible, that uses linux's syscall interface even though that means there are various things that are just plain broken (like nsswitch). So yeah, while it's true that go isn't the only language that can be statically linked, it's one of the few that focuses on it to such an (arguably unhealthy) extreme.
- zaphirplane 6y ago
  What’s the actual quote ?
  - pjmlp 6y ago
    "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Sources: https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
- pjmlp 6y ago
  The irony here is that Go type system is weaker than any of those three languages on their latest versions. So while they learned Java, Python, JavaScript, according to Pike they are still not good enough at their skills, so they must downgrade to Go.
- jfkebwjsbx 6y ago
  > c++ (with about 2000 lines of meson or cmake or makefile, ...) Making an static binary in C/C++ is a single command-line parameter in most compilers.
3fe9a03ccd14ca5 6y ago
The word "can" is very different than "does by default". Even just doing a static binary for windows and osx will require some VERY complex build systems for most languages. Not with Go. It's simple. I hope other languages put as much effort as Go has into static linked binaries.

TheDong 6y ago

The heck? This seems silly, and like an active nuisance. Timezone data changes multiple times each year. You can see this by the tz-announce email dates [0] Why would I want to have to update recompile and deploy a go binary 2-10 times a year just because Morocco decided to remove DST from one of its regions? I'd much rather the go authors not encourage me to do something dumb like encode tzdata in a nonstandard un-updateable location in my binary rather than having it in a standardized location that the OS will update for me as appropriate. [0]: https://mm.icann.org/pipermail/tz-announce/ https://mm.icann.org/pipermail/tz-announce/

ithkuil 6y ago
First point: making something possible doesn't necessarily mean encouraging it (unless you meant it in the "slippery slope" sense). Second point: The way many people use containers (especially when using minimal images meant to "just run a static binary") effectively boils down to the same thing: having a "un-updateable" blob that you need to rebuild in order to get an updated version thereof. If you have an OS with a package manager, that runs without being "reimaged" for weeks, months, years, then having a process that keeps the "OS" up to date (TZ data, security updates of shared libraries, ...) is good idea. If you have a static binary in a minimal image, running in an environment where any software update entails "re-imaging" your machine (VM, container, ...), then your process already has to consider that running the same binary for months and years without any updates is very bad idea. Statically linking critical components like your crypto libraries already begs for a timely and automated rebuild process. The TZ data fits the same pattern as shared libraries. There are points to be made in favour and against shared libraries. Whatever your position is on that topic, I think it can be transferred directly to TZ embedding.
4ad 6y ago
Go will use the system timezone data, this is just a fallback the programmer must opt-in.
- 3fe9a03ccd14ca5 6y ago
  Tz data is not always available (see alpine base image, or scratch). When it is available, it may be out of date. It may never get updated in fact.