Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Opinionated Guide To Go

blog.hackingthought.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: My Opinionated Guide To Go

#21

Post by kjs3 »

sergiotapia wrote: post #6
mattgreenrocks wrote: post #4

Earlier quoted context omitted.

Maybe Go is trying to tell you that the "move fast and break things" methodology is not how it should be used?

I know right? I do feel a warm fuzzy feeling when things compile and I generally feel much safer than when building things in Ruby.

When I talk to the youngsters about this exact feeling they look at me like I'm nuts. Coming from Ada/Modula-2/etc. where you put the thought in up front and if it compiled you were a long way to being "right" isn't something they get.

Re: My Opinionated Guide To Go

#22

Post by pjmlp »

rthomas6 wrote: 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.

Re: My Opinionated Guide To Go

#23

Post by kevrone »

AYBABTME wrote: post #3
sergiotapia wrote: post #2

I just wish Go would let me compile and run with a flag -allowing- unused imports. I find myself wasting a lot of time hunting down unused imports or variables and commenting them out. Maybe that'll be a non-issue the more I use Go, but so far it's a bit of a time waster.

https://github.com/bradfitz/goimports

It's worth mentioning that the author of this tool is Brad Fitzpatrick, one of the main contributors to the Go standard library and, in my opinion, the most "entrenched" Go developer on the team. And by that I mean he uses Go to build large and practical projects on his own (See Camlistore), so he knows what the language feels like from a perspective similar to the rest of us. He's also one of the only advocates on the team for the inclusion of generics.

Re: My Opinionated Guide To Go

#25

Post by kasey_junk »

rthomas6 wrote: post #15
kasey_junk wrote: post #9

Earlier quoted context omitted.

Well to be fair it does mention Java (though the deployment model expressed is, shall we say, Byzantine).

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.

Re: My Opinionated Guide To Go

#26

Post by treystout »

paukiatwee wrote: post #16

"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.

Re: My Opinionated Guide To Go

#27

Post by mediocregopher »

jerf wrote: post #14
AYBABTME wrote: post #3

Earlier quoted context omitted.

https://github.com/bradfitz/goimports

To explain to those who may not know what's going on here: Go forbids importing modules that you then don't use in the source code. This is particularly annoying with the "fmt" module, which contains things like Printf that are useful for debugging, but you may only be using fmt.Printf for one debugging statement in the code. Consequently, if you're developing, and you're adding and removing it over and over you also…

> flymake in emacs, don't know what in vim

https://github.com/scrooloose/syntastic for vim.

Re: My Opinionated Guide To Go

#28

Post by ZenoArrow »

lmm wrote: post #11
ZenoArrow wrote: post #8

Have noted this 'opinionated' trend going for quite a while, so this comment isn't about this article in particular, but can someone break down why an opinionated guide to something technical would be preferable to an impartial one? The only thing it seems to imply is that bias adds value in its own right.

It's a pre-emptive disclaimer "I know this isn't objective, don't complain about that". And it tells you that the guide isn't going to offer you confusing choices, it's going to tell you one way to do things. For some people that's an advantage.

Thanks for your reply lmm. I can see what you mean. However, I do think it has a high risk of building new dogmas without the understanding of when these dogmas should be broken.

Re: My Opinionated Guide To Go

#29

Post by herge »

paukiatwee wrote: post #16

"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?

Re: My Opinionated Guide To Go

#30

Post by kyrra »

cmhamill wrote: post #10

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

Post reply on HN