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

Go's first commit

github.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Go's first commit

#21

Post by buro9 »

christophersu wrote: post #6
bigstumpy wrote: post #2

I don't get it. According to the github history there was a hello world commit in 1972, conversion to C in 1974, conversion to ansi-c in 1988, then the next commit was the first go specification in 2008. Git was written in 2005. What did these hello world commits have to do with go? Why are they in the git history?

> According to the github history there was a hello world commit in 1972 > Git was written in 2005. Not sure about this specific case, but it isn't uncommon to migrate from another version control system (e.g. Subversion) to Git while maintaining the past history.

My oldest photo in Google Photos is from 1994.

My oldest email in Gmail is from 1996.

My oldest file in Google Drive is from 1998.

All of which pre-date their current storage (and some of which pre-date the company that created the current storage).

None of which is as important as anything in a VCS in terms of wanting to keep history intact.

BTW: If any Google engineer is present: Gmail search over mail older than a decade is terrible. Just terrible.

Re: Go's first commit

#22

Post by ori_b »

dilap wrote: post #8
dantaylor08 wrote: post #4

Much more interesting (first language spec commit): https://github.com/golang/go/commit/18c5b488a3b2e218c0e0cf2a...

I wonder why they got rid of this one > - new methods can be added to a struct outside the package where the struct is declared (need to think through all implications)

It's hard to compile efficiently, because you need to efficiently do the method lookup in the implementation.

Re: Go's first commit

#23

Post by maramono »

What I find interesting is that there is absolutely no mention of the word 'test' in the spec. With unit testing and TDD/BDD so ubiquitous now, perhaps new languages should be created with testing support baked in instead of it beng added as an after-thought.

Re: Go's first commit

#25

Post by ngrilly »

maramono wrote: post #23

What I find interesting is that there is absolutely no mention of the word 'test' in the spec. With unit testing and TDD/BDD so ubiquitous now, perhaps new languages should be created with testing support baked in instead of it beng added as an after-thought.

This commit is a joke, a wink.

Re: Go's first commit

#26

Post by junke »

junke wrote: post #17
ecnahc515 wrote: post #14

Earlier quoted context omitted.

I'd have to guess it would be conflict resolution. Imagine two separately imported packages for which you didn't write that add a method in on a type from a third package you didn't write, all with the same name/method signature. How does the compiler you know which of the implementations to use?

Compiler warning. --- (edit) The example, while being possible, looks quite improbable. If it is only a matters of conflicting names, qualified names should be able to resolve the ambiguity; here I suppose you imagine implementing the same interface for the same type differently in two packages. That a package implements an interface for the same external method for a third-party type is already dubious. Now, you hav…

I mean dispatch in general, not necessarily dynamic dispatch.

Re: Go's first commit

#28

Post by 4ad »

dilap wrote: post #8
dantaylor08 wrote: post #4

Much more interesting (first language spec commit): https://github.com/golang/go/commit/18c5b488a3b2e218c0e0cf2a...

I wonder why they got rid of this one > - new methods can be added to a struct outside the package where the struct is declared (need to think through all implications)

It doesn't work well with interfaces.

A method defined in a new package might break a type switch (or some reflection-based code) in another package.

Plus it's unclear what should happen with interfaces when multiple packages define methods with the same name.

Re: Go's first commit

#29

Post by django1993 »

dilap wrote: post #8
dantaylor08 wrote: post #4

Much more interesting (first language spec commit): https://github.com/golang/go/commit/18c5b488a3b2e218c0e0cf2a...

I wonder why they got rid of this one > - new methods can be added to a struct outside the package where the struct is declared (need to think through all implications)

Maybe because structs have some fields private and some public. To add a method outside the package would be to make those private fields visible in the method outside the package which then allows such methods to manipulate the struct and that will break the abstraction provided by it.

Re: Go's first commit

#30

Post by junke »

4ad wrote: post #28
dilap wrote: post #8

Earlier quoted context omitted.

I wonder why they got rid of this one > - new methods can be added to a struct outside the package where the struct is declared (need to think through all implications)

It doesn't work well with interfaces. A method defined in a new package might break a type switch (or some reflection-based code) in another package. Plus it's unclear what should happen with interfaces when multiple packages define methods with the same name.

> A method defined in a new package might break a type switch (or some reflection-based code) in another package.

In that case the code would break because it assumes too much. If the language was designed differently, people would code differently too. This is like having a Java abstract class which "knows" all the possible subclasses in advance: if it breaks, it is the responsibility of that abstract class for having too much coupling.

> Plus it's unclear what should happen with interfaces when multiple packages define methods with the same name.

I am not sure I understand: if methods are defined in different packages, they have different qualified names, don't they? is there any ambiguity here?

Post reply on HN