4 ms·

The biggest stumbling block there, for me, is that it's impossible to write shared libraries in go. You can't write libraries in go that can be used from anyth

by tene 12y ago

The biggest stumbling block there, for me, is that it's impossible to write shared libraries in go. You can't write libraries in go that can be used from anything other than go, so until you've converted everything over to go, you'll still need to write libssl.so and friends in C. Go is a great application language, but it doesn't play well enough with others to really be a systems language as long as you can't write libraries other languages can use in it.

jzelinskie 12y ago
While totally unsuited for the aforementioned hypothetical situation, Go has also supported SWIG for a few years now.
colin_mccabe 12y ago
Shared libraries are coming for Go. https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.
- tene 12y ago
  There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.
  - marcus_holmes 12y ago
    I moved from C# to Go, and one of the things I really loved is the sudden absence of DLL-Hell. I never have to worry that installing my program on another machine would suddenly cause it to bork. I guess I'm happy importing everything into monster huge static binaries and not worrying :)
    - johnny_reilly 12y ago
      Marcus, I'm also giving Go a try at the moment (C# is my day job). What are you using tooling-wise? I'm trying out Lite IDE at the moment and that's the best experience I've had yet. So far my view is that I really like the language but I'm finding the tooling pretty unappealing. Wonder if I'm missing a trick?
      - okatsu 12y ago
        I find that Sublime Text with the GoSublime plugin works pretty well. There's "Intellisense" for imported packages and GsLint actively detects syntax errors. Gofmt also takes care of indentation and formatting for you at every save.
        bkeroack 12y ago
        ++ to Sublime Text and GoSublime. It's what I use and anecdotally appears to be the most popular Go dev environment.
        johnny_reilly 12y ago
        Thanks both of you - I haven't had a go with GoSublime yet. Now I will!
        marcus_holmes 12y ago
        My experience: you kinda have to rethink what an IDE is. Go comes from the *nix tradition where the "coding environment" is a text editor and a few terminal windows. I use GoConvey to automagically run my tests and tell me what I broke. I keep this running in a terminal window (so I can CTRL-C stop it) and a browser window. I have another terminal tab on the same window for godoc, and that's serving another browser window. I have a terminal tab for git commands and file manipulation (this is the one the terminal window is normally on). I moved away from SublimeText to Atom (with go-plus) because while the load times suck, the go language support in the tooling is way better. Not that GoSublime is bad, it's not, but Atom just works better for me. I tried vim, and loved it, but the support for the go tools was never quite there, and configuring the bloody thing was a nightmare. So every time I save a file it automagically runs gofmt, goimports, compiles and runs my tests in goconvey (and tells me what I broke), and colours my test coverage right in the editor. It's not quite the integrated experience that Visual Studio is, but it's incredibly powerful, and conforms to the unix philosophy of lots of good, small programs working together. And just for comparison; today I spent 20 mins trying to get a dark theme on VS2010 and had to give up (or hand-pick every colour in what looked like around 100 options)... whereas I have dark themes galore on everything else ;)
codexon 12y ago
And because everything is statically compiled, go binaries tend to be very large. Imagine each binary being 5 mb on average and multiply that by 100.
- slimsag 12y ago
  > And because everything is statically compiled, go binaries tend to be very large. Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? > Imagine each binary being 5 mb on average and multiply that by 100. I don't think it's a factor of 100 times, that seems a bit outrageous.
  - rurounijones 12y ago
    >> Imagine each binary being 5 mb on average and multiply that by 100. > I don't think it's a factor of 100 times, that seems a bit outrageous. I think he means 100 utilities all weighing in at 5mb
  - masklinn 12y ago
    > Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? Removing DWARF information with -ldflags -w reduces the size of the binary by 20%. The binary is 1.8MB originally... $ go build hello.go $ wc -c hello 1806192 hello $ go build -ldflags -w hello.go $ wc -c hello 1408880 hello the rest is pretty much all runtime, the hello world itself should take about 10k, that's more or less the size of the C or dynamically linked Rust versions (Rust also uses static linking by default, and the hello world is 300k in that case)
    - f2f 12y ago
      to see how much the runtime contributes to the size of the binary use an empty main. for hello world you bring in the fmt package which is a relative heavyweight: $ cat > t.go package main func main() {} $ go build t.go $ wc -c t 623280 t $ nm t | wc -l 1029 $ cat > t.go package main import "fmt" func main() { fmt.Println("hello world") } $ go build t.go $ nm t | wc -l 2541
pjmlp 12y ago
That is a toolchain limitation, not the language. I think gccgo allows for .so. And the work for Android is adding .so support to the main toolchain.
codygman 12y ago
You could write those command line libraries/etc in Ocaml now ;)
- pjmlp 12y ago
  Yep "Unix system programming in OCaml" http://ocaml.github.io/ocamlunix/ http://ocaml.github.io/ocamlunix/
  - codygman 12y ago
    Oh this looks very interesting. It would be fun to read this and make Haskell versions of the programs as well as learn Ocaml at the same time!
