5 ms·

Want to know what's even worse? Using comments for something but not parsing the syntax tree. In go 1.4, save the following to a file and run 'go generate' on

by TheDong 12y ago

Want to know what's even worse? Using comments for something but not parsing the syntax tree. In go 1.4, save the following to a file and run 'go generate' on it: https://play.golang.org/p/9WJtxClRXr https://play.golang.org/p/9WJtxClRXr (I'd make it run in the playground, but you can't 'fork exec', so exec.Command($GOBIN, generate) won't work sadly) Even though that code has no comments (only a multi-line string), go generate will run and print out a '\'. I also used that generate command to point out that with generate, as it exists in 1.4, there's actually NO WAY to print out a dollar sign. The dollar-sign part of this is fixed in master (so go1.5), but it was fixed not by allowing '\$', but by the bizarre $DOLLAR environment variable. See https://go-review.googlesource.com/#/c/8091/ https://go-review.googlesource.com/#/c/8091/ These "features" make the use of comments as directives even worse, because it's NOT comments being used as directives in the case of go generate, but simple string matching. It literally just loops through lines of text and checks if it startswith the correct substring. This was, of course, done due to lazyness (same as $DOLLAR and many other 'features' of go), and the lazyness is starting to show through the cracks here and there. Go often prefers pain for the programmer for the compiler developer's life being simpler by about 5 minutes.

eis 12y ago
That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. Which is amplified by the previous statements regarding for example generics where they said they wont introduce them until they find a really good way to do it but then crank out half baked stuff like this.
- coldtea 12y ago
  >I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?
  - andrewchambers 12y ago
    Go has the best and most consistent std library I have seen.
    - coldtea 12y ago
      It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.
      - krylon 12y ago
        Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used to be, at least) pretty huge. Not that this invalidates your point.
        gravypod 12y ago
        Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)
    - TheDong 12y ago
      Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), and sometimes panics. If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions. The math library, as mentioned above, is pretty darn iffy. The existence of both 'path' and 'filepath' is possibly a mistake. The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed. Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on). Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.
- tmaly 12y ago
  I have been using Perl for a long time, it did not get everything right when it first rolled out its object system. Through incremental improvements and backward compatibility the language has become very stable. Go is just getting to 1.5, so I expect it to have some issues at the beginning.
  - threeseed 12y ago
    That $DOLLAR fix isn't just some "issue" at the beginning as though it was a design mistake or architectural oversight. It is flat out sloppy work. If you are creating a programming language that wants to maintain backwards compatibility surely every check in you make would be as close to perfect. No ?
  - danesparza 12y ago
    Agreed: Languages can evolve. Perl has been around since 1987. I would expect Go (first released in 2009) to have learned valuable lessons from earlier failures. This particular set of features doesn't appear to be very thoughtful.
Merkur 12y ago
uh - that's really bad! :(
ab5tract 12y ago
"Go often prefers pain for the programmer for the compiler developer's life being simpler by about 5 minutes." Interesting contrast to the philosophy of Perl 6: 'torture the implementor on behalf of the user'.
- catwell 11y ago
  This is exactly the "Worse is Better" debate. We know which horse won last time, I would bet on the same one this time too.
anon3_ 12y ago
https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X "Every language contains novel features and omits someone's favorite feature. Go was designed with an eye on felicity of programming, speed of compilation, orthogonality of concepts, and the need to support features such as concurrency and garbage collection. Your favorite feature may be missing because it doesn't fit, because it affects compilation speed or clarity of design, or because it would make the fundamental system model too difficult. If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X."

by TheDong 12y ago

eis 12y ago

That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. Which is amplified by the previous statements regarding for example generics where they said they wont introduce them until they find a really good way to do it but then crank out half baked stuff like this.

coldtea 12y ago
>I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?
- andrewchambers 12y ago
  Go has the best and most consistent std library I have seen.
  - coldtea 12y ago
    It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.
    - krylon 12y ago
      Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used to be, at least) pretty huge. Not that this invalidates your point.
      - gravypod 12y ago
        Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)
  - TheDong 12y ago
    Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), and sometimes panics. If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions. The math library, as mentioned above, is pretty darn iffy. The existence of both 'path' and 'filepath' is possibly a mistake. The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed. Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on). Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.
tmaly 12y ago
I have been using Perl for a long time, it did not get everything right when it first rolled out its object system. Through incremental improvements and backward compatibility the language has become very stable. Go is just getting to 1.5, so I expect it to have some issues at the beginning.
- threeseed 12y ago
  That $DOLLAR fix isn't just some "issue" at the beginning as though it was a design mistake or architectural oversight. It is flat out sloppy work. If you are creating a programming language that wants to maintain backwards compatibility surely every check in you make would be as close to perfect. No ?
- danesparza 12y ago
  Agreed: Languages can evolve. Perl has been around since 1987. I would expect Go (first released in 2009) to have learned valuable lessons from earlier failures. This particular set of features doesn't appear to be very thoughtful.

Merkur 12y ago

uh - that's really bad! :(

ab5tract 12y ago

"Go often prefers pain for the programmer for the compiler developer's life being simpler by about 5 minutes." Interesting contrast to the philosophy of Perl 6: 'torture the implementor on behalf of the user'.

catwell 11y ago
This is exactly the "Worse is Better" debate. We know which horse won last time, I would bet on the same one this time too.

anon3_ 12y ago

https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X "Every language contains novel features and omits someone's favorite feature. Go was designed with an eye on felicity of programming, speed of compilation, orthogonality of concepts, and the need to support features such as concurrency and garbage collection. Your favorite feature may be missing because it doesn't fit, because it affects compilation speed or clarity of design, or because it would make the fundamental system model too difficult. If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X."