5 ms·

"Go is syntactically a big language. Neugram’s front end has to match it, and that’s a lot of work, much of which is still to do." I appreciate the sentiment –

"Go is syntactically a big language. Neugram’s front end has to match it, and that’s a lot of work, much of which is still to do." I appreciate the sentiment – that there's a lot of work left to do – but isn't the assertion about syntax size false? I thought Go's syntax was quite small compared to other popular languages? It only has 25 reserved words (Java has 50+) and was designed in part to be uniform and easy to read.

crawshaw 9y ago
I made this point poorly, because I agree with you that Go is quite easy to read and very predictable. With more words: I have written a parser and type checker for an ML-style language, with parametric types and several other neat tricks in it, and I've now written a parser and type checker for a good subset of Go. The latter has been far more work. I am not entirely sure how to explain the work. Go has lots of syntactic and type conveniences that are easy to use and read, but quite difficult to implement. As there are few implementers and many users, I think the original designers of Go picked well when they put the work on us implementers.
- ansible 9y ago
  What stopped you from using the parsing in the standard library?
  - crawshaw 9y ago
    Because Neugram is a different language. It is so only in small ways, but they add up when you are in the parser, and especially in the type checker. First is the fact that the top level is statements, not declarations. That would mean heavy modification to the go/parser package to make the inner-function statement parser the top level. Second is the fact I need to parse incrementally, to implement a REPL. That would not require serious modification to go/parser, but it would to go/types. Third is I wanted to experiment with new syntax. It was quicker to get to that experimentation by working from scratch rather than adopting go/parser and go/types. Fourth is there are some fundamental things I would like to do differently, particularly around how comments are handled. I haven't got there yet. In retrospect, if the new Go parser inside cmd/compile existed when I started this, I probably would have started from there. (It does many of the things I wanted to do to go/parser.) I suspect I still would have ended up with my own type checker though, if for no other reason than incremental type checking.
    - ansible 9y ago
      I've toyed with making some kind of interpreter for Go. Something that integrates well with it, giving access to all the libraries, channels, goroutines and such. Discussing this with an acquaintance, we decided the best scripting language for Go was... Go. It is interesting to see that you've headed in the same general direction, though you've thought things through much further than we did. I'll have to try it out.
- ainar-g 9y ago
  Can you elaborate on what syntactic conveniences are difficult to implement and why? Language design is on of my hobbies, so I really would like to know that.
  - mjburgess 9y ago
    At a guess, I would describe it as a trade off between syntax and semantics. Languages that have simpler syntax tend to have far more complex semantics (to infer what's missing, etc.). Eg. python's semantics is horribly complex: "hello".upper() is something like str.__dict__['upper']("hello")) -- which is all run-time. Whereas say a C++ version amounts to quite a simple run-time function call on some bytes.
  - crawshaw 9y ago
    One good example is untyped constants. They form a large extension to the type system only present at compile time. It is a good example because there is an excellent blog post describing them in detail: https://blog.golang.org/constants https://blog.golang.org/constants In particular note the difference between const hello = "Hello, 世界" and const typedHello string = "Hello, 世界" one of these can be assigned to named string types, the other cannot. As a user of Go I find untyped constants to be extremely useful. They almost always do what I want without surprise. Implementing them however, is not trivial. A tricker example is embedding. It adds a lot of complexity to the type system. As a user, it can be a bit surprising, but I admit it is very useful.
TheDong 9y ago
Go's small number of keywords is deceptive. Let's look at some of Java's keywords which have no analogue in the Go specification's list of keywords 1. boolean: go has the `bool` type, but it's a builtin, not a keyword, so it doesn't count against it. 2. byte: same thing 3. null: Go's `nil` is again not counted as a keyword in their list of 25 .... And hey, that accounts for almost the entire difference if you count all the primitive types. Go, on the other hand, does not consider those "keywords", which leads to absolutely silly behaviour. A programmer can accidentally redefine `len` to be a variable, and then `len(x)` will be an error later. Because go has a ton of important builtins which aren't reserved keywords, you can write incredibly confusing code: https://play.golang.org/p/-xChCblMEh https://play.golang.org/p/-xChCblMEh For a nice list, check out https://play.golang.org/p/yjkxqVY4eo https://play.golang.org/p/yjkxqVY4eo ... yeah, Go's small number of keywords is often touted by Gophers, but really it's because the go team made this incredibly stupid decision. If you counted the same sorts of things as keywords that java did, Go would have almost exactly the same number... and more problems would be caught at compile-time (like `len := 1`) .
- Vendan 9y ago
  I think the true argument is that you can read the Go specification in a slightly extended sitting, whereas (for example), the current working draft for C++ is 1416 pages.
  - kibwen 9y ago
    The Go specification is not the same sort of document as the C++ or Java specifications. Go is doubtlessly less extensive than C++ or Java, but it would be dishonest to attempt to leverage their respective specification documents as yardsticks for complexity. If Go were submitted to a standards body such as ISO, the drafting committee would produce a more detailed and more verbose document than currently exists.
  - camus2 9y ago
    Is the Go "specification" considered a normative spec, like ECMASCRIPT spec? And AFAIK the C++ draft also covers the std lib.
