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

Go Lang: Comments Are Not Directives

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 222 posts

Re: Go Lang: Comments Are Not Directives

#121

Post by tomjen3 »

zaphar wrote: post #103
breakingcups wrote: post #27

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This in itself isn't bad, but the problem it causes is that the Googlers (who do not experience the pain that other users of the language do) are still the…

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This is the most bizarre criticism of go I have ever heard. Go has the best tooling of any language I have ever used bar none. A cursory look at: https://go…

Eclipse has had those things for years for Java. Yeah that is not editor agnostic but when you sit down and learn a platform learning an IDE isn't a big deal.

Speaking of which I do not see any official recommendation of an IDE for Go.

Re: Go Lang: Comments Are Not Directives

#122

Post by tree_of_item »

breakingcups wrote: post #27

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). This in itself isn't bad, but the problem it causes is that the Googlers (who do not experience the pain that other users of the language do) are still the…

> The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem.

I'd say you got this exactly backwards. The language is mediocre, but the tooling and ecosystem are great.

The `go` command in particular is something I really want in other languages: no messing around with build files or monsters like `cabal`.

Re: Go Lang: Comments Are Not Directives

#123

Post by lclarkmichalek »

chimeracoder wrote: post #98
TheDong wrote: post #75

Earlier quoted context omitted.

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 han…

> 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), This is the advantage of having errors be interfaces rather than concrete values. Once you learn how to use it, it's a strength. The usage of structs that satisfy the interface (as in PathError) is clearly do…

    $ curl http://golang.org/pkg/reflect/ | grep panic | wc -l
    79

Re: Go Lang: Comments Are Not Directives

#124

Post by whateveracct »

vowelless wrote: post #117
TheDong wrote: post #75

Earlier quoted context omitted.

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 han…

> The math library, as mentioned above, is pretty darn iffy. My biggest disappointments early on was not even having a Max/Min function for ints.

But there is for float64 ;)

I think this is a classic case of Go's need for "simplicity" hamstringing the language. When handling min/max, they had a few options:

1) Treat numbers as a special case and have a polymorphic min/max that operates on any number type. This is out of the question because it is obtuse and irregular and neither of those things are the "Go way"

2) Properly abstract over numbers somehow. This can be weakly done using Go interfaces but 1) it would require >, 3) Write a min/max for every number type. Due to lack of overloading, each would be named accordingly (minInt64 etc). This is ugly and definitely not the "Go way"

4) Just use the most "general" number type and write min/max for that. You can just cast on the way in and out so this "works". It doesn't require API bloat or more language features, so it's the "Go way"

Re: Go Lang: Comments Are Not Directives

#125

Post by tangent128 »

bozoclownn wrote: post #111
scott_s wrote: post #104

I don't know enough of the matter to have an informed view, but I think it's worth noting that there is precedent for this sort of thing. Take from one of my Python scripts: #!/usr/bin/env python http://en.wikipedia.org/wiki/Shebang_%28Unix%29

I would add that this technically is a (ba)sh script, not a Python script.

On *nix systems, the #! is parsed by the kernel as a magic number. sh/bash are not involved.

Re: Go Lang: Comments Are Not Directives

#126

Post by oldmanjay »

bane wrote: post #76

As soon as you start using comments for something other than comments or documentation, you've basically admitted the language is broken and you end up becoming Java.

I don't understand the conclusion. Java is certainly verbose and a fair bit aggressively ugly, but it has consistent syntax and I've never before heard anyone describe it as broken. care to amplify?

Re: Go Lang: Comments Are Not Directives

#127

Post by stefantalpalaru »

bozoclownn wrote: post #111
scott_s wrote: post #104

I don't know enough of the matter to have an informed view, but I think it's worth noting that there is precedent for this sort of thing. Take from one of my Python scripts: #!/usr/bin/env python http://en.wikipedia.org/wiki/Shebang_%28Unix%29

I would add that this technically is a (ba)sh script, not a Python script.

No, you can use any program to launch executable scripts that start with #!. The kernel sees that magic number at the beginning of the file, tries to read a program path and arguments, adds the script as the last arg and executes the whole thing.

The various shells are just a subset of the possible programs used.

Re: Go Lang: Comments Are Not Directives

#128

Post by tomjen3 »

enneff wrote: post #6
bsaul wrote: post #5

Agree as well. They could use the same convention as typescript and use a triple slash instead. That wouldn't change much of the language and impact IDEs, but at least distinguish between human comments and tooling instructions.

What's the difference between "///" and "//go:"? The latter is Go's official convention, it's just that unfortunately some of our older mechanisms predate the convention.

Realistically there is no big difference between /// and //go: although the former is well used (Java, C# and, probably more importantly for Golang, jsdocs are written as /). Either would be useful.

But the complaint is about //foobar: and that is just confusing.

Re: Go Lang: Comments Are Not Directives

#129

Post by tomjen3 »

yyhhsj0521 wrote: post #85

In Python, following comment #- -utf8- - indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.

That may have been a hack based on emacs where you can set various file options with comments like that.

Re: Go Lang: Comments Are Not Directives

#130

Post by stefantalpalaru »

henesy wrote: post #70
nicerobot wrote: post #63

Just because _you_ are locked into a mentality about a meaning for // does not mean we all are. Explain to me why formatted/structured text can not appear after a // in a file. If your editor parsed the text and formatted it to look meaningful, like code, would that help?

I'm not sure why it bothers everyone so much. I might be missing something, but unless people are writing their comments in a very specific style then it shouldn't cause issues. From the help: "(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally." It just seems like the code is distinctive enough it shouldn't cause prob…

What part of "all syntax should be validated" don't you understand? By putting that syntax in comments, syntax errors will not trigger any output from the tools because they remain valid free-form comments.
Post reply on HN