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

Go 1.4 is released

blog.golang.org

Post reply on HN
Print view View original

261–265 of 265 posts

Re: Go 1.4 is released

#261

Post by jrockway »

natefinch wrote: post #231
xienze wrote: post #210

Earlier quoted context omitted.

Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...

This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing. The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're lucki…

This is the big insight. Instead of trying to inherit code, figure out what that code does that interesting, and allow that code to do the interesting things without being inside the class. For example, imagine your class has a "WriteToFile" method. Instead of that, it should just have a method to return its representation, delegating the responsibility of writing to a file to something else. (Of course, the fact that a file can be written to should also be one of those "interesting things", and the thing that writes shouldn't care that it's backed by a file.)

Instead of

foo.WriteToFile("/tmp/foo")

You might write:

file.Write(foo.Representation()).

I promise that most inheritance in the real world is attempting to reuse something like "WriteToFile". "I wouldn't want to copy-paste the file-writing code, so I'll inherit from something that can write itself to the file." No. Don't do that.

Re: Go 1.4 is released

#262

Post by dbaupp »

igouy wrote: post #259
dbaupp wrote: post #257

Earlier quoted context omitted.

A few comments up you are saying that Steve's problems with the benchmarks game are invalid and the game isn't considered for the sort of comparison Steve (and many others) dislike because it says all over the website that > These are not the only compilers and interpreters. These are not the only programs that could be written. These are not the only tasks that could be solved. These are just 10 tiny examples. etc.…

>>A few comments up you are saying that … isn't considered for the sort of comparison … Please quote my words that you claim say that.

> 1) That might be a credible criticism if the benchmarks game claimed to be some kind of exhaustive comparison.

(I.e. literally your paragraph before the thing I quoted in my comment just above.)

Re: Go 1.4 is released

#263

Post by igouy »

dbaupp wrote: post #262
igouy wrote: post #259

Earlier quoted context omitted.

>>A few comments up you are saying that … isn't considered for the sort of comparison … Please quote my words that you claim say that.

> 1) That might be a credible criticism if the benchmarks game claimed to be some kind of exhaustive comparison. (I.e. literally your paragraph before the thing I quoted in my comment just above.)

Those words do not say that there are no people who "will do naive comparisons using the benchmarks game".

Those words say that they do so in-spite of what's shown on the benchmarks game website, not because of what's shown.

Re: Go 1.4 is released

#264

Post by igouy »

dbaupp wrote: post #257
igouy wrote: post #253

Earlier quoted context omitted.

>>… but it doesn't stop people from comparing languages based on the benchmarks game. How could it? Some kind-of black magic? The benchmarks game is just a resource. In the example you provided a discussion is taking place, and some opinions are being challenged.

A few comments up you are saying that Steve's problems with the benchmarks game are invalid and the game isn't considered for the sort of comparison Steve (and many others) dislike because it says all over the website that > These are not the only compilers and interpreters. These are not the only programs that could be written. These are not the only tasks that could be solved. These are just 10 tiny examples. etc.…

>>…any discussion about the benchmark game degenerates into…Given the comments you have already made, that seems to be a self fulfilling prophesy.

Re: Go 1.4 is released

#265

Post by codemac »

Gracana wrote: post #195
bradfitz wrote: post #30

Earlier quoted context omitted.

You seem to be confusing compilers and build systems. You can use whatever build system you'd like and with whichever compiler.

Is it possible to do away with the typical Go project directory structure? I thought all that was enforced by the tools, but it's possible that I didn't dig deep enough to uncover greater flexibility.

No it's not if you ever intend to type `go`.

The go team has decided that the go language doesn't depend on any build system, but pushes a single build system one that requires source code compatibility and provides no benefit over many existing and easy to use build systems (makefiles, tup, etc).

Post reply on HN