6 ms·

Another reason Go has been helpful is that is generates a single executable that can be distributed to our clients. There's no complex dependency chain or layou

• drivebyacct2 14y ago
  The other nicety that goes hand in hand with this is crazy simple cross compiling. My current project uses cgo and pcap so I don't get to use it now [1], but my last and next project allow me to hit a single command and have nice statically compiled binaries for FreeBSD, OS X, Linux and Windows in a very small amount of time with almost no setup effort. I still need to get it wired up to the GitHub API for downloads and life will be perfect. I can push to master and upload a build for download all in one fell swoop. ([1], cross compiling is not [currently?] supported with cgo)
• TazeTSchnitzel 14y ago
  You can do the same thing with any compiled language, but I suppose that's a feature of Go since it's a compiled language.
  • riobard 14y ago
    You can do the same thing with any compiled language This is not necessarily true. Remember the DLL hell? Go does not support dynamic linking at all (some say this is a disadvantage), so you are forced to produce a single self-contained binary.
    • TazeTSchnitzel 14y ago
      DLL hell only happens if you use dynamic linking. Static linking is always an option. (actually, is it? I don't tend to use a lot of libraries, how much stuff that isn't part of the OS can you not statically link?)
      • Strom 14y ago
        I belive you need to also provide re-linking mechanisms for your customers if you statically link something licensed under LGPL.
      • podperson 14y ago
        DLL hell happened (in Windows) because you had to dynamically link against system libraries which could change in incompatible ways making your code fragile. Depending on the nature of the development toolset, you may not be able to avoid DLL hell. E.g. you may not have the right to build the library into your code and/or the toolset may force you to link against external code libraries. The original goal of Microsoft's DLL strategy was to save disk space (and presumably memory) but the end result was a compatibility nightmare. Retrospectively, it seems to have been both a bad technical decision (disk space turned out to be a bad thing to trade against other considerations) and badly implemented (too many DLLs went live and then broke backwards compatibility in updates). It seems like other companies managed to allow dynamic linking without creating so much fragility.
        • gouranga 14y ago
          It's a great idea and still is. Linux does pretty much the same thing. It actually broke because they didn't allow multiple versions and windows linked to the latest version at runtime. They fixed all this with WinSXS which allows a PE file to specify a manifest i.e. a list of required versions of DLLs to load. This is all neatly explained here: http://msdn.microsoft.com/en-us/library/aa376307.aspx http://msdn.microsoft.com/en-us/library/aa376307.aspx
        • tedunangst 14y ago
          It would be more accurate to say dll hell happened because vendors decided to install their 3rd party dependencies in the windows directory. There are not as many problems with actual Microsoft dlls.
      • 4ad 14y ago
        > Static linking is always an option. Not if you use C and glibc (most common combination of them all, most software requires glibc). Even if you compile glibc statically in your program (not an option by default at least in Ubuntu), glibc itself will load more shared objects at runtime.
  • genbattle 14y ago
    With other languages such as C/C++ if you link a library into your program statically, that library may dynamically load other dependencies. In Go, all dependencies have to be statically compiled into that package. Rob Pike made a good point about this in one of the Go talks [1] (I think it was the "Meet the Go team" talk) when they were talking about package management and the static linking, and how in C++ you could get massive chains of useless includes (I think is came out of a question on the speed of the Go compiler). His reasoning was that all the code you need to compile a package should be in the one package binary. You shouldn't need to worry about having other 3rd-party packages that your dependency depends on installed on the target system. [1] http://blog.golang.org/2012/07/go-videos-from-google-io-2012.html http://blog.golang.org/2012/07/go-videos-from-google-io-2012...
    • pjmlp 14y ago
      > In Go, all dependencies have to be statically compiled into that package. This is not true. If you make use of cgo, the dependencies are linked dynamically.
      • 4ad 14y ago
        Using cgo is an exception rather than the rule, and when Rob talks about package dependencies he means any file required for building that package, not only the shared objects. This includes C/C++ header files. Even with cgo, to use a package that uses cgo you only need that package archive, you need not care about what files that created that package.
        • pjmlp 14y ago
          Like in every other compiled language that has modules.
      • genbattle 14y ago
        Yes, you are right. I was referring to pure Go packages.
• cenuij 14y ago
  This sentiment was echoed by pretty much all the engineers (Canonical, StatHat, Heroku, Iron.io) who presented in the "Go in Production" talk at I/O 2012 http://www.youtube.com/watch?v=kKQLhGZVN4A http://www.youtube.com/watch?v=kKQLhGZVN4A
• Dobbs 14y ago
  This is one of my major annoyances with python and ruby. I want to take all the package dependencies and toss them into a single executable that at most relies upon the interpreter to be there. With a bit of hacking you can do it but it isn't the most straightforward procedure, can be messy and isn't really supported by the community.
  • gecko 14y ago
    The Python side's actually really easy and well-supported: Python can run code from a zipfile, so tools like `py2exe` or `pyinstaller` get you down to Python interpreter + zipfile. That's two files, but only two files. I don't know if there's similar stuff on the Ruby side.
    • wahnfrieden 14y ago
      It gets much messier once you have dependencies that aren't pure python. Last I checked py2exe was no longer maintained either.
    • davidw 14y ago
      Tcl has really good support for this, actually. It's a bit of a messy concept, but in the end, it works out pretty well.
• Strom 14y ago
  Static linking is easily available with C/C++ as well. The main trade-off is how critical bugs in some library your program uses can be solved. With dynamic linking it's possible for the library author to publish an API-compatible update, which when deployed fixes the issue in all programs that use this library. With static linking you need to recompile the whole program and publish the update. For real world examples you could look at the Microsoft C run-time. When a security vulnerability is found & fixed, Microsoft pushes the dynamic link version of the update via Microsoft Update and millions of programs are no longer affected by this issue. However when you linked statically, you need to update your program as well. Many programs do not have good automatic update systems, and many programs aren't even under continued maintenance and remain forever vulnerable.
  • jkn 14y ago
    Static linking is not easily available with C/C++ in the general case. Some libraries support it, some important ones like Glibc and GTK+ do not.
    • pjmlp 14y ago
      The only reason this is not an issue with Go is that the language is too young and the reference compiler only supports static linking fot the time being. The moment the compiler starts supporting dynamic linking the same will happen to Go.
      • 4ad 14y ago
        Static linking of Go code is a conscious design decision, not some artifact of toolchain immaturity. It will never change.
        • reddit_clone 14y ago
          On a related note, using Go can one develop DLLs that can be dynamically consumed from other applications? Or you can only produce statically linked exe's?
• sausagefeet 14y ago
  Definitely. One reason I like Ocaml so much.
• georgemcbay 14y ago
  This also makes cross-compiling a breeze. I write software in Go for armv5 chumby devices but I edit and compile on Windows (the Go compiler itself can be compiled and run on the chumby devices, but they are very slow and low memory for doing active development on). Getting a build for the chumby from my Windows/x64 box is as easy as setting GOARCH=arm, GOARM=5 and GOOS=linux and then re-running go build. Ridiculously simpler than setting up a full gcc toolchain that targets the device, taking into account what libc is on each device, etc. Build on the Windows box, scp the output executable over and It Just Works.
  • riobard 14y ago
    Ha, this is very cool. I didn't know you can cross-compile Go before. Just tried and it's really easy to setup a build for multiple architecture. Thanks for the tip!