diggan 9y ago
Guess it's relative. Different lisps are probably syntactically the smallest group of languages, but compared to Java (which most people would say is a bloated language) it's a tiny one.

crawshaw 9y ago

I made this point poorly, because I agree with you that Go is quite easy to read and very predictable. With more words: I have written a parser and type checker for an ML-style language, with parametric types and several other neat tricks in it, and I've now written a parser and type checker for a good subset of Go. The latter has been far more work. I am not entirely sure how to explain the work. Go has lots of syntactic and type conveniences that are easy to use and read, but quite difficult to implement. As there are few implementers and many users, I think the original designers of Go picked well when they put the work on us implementers.

ansible 9y ago
What stopped you from using the parsing in the standard library?
- crawshaw 9y ago
  Because Neugram is a different language. It is so only in small ways, but they add up when you are in the parser, and especially in the type checker. First is the fact that the top level is statements, not declarations. That would mean heavy modification to the go/parser package to make the inner-function statement parser the top level. Second is the fact I need to parse incrementally, to implement a REPL. That would not require serious modification to go/parser, but it would to go/types. Third is I wanted to experiment with new syntax. It was quicker to get to that experimentation by working from scratch rather than adopting go/parser and go/types. Fourth is there are some fundamental things I would like to do differently, particularly around how comments are handled. I haven't got there yet. In retrospect, if the new Go parser inside cmd/compile existed when I started this, I probably would have started from there. (It does many of the things I wanted to do to go/parser.) I suspect I still would have ended up with my own type checker though, if for no other reason than incremental type checking.
  - ansible 9y ago
    I've toyed with making some kind of interpreter for Go. Something that integrates well with it, giving access to all the libraries, channels, goroutines and such. Discussing this with an acquaintance, we decided the best scripting language for Go was... Go. It is interesting to see that you've headed in the same general direction, though you've thought things through much further than we did. I'll have to try it out.
ainar-g 9y ago
Can you elaborate on what syntactic conveniences are difficult to implement and why? Language design is on of my hobbies, so I really would like to know that.
- mjburgess 9y ago
  At a guess, I would describe it as a trade off between syntax and semantics. Languages that have simpler syntax tend to have far more complex semantics (to infer what's missing, etc.). Eg. python's semantics is horribly complex: "hello".upper() is something like str.__dict__['upper']("hello")) -- which is all run-time. Whereas say a C++ version amounts to quite a simple run-time function call on some bytes.
- crawshaw 9y ago
  One good example is untyped constants. They form a large extension to the type system only present at compile time. It is a good example because there is an excellent blog post describing them in detail: https://blog.golang.org/constants https://blog.golang.org/constants In particular note the difference between const hello = "Hello, 世界" and const typedHello string = "Hello, 世界" one of these can be assigned to named string types, the other cannot. As a user of Go I find untyped constants to be extremely useful. They almost always do what I want without surprise. Implementing them however, is not trivial. A tricker example is embedding. It adds a lot of complexity to the type system. As a user, it can be a bit surprising, but I admit it is very useful.

TheDong 9y ago

Go's small number of keywords is deceptive. Let's look at some of Java's keywords which have no analogue in the Go specification's list of keywords 1. boolean: go has the `bool` type, but it's a builtin, not a keyword, so it doesn't count against it. 2. byte: same thing 3. null: Go's `nil` is again not counted as a keyword in their list of 25 .... And hey, that accounts for almost the entire difference if you count all the primitive types. Go, on the other hand, does not consider those "keywords", which leads to absolutely silly behaviour. A programmer can accidentally redefine `len` to be a variable, and then `len(x)` will be an error later. Because go has a ton of important builtins which aren't reserved keywords, you can write incredibly confusing code: https://play.golang.org/p/-xChCblMEh https://play.golang.org/p/-xChCblMEh For a nice list, check out https://play.golang.org/p/yjkxqVY4eo https://play.golang.org/p/yjkxqVY4eo ... yeah, Go's small number of keywords is often touted by Gophers, but really it's because the go team made this incredibly stupid decision. If you counted the same sorts of things as keywords that java did, Go would have almost exactly the same number... and more problems would be caught at compile-time (like `len := 1`) .

Vendan 9y ago
I think the true argument is that you can read the Go specification in a slightly extended sitting, whereas (for example), the current working draft for C++ is 1416 pages.
- kibwen 9y ago
  The Go specification is not the same sort of document as the C++ or Java specifications. Go is doubtlessly less extensive than C++ or Java, but it would be dishonest to attempt to leverage their respective specification documents as yardsticks for complexity. If Go were submitted to a standards body such as ISO, the drafting committee would produce a more detailed and more verbose document than currently exists.
- camus2 9y ago
  Is the Go "specification" considered a normative spec, like ECMASCRIPT spec? And AFAIK the C++ draft also covers the std lib.

diggan 9y ago

Guess it's relative. Different lisps are probably syntactically the smallest group of languages, but compared to Java (which most people would say is a bloated language) it's a tiny one.