Live data from Hacker News

My Opinionated Guide To Go

blog.hackingthought.com

31–40 of 73 posts

Re: My Opinionated Guide To Go

#31

"Go: Code -> Operating System -> Hardware" Is there any reason to use RVM, PVM on production while Go does not required one? I believe should be install one and only one Ruby/Python version on production. Why Ruby/Python does not required application server like unicorn/wcgi, etc? The article clearly try to make other deployment more complicated .

It's a nonsense comparison anyway. E.g. with Java I don't have to care much about the hardware an operating system (e.g. we develop on Mac and deploy on Linux).

And sure, you can use an application container. But you can also embed a webserver. E.g., we Jetty embedded and use a strict SecurityManager policy[1]. So it's more like:

Code -> JVM (with security manager)

[1] http://docs.oracle.com/javase/tutorial/essential/environment...

Re: My Opinionated Guide To Go

#32

"Go: Code -> Operating System -> Hardware" Is there any reason to use RVM, PVM on production while Go does not required one? I believe should be install one and only one Ruby/Python version on production. Why Ruby/Python does not required application server like unicorn/wcgi, etc? The article clearly try to make other deployment more complicated .

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.

Re: My Opinionated Guide To Go

#33
post #29

"Go: Code -> Operating System -> Hardware" Is there any reason to use RVM, PVM on production while Go does not required one? I believe should be install one and only one Ruby/Python version on production. Why Ruby/Python does not required application server like unicorn/wcgi, etc? The article clearly try to make other deployment more complicated .

One version of python on a modern linux OS? How do you mesh the default version of python used by the os with the version of python required by your application code?

[deleted]

Re: My Opinionated Guide To Go

#34
post #30

Not entirely on-topic, but the mention of the various language "stacks" at the beginning of the article reminded me of something I've been wondering. Why does the de facto standard for web apps in Go-land seem to be using the built-in HTTP server provided by net/http, or otherwise having the program server as its own HTTP server? Most other languages seem to have converged on FastCGI or some similar model ({W,P}SGI,…

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.

Re: My Opinionated Guide To Go

#35
post #5

Why does this article only compare Go with interpreted languages at the top? Go is a compiled language; wouldn't it be more fair to compare it with other languages that can be compiled, like C++, Rust, Haskell, or Lisp/Scheme? I mention this because the article acts as if getting rid of abstraction layers between the OS and the code is a new idea. No, that's how all compiled languages are... that's the point of compi…

> that's how all compiled languages are

You mean, like Java and C# ?!

Re: My Opinionated Guide To Go

#36

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.

Not being a Go developer I don't understand why this would be the case. Doesn't Go compile code to a binary? Why should Go even be required on the server?

Re: My Opinionated Guide To Go

#37
post #22
post #5

Why does this article only compare Go with interpreted languages at the top? Go is a compiled language; wouldn't it be more fair to compare it with other languages that can be compiled, like C++, Rust, Haskell, or Lisp/Scheme? I mention this because the article acts as if getting rid of abstraction layers between the OS and the code is a new idea. No, that's how all compiled languages are... that's the point of compi…

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 source to machine code with their own compiler toolchain (no LLVM, GCC, or other compiler required).

When you look at the people coming to Go, most are coming from Python or Ruby, not C, C++, or Java. So a lot of the experience Go developers have are those other languages. As Rob Pike pointed out 2 years ago[1], while they set out for Go to replace C++, it ended up actually being a much better fit for Python and Ruby developers.

[0] http://adventgo.blogspot.ca/2014/05/origin-of-go-toolchain.h...

[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Re: My Opinionated Guide To Go

#38

Earlier quoted context omitted.

Java, while compiled, isn't compiled to machine code, and the bytecode to which it is compiled is run on a virtual machine. For this reason, I consider Java more of an interpreted language than a compiled language per se.

Fine but calling it slow is unfair, especially in relation to Go.

Ah, true. I guess I didn't mean to call Java slow, but interpreted languages in general (at least, their reference implementations) are pretty slow. You're right... Java's kind of in its own category in a lot of ways.

Re: My Opinionated Guide To Go

#39

"Go: Code -> Operating System -> Hardware" Is there any reason to use RVM, PVM on production while Go does not required one? I believe should be install one and only one Ruby/Python version on production. Why Ruby/Python does not required application server like unicorn/wcgi, etc? The article clearly try to make other deployment more complicated .

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.

Re: My Opinionated Guide To Go

#40

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.

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.
Post reply on HN