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
Go Lang: Comments Are Not Directives
111–120 of 222 posts
Re: Go Lang: Comments Are Not Directives
#112Earlier quoted context omitted.
> 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?
Go has the best and most consistent std library I have seen.
Re: Go Lang: Comments Are Not Directives
#113In Python, following comment #- -utf8- - indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.
I was going to say it's the only one Python 2 has, AFAIK. So they've kept it reaosnable there, but then I remembered this: https://www.python.org/dev/peps/pep-0484/#id24 Which is pretty scary, IMHO. Python is productive, but I always questioned some of the choices in the language design (broken lambdas, etc -- though the implementation of list comprehensions were great so I just learned to love them) -- but it seems…
Remember that Python has supported function annotations since 3.0 [0]. Python 3.5 will only add the option to type check those same annotations.
Any type annotations that can be checked by Python 3.5 can also be parsed by earlier versions of Python, though without being checked.
The only wart in this master plan is specifically the one where you want to type annotate variables (as opposed to functions). Comments are the only way they could do this in a backwards compatible way.
The Python devs are well aware of the ugliness of this compromise, which is why they end the section you linked to with this:
> If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version.
I can't comment on Go, but I wouldn't call Python's choice here unreasonable.
Re: Go Lang: Comments Are Not Directives
#114Earlier quoted context omitted.
I too like the idea that comments are more than blabber. I do use comments like //BUG: //TODO: and //HOT: My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong. Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here. A directive…
Now argue against yourself and prove you understand why you hit resistance.
Re: Go Lang: Comments Are Not Directives
#115Earlier quoted context omitted.
And there's //line path/to/file:linenumber and //go:noescape
Reminds me of typescript ///
Re: Go Lang: Comments Are Not Directives
#116Earlier quoted context omitted.
Now argue against yourself and prove you understand why you hit resistance.
if you can agree that i got arguments that convince - i do you the favor. :)
Re: Go Lang: Comments Are Not Directives
#117Earlier quoted context omitted.
Go has the best and most consistent std library I have seen.
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…
My biggest disappointments early on was not even having a Max/Min function for ints.
Re: Go Lang: Comments Are Not Directives
#118At last! I'm not insane! I raised this on the golang dev forums and got nowhere: https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOz... The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.
If I had a huge amount invested in Go I would consider forking it - it is one thing to have a benevolent dictator, but if he doesn't at least listen then there is no point at all.
Re: Go Lang: Comments Are Not Directives
#119If you're feeling paranoid and don't have time to look up the set of magical incantations, maybe you should write your actual comments like this: // COMMENT we have to check that [...] :)
Code should not be magical. Magic is bad engeneering. Magic involving a whitespace is madness.
Re: Go Lang: Comments Are Not Directives
#120Earlier quoted context omitted.
> The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here. That's a rather disingenuous summary given that literally the very first response is Brad Fitzpatrick from the Go team agreeing with you, acknowledging that it's unfortunate, and admitting that it can't feasibly be changed yet due to the compatibility guarantees. And then shortly a…
I doubt that there will ever be a Go 2. EDIT: For the downvoters, quoting Rob Pike in one of his presentations, "Go's design is done".
Regardless, issues are still filed under the tag of `go2`, even by Rob Pike. There's no reason to believe that go2 won't eventually happen.