41–50 of 73 posts
Earlier quoted context omitted.
Exactly. I have vim handle it for me every time I save. No problemo.
Can you elaborate on how you are doing this? Would love to add this to Vim. Thanks!
For sublime users, see here: http://michaelwhatcott.com/gosublime-goimports/
It's a great tool, very convenient.
Earlier quoted context omitted.
That is true, what if in future ubuntu/centos include Go by default (which might not the version you use)? I believe then will have some GVM or similar tool to solve the problem. Edit: As others pointed out, Go is compiled binary and does not required runtime (like JVM) so versionning is not issue. Thanks for clearing up.
There won't be a need for a GVM as Go is not a stand-alone runtime. Once compiled for a specific platform it will just run. You don't even need it installed on the server. You can cross-compile on your DEV machine and move the binary LIVE. Then it just runs. It doesn't need any libraries on the server.
Earlier quoted context omitted.
A lot of python shops I've come across don't use the system installed python or ruby. In python land at least it's exceedingly common to deploy a virtualenv with a separate python runtime and isolated 3rd party libs. This makes pinning your version deps easier and doesn't matter if the underlying server is ubuntu or centos or whatever.
That is true, what if in future ubuntu/centos include Go by default (which might not the version you use)? I believe then will have some GVM or similar tool to solve the problem. Edit: As others pointed out, Go is compiled binary and does not required runtime (like JVM) so versionning is not issue. Thanks for clearing up.
Earlier quoted context omitted.
For Go, you probably don't want to use their net/http server if you will also have it doing SSL/TLS. Go's TLS implementation doesn't support a lot of older cipher suites which could be a problem for some clients. As well, it is not as hardened as OpenSSL and others (such as possibly being vulnerable to timing attacks[0]). [0] https://code.google.com/p/go/issues/detail?id=2445
OTH there was no Heartbleed bug in the SSL implementation of Go's net/http. So much for hardened implementation. Secondly you can use go behind a http proxy, or even in an FCGI etc environment with minimal change to the code.
That said, it's an advantage of heterogeneity; you get some security by being a small target in a sea of OpenSSL servers.
Earlier quoted context omitted.
That is true, what if in future ubuntu/centos include Go by default (which might not the version you use)? I believe then will have some GVM or similar tool to solve the problem. Edit: As others pointed out, Go is compiled binary and does not required runtime (like JVM) so versionning is not issue. Thanks for clearing up.
There won't be a need for a GVM as Go is not a stand-alone runtime. Once compiled for a specific platform it will just run. You don't even need it installed on the server. You can cross-compile on your DEV machine and move the binary LIVE. Then it just runs. It doesn't need any libraries on the server.
This makes no sense. The runtime of Docker is the Operating System. There's no extra layer, as it's being implied.
And there's no difference between Go and the other languages that makes Docker more or less useful. You can have separate Python processes without Docker, just like you'd have separate Go processes.
I like Go, but this article just sets up strawmen to bring down.
Earlier quoted context omitted.
A lot of python shops I've come across don't use the system installed python or ruby. In python land at least it's exceedingly common to deploy a virtualenv with a separate python runtime and isolated 3rd party libs. This makes pinning your version deps easier and doesn't matter if the underlying server is ubuntu or centos or whatever.
Yeah, many of the ruby applications I've seen recommend RVM so that you can isolate yourself from the system-installed version of ruby. That's the nice thing about go - each application carries around everything it needs to run in total isolation from the rest of the machine.
By the way, you can actually do the same for Python using cx_Freeze; it'll create a single executable with Python + libraries + you code.
[1] http://cx-freeze.readthedocs.org/en/latest/script.html#scrip...
Earlier quoted context omitted.
That's quite common when selling Go. Go advocacy tends to ignore what other modular languages with native compilers offer since the early 80's, as well as, present a cut down version of what modern runtimes are capable of.
If you read any posts or listen to any talks by Google's Go team, they are a fairly modest about Go. They know it isn't as fast as it could be (since they don't have decades of compiler optimizations yet that GCC or other compilers would give). As well, it's just a newer language. One thing a lot of people don't always realize is Golang started with the Plan9 C compiler[0]. So they actually generate all the way from…
I would imagine it's similar for the java guys, especially now that there's java 8, you start having to worry whether it's installed etc. I think Java is a harder sell, because most Java guys don't recognize the complexity inherent in their huge type systems, and they have all these new toys to play with in Java 8 without having to learn a whole new language.... I think they'll come around eventually, though.
Go happens to also be a really great alternative to C and C++ (at least in applications where you don't need the strict timing of a GC-less language...) It's much less error prone than C and C++, with memory safety making most truly critical security bugs simply impossible. Again, like the Java guys, it's a little hard to convince people that have been working in the language for 15-20+ years that there's something that can make their lives easier...
Earlier quoted context omitted.
There won't be a need for a GVM as Go is not a stand-alone runtime. Once compiled for a specific platform it will just run. You don't even need it installed on the server. You can cross-compile on your DEV machine and move the binary LIVE. Then it just runs. It doesn't need any libraries on the server.
Does Go not have the concept of linking? If you are deploying several Go applications on the same server that each use libraries, does it include duplication of libraries in every binary?
So if you have multiple different Go applications on one server, and they use some of the same libraries, then each application's binary will contain a copy of that library.
It makes things a little redundant, but also simplifies the deployment process.
edit: The only exception is if you are using cgo and liking to existing C libraries. In pure Go there is no linking.