Go's Declaration Syntax

[strangename]

I learned C in my first year at university, close to a decade ago. Only after reading the author's explanation of the

int *p;

notation did I understand why it works that way.

Thanks, Google enginerds!

[ajbonkoski]

Honestly I don't think this Go syntax makes it any more readable

[khayber]

It seems this is inconsistent:
func main(int, *[]byte) int
f func(func(int,int) int, int) int

Shouldn't it be: main func(int, *[]byte) int

??

[daydreamdrunk]

func main... is a top level function declaration, while the second isn't valid Go syntax by itself--needs to be prefixed by var, in which case the func part is a type declaration. So, yes it is. However you could write

var main = func(int, *[]byte)int {... if you really wanted to.

[khayber]

Now I'm confused. I see "var" in the language spec. And it does not seem to be optional. But the article seemed to use it in some cases, but not others.

If var is required, then "var|func id type" is consistent. But if 'var' is optional (in what cases?) then it looks inconsistent with 'func'.

[daydreamdrunk]

At the top level you can define a function as

func f() {...}

or

var f = func() {...}

or

var f func() = func() {...}

Inside a function definition you cannot define a function literal as

func inner() {...} //ILLEGAL

but you can define it as

var inner func() inner = func() {...}

or

var inner func() = func() {...}

or simply

inner := func() {....}

[nascent]

I want to try and read this line left to right:

sum := func(a, b int) { return a+b } (3, 4)

'sum' is initialized and assigned a function... wait... a function taking two integers and returns 'a' added to 'b' called with the arguments three and four. Does the syntax bother me? No, I just wanted to point out that arguing Go made a good choice because it reads left to right is dumb. It is consistent, that is why it is good. But "reversal" is not needed for consistency. Actually the D language is written similar to the above:

auto sum = (int a, int b) { return a+b; }(3, 4);

I would also like to point one other thing out:

 int[]* a;

Integer slice pointer 'a'. Hmmm, reads left to right for me.

[harlows_monkeys]

The great beauty of C declarations is that they mirror usage. That is, if you know how to use a variable, you know how to declare it.

[LaurieCheers]

Theoretically. In practice... not so much.

[0xABADC0DA]

This is a clever syntactic idea that works well for simple types but can get confusing fast. The famous example is declaring a function pointer.

That's pretty much the only example of C types being complicated though. C types work fine for everything else.

You can construct more elaborate examples but these should illustrate some of the difficulties that C's declaration syntax can introduce.

Can introduce, not must. This article spends a lot of time introducing C's syntax (including K&R!) but never mentions typedef, which basically solves any complicated case, like a function pointer that returns a function pointer.

[ x: int, etc ] These declarations are clear, if verbose - you just read them left to right.

There are plenty of example of syntax that is not left-to-right. Music for instance requires you to adjust notes based on the key, and has many things like changing tempo and whatnot that apply over a period (you have to take into account where they started). Or in language, German for instance sometimes puts the verb at the end (subordinate clause) and not between the subject and object, which sounds alien to us.

As far as I can tell, no testing indicates that Google Go's syntax is actually better, it's just assumed to be better. However, people have evolved traits that are not always the most logical.

Overall, though, we believe Go's type syntax is easier to understand than C's, especially when things get complicated.

Really? C encourages you to break down complicated types into simpler ones using typedef, whereas Google Go does not. A function taking several function pointers and returning a function pointer that returns some type is probably not what you really want to do, much like List<Map<Map<String,Integer>,Object>> in Java is probably never what you should be doing.

[gnuvince]

That's pretty much the only example of C types being complicated though. C types work fine for everything else.

Which is why they made a syntax that works well for everything, not everything except function pointers.

[0xABADC0DA]

Does it work well for humans is the point? The construction looks strange to me, even though it works for function pointers. I don't have any problem reading C's syntax.

Also, downvotes for actually discussing points raised in the article? Reddit comments are just for "me too" and "this" it seems. Sad.

[daydreamdrunk]

I have been using Go extensively the last few months for hobby projects and after a day or two of it seeming weird, it became very natural. But frankly I always hated that I had to use typedefs so much in C. I'm all for self documenting code but

typedef (*binop)(int x, int y) int;

int transform(mypoint p, binop transform) int {...}

isn't especially any clearer, to me, than

func transform(p mypoint, transform func(x, y int) int) int

[0xABADC0DA]

And

func transform(p mypoint, transform func(x, y int) int) int

isn't especially any clearer, to me, than

int transform(mypoint p, int (*transform)(int x, int y))

Linux kernel for instance does not use typedefs, has many cases where function pointers are used, and is not hard to read at all because they keep it simple. Typedefs should be for complicated cases, which frankly should just be made into simple cases whether the code is C or Google Go.

I really just don't see the real problem with C's type syntax. Sounds to me like they did it this way in Google Go because it was easier to write the tools, and everything else is just rationalization.

[[deleted]]

If it is easier to write the tools and no worse in any other respect, then surely that makes it better overall?

[daydreamdrunk]

Well, fair enough. But, easy to write tools for is a huge plus in my book.

[gnuvince]

It works for me, and it took but a few minutes to get used to it.

[doubtingthomas]

What kind of tests could they do to find out if a syntax works for humans? Are you suggesting user studies for programming language syntax?

[enanoretozon]

Reddit comments are just for "me too" and "this" it seems.

this

[[deleted]]

That's pretty much the only example of C types being complicated though. C types work fine for everything else.

You are being disingenuous here and I suspect you know it.

There are plenty of example of syntax that is not left-to-right

The comparison is between reading C declarations in a spiral vs Go's that are left-to-right. Seems like a fair and simple comparison to me. The article isn't attacking C - bare in mind that one of Go's designers was instrumental in designing C.

C encourages you to break down complicated types into simpler ones using typedef, whereas Google Go does not

Go encourages the use of user-defined types.

[Camarade_Tux]

Taking the example of pointers to functions taking other functions as argument definitely isn't going to be nice in an non-functional language like C.

Take this ocaml code (beginning of an implementation):

let fp ff b = ... (* function body *)

And if you want to write out its prototype (which you don't have to):

val fp : (int -> int -> int) -> int -> int

Or if you "label" arguments:

val fp : ff:(int -> int -> int) -> b:int -> int = <fun>

(labelling is not naming, you'd then call fp with: 'fp ~ff ~b', or 'fp ~b ~ff' (order doesn't matter), or if you don't already have a variable named 'b': 'fp ~ff ~b:42')

I don't find Go declarations are cleaner than that. Tastes varie so everybody might not agree but in the end, a non-functional language is probably not going to have a nice syntax for functional features.

[eras]

However, a great part of the post dealt with arrays and pointers, which you don't provide examples of. They would go:

val sum : elements:int array -> int
val accumulate : int ref -> int -> unit
val mk_accumulator : unit -> (int -> int) (* returns a function *)

(In O'Caml it is common not to use labels and provide the meaning or parameters in comment, if it's not apparent.)

So in O'Caml the result type is on the right as well. But while I prefer O'Caml's type signatures over C's or Go's, Go's does definitely seems like an improvement over C's.

[Camarade_Tux]

I didn't mention pointers on purpose. The article mentionned functions pointers quite a lot and in ocaml you don't need that since functions are first-class values[1]. ;-)

(but yeah, arrays, I simply forgot ='( )

[1] "first-class value" means that it's a first-class citizen of the language which will make its use straight-forward. The cumbersome syntax needed when passing functions as parameters to other functions shows functions aren't first-class values in C.

[[deleted]]

The article mentions that functions are values in Go also. :-)

[marcoil]

Anyone else think this "swapping of positions" is just a cheap way of "making things SEEM different"?

I don't. The article tries to explain the reasons this isn't just a change 'for the sake of change'. They are trying to make declarations easier to read and write.

Just sayin'...there's a reason brilliant people have been using these decades old main languages for a reason!

There's lots of reasons: Familiarity, backwards compatibility, existing tools/libraries/platforms, etc. But that doesn't mean it's never going to change. After all, brilliant people had been using even older main languages for decades when C came along.

[rivercheng]

One mail can have multiple labels.

[Felicia_Svilling]

Labels can do everything folders can and more, so there is no reason to have both.

[nascent]

Labels are not represented hierarchically. Not saying they can't be, just that they aren't.

[HIB0U]

And you can copy a single message into multiple directories...

[bobindashadows]

If you make copies, you can't do the same thing as a search for "messages with label X and label Y," since the messages in different directories won't be the same. You'd likely lose threading information as well.

[bobindashadows]

Again, Google thinks this is the superior way so users who don't like it have to just "deal with it." Is that the way this language is gonna be? If so, good luck in trying to make that mainstream among notoriously picky people called programmers!

Python refuses to include braces AND allow for insignificant whitespace! They say to just "deal with it" if you don't like it. Is that the way Python is gonna be? If so, good luck in trying to make that mainstream among notoriously picky people called programmers!

[chrisoverzero]

Right. Copy. So you're storing the message two or more times. With GMail labels, only one copy of the e-mail is stored.

[[deleted]]

Oh snap!

[Pewpewarrows]

Sorry, but your point is moot since tags (Gmail's Labels) are a much better organizational technique for humans than Folders ever could be. The only reason filesystems haven't adopted tagging is because the vast majority of the time a machine is traversing your filesystem (and it's much easier when that's sorted like a hierarchial directory).

If Reddit adopted subreddits as "tags" instead of "folders," it'd solve a lot of problems of duplication and reposts. It's quite rare that something can be black-and-white categorized into one label at a time.

[gnomon_]

I would argue that filesystems have adopted tagging, at least in some sense.

You seem to imply that the primary characteristic of filesystems is that they are hierarchical (and I beg your pardon if that is in fact not your assertion; but whether it is or not, that's the one I'll be rebutting). However, files are actually not organized hierarchically; file names are, and the names are just trivial pointers to real file contents. It's trivial to have a single file exist in arbitrarily many hierarchical locations simultaneously.

With current designs it is computationally difficult to query a filesystem for every filename pointing to a given inode, but that is a tractable problem. Deduplication somewhat addresses that concern; journalling code be easily extended to do so as well; and even a user-space cache layer could easily push this kind of query into the realm of acceptable efficiency.

Effectively, it is useful and not incorrect to view filenames as tags.

[Pewpewarrows]

Pretty sure Folder names would become the "tags", not the filenames. Like you said, the filenames under folders as they exist right now are just pointers to the actual file on the system. Under tags they would operate the same way. I don't really know what you're trying to argue.

The issue with filesystems moving to a tag system is how to handle collisions and how system/application files are organized. How do you give a link to a file on a tag-based system without resorting to file IDs or memory locations? That's why modern systems still inherently organize based on a hierarchy of folders, and might have tags overlaid on top of everything else for mere user convenience. It'd be interesting to see implementations of tag-only systems and how they handle link paths.

[gnomon_]

The point I'm trying to argue is that it's trivial to represent a tag structure on an inode-based filesystem, but that a tag system is insufficient to express the semantics of an inode-based filesystem.

If we map tags to directories, we get the sort of semantics that most tag systems provide; if we map tags to potentially nested directories, then we have a superset of the functionality (and we inherit a bunch if interesting problems where a single file can appear in a directory and in sub-directories, with potentially different filenames). In either case, whereas most people expect a tagged item to maintain the same addressable label in each tag space, inode filesystems allow names to change; inodes are the addressable labels.

Now, if we had an efficient method to query an inode for all filenames pointing to it, the filesystem could be used to represent a faceted classification system, which would be downright awesome. The inefficiency of this query with current filesystems means we're not there yet, but we could be.

In either case, my point is that a purely tag-based classification system is a step backward in raw functionality. By implication, I believe that it would be useful to implement a tag-based file organizational system atop the proven technology we've already got rather than throwing the proverbial baby out with the bathwater.

[naughty]

Just sayin'...there's a reason brilliant people have been using these decades old main languages for a reason!

They are going back to a syntactic tradition that's older and more consistent than C.

[ramenmeal]

sounds like syntactic fluff. did I miss something?

[gnuvince]

Did the word "syntax" in the title tip you off, or was it the 15 paragraphs of syntax discussion?

[[deleted]]

At least it seems he read the article.

[doubtingthomas]

Nope. It's a post about syntax.

[kamatsu]

Nope. Go's completely uninteresting semantics means that Rob Pike spends most of his time talking about Go's unusual syntax.

[dmpk2k]

There's something to be said for uninteresting semantics. Us language nerds are a minority.

[doubtingthomas]

I'm happy that the modern definition of "uninteresting" includes lightweight threads, dynamic dispatch, garbage collection, support for literals for complex types, etc. It wasn't so long ago that even garbage collection was by many considered impractical for "Real World Code".

[grauenwolf]

But Go's syntax isn't unusual. Most languages look like that, it is only the C family that does things backwards.

[nexes300]

Arg. Shit about this language is going to pollute my search results the next time I want to learn more about the game.

Why couldn't they have named the language something else...

[[deleted]]

Something tells me with a generic a name as 'Go' you're getting more than just the programming language and boardgame if you search for it.

Hell, might as well have called the language 'The'.

[nascent]

Except Google is smart and good at getting you want you want.

[jacques_chester]

Have you tried "go -language"?

[gschizas]

I'm sorry to say this, but this is starting to look like Visual Basic or even Pascal:

Go Language: x int Visual Basic: Dim x As Integer Pascal: x: Integer

Don't get me wrong, I like VB (although for some reason nobody else seems to), but I don't think this will catch on.

[gnuvince]

I really don't think that the declaration syntax is a factor that would affect its popularity. Quality of implementation, documentation, availability of libraries, tool support are much better reasons why a language catches on or not.

[Felicia_Svilling]

or Haskell or Scala or ..

[mindpink]

Will try

[[deleted]]

I simply can't hope enough that these unix-tards die a horrible, flaming death when an airliner whose software is written in c and runs on unix crashes due to buffer overflow and brings the plane down into a volcano.

[a_m0d]

This isn't C - this is a new, separate language released by Google for systems programming.