Animats 12y ago
Are shared libraries a memory win in production environments? For shared libraries to be a win, you have to be running different executables on the same machine (or VM) which share libraries of significant size relative to the memory use of the program itself. You also have to be using a big fraction of each shared library. With static linking, if you need "cos", you get that loaded; with a shared library, you bring in the entire math library. Modern production environments often involve only one program per VM, or multiple instances of the same program. In such cases, shared libraries are a lose.

by tene 12y ago

jzelinskie 12y ago

While totally unsuited for the aforementioned hypothetical situation, Go has also supported SWIG for a few years now.

colin_mccabe 12y ago

Shared libraries are coming for Go. https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.

tene 12y ago
There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.
- marcus_holmes 12y ago
  I moved from C# to Go, and one of the things I really loved is the sudden absence of DLL-Hell. I never have to worry that installing my program on another machine would suddenly cause it to bork. I guess I'm happy importing everything into monster huge static binaries and not worrying :)
  - johnny_reilly 12y ago
    Marcus, I'm also giving Go a try at the moment (C# is my day job). What are you using tooling-wise? I'm trying out Lite IDE at the moment and that's the best experience I've had yet. So far my view is that I really like the language but I'm finding the tooling pretty unappealing. Wonder if I'm missing a trick?
    - okatsu 12y ago
      I find that Sublime Text with the GoSublime plugin works pretty well. There's "Intellisense" for imported packages and GsLint actively detects syntax errors. Gofmt also takes care of indentation and formatting for you at every save.
      - bkeroack 12y ago
        ++ to Sublime Text and GoSublime. It's what I use and anecdotally appears to be the most popular Go dev environment.
        johnny_reilly 12y ago
        Thanks both of you - I haven't had a go with GoSublime yet. Now I will!
        marcus_holmes 12y ago
        My experience: you kinda have to rethink what an IDE is. Go comes from the *nix tradition where the "coding environment" is a text editor and a few terminal windows. I use GoConvey to automagically run my tests and tell me what I broke. I keep this running in a terminal window (so I can CTRL-C stop it) and a browser window. I have another terminal tab on the same window for godoc, and that's serving another browser window. I have a terminal tab for git commands and file manipulation (this is the one the terminal window is normally on). I moved away from SublimeText to Atom (with go-plus) because while the load times suck, the go language support in the tooling is way better. Not that GoSublime is bad, it's not, but Atom just works better for me. I tried vim, and loved it, but the support for the go tools was never quite there, and configuring the bloody thing was a nightmare. So every time I save a file it automagically runs gofmt, goimports, compiles and runs my tests in goconvey (and tells me what I broke), and colours my test coverage right in the editor. It's not quite the integrated experience that Visual Studio is, but it's incredibly powerful, and conforms to the unix philosophy of lots of good, small programs working together. And just for comparison; today I spent 20 mins trying to get a dark theme on VS2010 and had to give up (or hand-pick every colour in what looked like around 100 options)... whereas I have dark themes galore on everything else ;)

codexon 12y ago

And because everything is statically compiled, go binaries tend to be very large. Imagine each binary being 5 mb on average and multiply that by 100.

slimsag 12y ago
> And because everything is statically compiled, go binaries tend to be very large. Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? > Imagine each binary being 5 mb on average and multiply that by 100. I don't think it's a factor of 100 times, that seems a bit outrageous.
- rurounijones 12y ago
  >> Imagine each binary being 5 mb on average and multiply that by 100. > I don't think it's a factor of 100 times, that seems a bit outrageous. I think he means 100 utilities all weighing in at 5mb
- masklinn 12y ago
  > Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? Removing DWARF information with -ldflags -w reduces the size of the binary by 20%. The binary is 1.8MB originally... $ go build hello.go $ wc -c hello 1806192 hello $ go build -ldflags -w hello.go $ wc -c hello 1408880 hello the rest is pretty much all runtime, the hello world itself should take about 10k, that's more or less the size of the C or dynamically linked Rust versions (Rust also uses static linking by default, and the hello world is 300k in that case)
  - f2f 12y ago
    to see how much the runtime contributes to the size of the binary use an empty main. for hello world you bring in the fmt package which is a relative heavyweight: $ cat > t.go package main func main() {} $ go build t.go $ wc -c t 623280 t $ nm t | wc -l 1029 $ cat > t.go package main import "fmt" func main() { fmt.Println("hello world") } $ go build t.go $ nm t | wc -l 2541

pjmlp 12y ago

That is a toolchain limitation, not the language. I think gccgo allows for .so. And the work for Android is adding .so support to the main toolchain.

codygman 12y ago

You could write those command line libraries/etc in Ocaml now ;)

pjmlp 12y ago
Yep "Unix system programming in OCaml" http://ocaml.github.io/ocamlunix/ http://ocaml.github.io/ocamlunix/
- codygman 12y ago
  Oh this looks very interesting. It would be fun to read this and make Haskell versions of the programs as well as learn Ocaml at the same time!

Animats 12y ago

Are shared libraries a memory win in production environments? For shared libraries to be a win, you have to be running different executables on the same machine (or VM) which share libraries of significant size relative to the memory use of the program itself. You also have to be using a big fraction of each shared library. With static linking, if you need "cos", you get that loaded; with a shared library, you bring in the entire math library. Modern production environments often involve only one program per VM, or multiple instances of the same program. In such cases, shared libraries are a lose.