4 ms·

I wouldn't personally compare it to Java, having written it for some time. I too am not too fond of writing web apps in Go. It's doable, and you can do things t

I wouldn't personally compare it to Java, having written it for some time. I too am not too fond of writing web apps in Go. It's doable, and you can do things to make it easier, but it can be painful. It took me some time to get in to the groove. I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). It also seems to be pretty popular for different newer data stores. Again, if it's pure Go it'll run anywhere... so it makes development (and portability) much easier. I like its concurrency model, to a point. That said, I hope they really improve some things about in Go 2 (like working with channels and goroutines). I'm not sure when that will be. I use Go for a lot of things, most of which are command line applications. Whether it be interfacing with some sort of REST API, taking actions on the local system, or some sort of network client for devices on my LAN. It works well for quite a few cases. It seems to fit well with my mental model quite often, so I use it. And it's a simple language, so it was easy to get started with it. At the end of the day, it's a tool like many others. I think it's up to the creator to choose the tool that feels best to them.

e12e 11y ago
> I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). This is something I haven't seen discussed much recently. Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)? As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.". As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found. [1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein: http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-pypy-vs-Python/ http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...
- TheSwordsman 11y ago
  >But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found. Yeah, I think it may be because it's situation dependent. For me, it always consisted of recompile all binaries and deploy them. And even then, I'm not sure people would enjoy a blog post just telling you to recompile all the things. It's not very sexy, honestly. In my situation, it wasn't that big of a pain to do so. A lot of these libraries are within stdlib, so a security bug would incur a new release of Go. So an update should be pretty easy. If's an external library (i.e., one picked up from GitHub for example), it's pretty much the same. Get new source, recompile binary with patched library, ship to all the things. There are tradeoffs, absolutely. The alternative would be to write something in an interpreted language. That means we need to push a runtime environment up to the node, and that may include managing any libraries that are needed (think Rubygems). Managing these kinds of setups can be a pain, especially if a node has multiple projects with different dependencies. I found that shipping a single binary was often easier for me. But it goes back to it being an item in the toolbox, depends on what you need and how your systems are built.
- calgoo 11y ago
  Well, i personally really like the Static linking, but that is because of the limitations on our network. To get onto a server, I have to use a VDI session -> Citrix -> SSH Jump host -> ssh jump host -> server. The servers dont have internet access and to get files onto them i have to do the same story as above (using sftp). So having 1 static binary that i copy over without having to worry about the dependencies is great.
- wfsfw4w44 11y ago
  go is somewhat special in what is shipped with its system libs: "TLS/SSL/GZIP/PNG/XML" all of these are part of the go standard libs, and gets regularry updated with the language. tls and ssl: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ gzip: https://golang.org/pkg/compress/gzip/ https://golang.org/pkg/compress/gzip/ png: https://golang.org/pkg/image/png/ https://golang.org/pkg/image/png/ xml: https://golang.org/pkg/encoding/xml/ https://golang.org/pkg/encoding/xml/ since golang also has built in support for fuzzing in the toolchain, the standard parts are quite battle tested already. if you study their sourcecode you will also find Benchmark functions, that you can use to benchmark the implementations (go test -bench ./...)

e12e 11y ago

> I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). This is something I haven't seen discussed much recently. Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)? As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.". As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found. [1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein: http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-pypy-vs-Python/ http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...

TheSwordsman 11y ago
>But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found. Yeah, I think it may be because it's situation dependent. For me, it always consisted of recompile all binaries and deploy them. And even then, I'm not sure people would enjoy a blog post just telling you to recompile all the things. It's not very sexy, honestly. In my situation, it wasn't that big of a pain to do so. A lot of these libraries are within stdlib, so a security bug would incur a new release of Go. So an update should be pretty easy. If's an external library (i.e., one picked up from GitHub for example), it's pretty much the same. Get new source, recompile binary with patched library, ship to all the things. There are tradeoffs, absolutely. The alternative would be to write something in an interpreted language. That means we need to push a runtime environment up to the node, and that may include managing any libraries that are needed (think Rubygems). Managing these kinds of setups can be a pain, especially if a node has multiple projects with different dependencies. I found that shipping a single binary was often easier for me. But it goes back to it being an item in the toolbox, depends on what you need and how your systems are built.
calgoo 11y ago
Well, i personally really like the Static linking, but that is because of the limitations on our network. To get onto a server, I have to use a VDI session -> Citrix -> SSH Jump host -> ssh jump host -> server. The servers dont have internet access and to get files onto them i have to do the same story as above (using sftp). So having 1 static binary that i copy over without having to worry about the dependencies is great.
wfsfw4w44 11y ago
go is somewhat special in what is shipped with its system libs: "TLS/SSL/GZIP/PNG/XML" all of these are part of the go standard libs, and gets regularry updated with the language. tls and ssl: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ gzip: https://golang.org/pkg/compress/gzip/ https://golang.org/pkg/compress/gzip/ png: https://golang.org/pkg/image/png/ https://golang.org/pkg/image/png/ xml: https://golang.org/pkg/encoding/xml/ https://golang.org/pkg/encoding/xml/ since golang also has built in support for fuzzing in the toolchain, the standard parts are quite battle tested already. if you study their sourcecode you will also find Benchmark functions, that you can use to benchmark the implementations (go test -bench ./...)