Live data from Hacker News

Half a decade with Go

blog.golang.org

101–110 of 257 posts

Re: Half a decade with Go

#101
post #99

Earlier quoted context omitted.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is.

Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both the praise and the criticism.

Powerful languages can cause other issues, but they do enable certain things that weaker languages simply never can.

Re: Half a decade with Go

#102

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever getting in my way. Let's talk for a second about the tiny little function

io.Copy(dst io.Writer, src io.Reader)

It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface.

As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well.

Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...

Re: Half a decade with Go

#103
post #93

Sometimes I wonder: if Apple's new language had been Go, and Google's new language had been Swift, how would reaction by developers and adoption have differed? (You can also run this thought exercise with Go and Rust, if you prefer a different competition between self-proclaimed systems languages.)

I'm not totally sure how a non-optionally garbage-collected language with a runtime could ever be called a "systems language."

Re: Half a decade with Go

#104
post #31
post #17

You still need a Makefile if you use things like godep, or their new `go generate` stuff. They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!

I don't know why people hate on Makefiles, make is great! Does exactly what it says on the tin.

I don't hate Makefiles, in fact they're quite wonderful in languages that have file based build systems (see: C). I'm just tired of the go team touting that they are unnecessary.. except that every major go project has one (or something like make.go in camlistore).

Re: Half a decade with Go

#105
post #99

Earlier quoted context omitted.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

Do you have a source? I don't find your claim implausible, however I would like to know how you came to that conclusion.

Re: Half a decade with Go

#106
post #99

Earlier quoted context omitted.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

More code will be written in COBOL this year alone than has ever been written in Go.

Re: Half a decade with Go

#108
post #99

Earlier quoted context omitted.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is. Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both th…

C and Java are not the subject here.

Re: Half a decade with Go

#109
post #99

Earlier quoted context omitted.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

More code will be written in COBOL this year alone than has ever been written in Go.

you're clueless.

Re: Half a decade with Go

#110
post #99

Earlier quoted context omitted.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

Do you have a source? I don't find your claim implausible, however I would like to know how you came to that conclusion.

the internet is my source.
Post reply on HN