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

131–140 of 222 posts

Re: Go Lang: Comments Are Not Directives

#131

Post by TheDong »

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…

No, the advantage of having an interface is everything can return an error I can typeswitch on. Unfortunately, you can't (in a backwards compatible way) change io.EOF or any of the other 'constant' errors because there's so much code doing 'if err != io.EOF' which now breaks. In addition, it's backwards incompatible due to anyone doing 'reflect.TypeOf' which I guess you could argue is fine to break.

Speaking of reflection, there's a metric TON of runtime panics in the reflect package. Hell, I'm not sure there's a method in there that can't panic.

No doubt, however, you'll say that's cheating and the expected behavior of that package, so how about NewTimer (playground https://play.golang.org/p/jDKniK3aqa ). It does not give me an opportunity to recover from bad input by passing an error out, it just panics. It is also not documented that it panics afaik and other functions in time (time.Sleep) take negative durations and handle them just fine. This is definitely inconsistent with other std library functions that can take bad input and return errors.

I also think it's disingenuous to say "Keep in mind errors are from C and at least they're better than C"... the comment I'm responding to is a comment regarding go std library being one of the most consistent (implicit compared to ANY LANGUAGE) so I may bring in anything I wish, and sure Go's errors are a step up from C, but they're awful compared to other languages. They're basically passing around strings with no builtin way to create a trace of errors to return up the stack to maybe be printed, no default way to create an optional type with an error value, and no consistent way to determine which of N errors it was that was returned from a function without using a regexp 90% of the time because that damned fmt.Errorf / errors.New... And yes, using a Regexp in your error handling IS a problem.

> defined on float64, which can be annoying, but is far better than any alternative

Funnily enough, the 'rand' library implements everything by just having multiple functions and postfixing them with types (rand.Uint32, rand.Int, rand.Float32) and strconv does something vaguely similar.

Whether one or the other is better, that's another inconsistency in the stdlibrary; do you have many functions per type or only one function for one type? I have no clue how Go could have abused you such that you are able to conceive of not having a builtin int64 compatible 'min' function as a good thing.

Actually, perhaps your post is simply a plea for help as Go has tied you up and holds a gun to your head, in which case I suppose we should mount a rescue mission forthwith! Just let me write a quick timer to keep track of our progress... -1 you s.. err panic

Re: Go Lang: Comments Are Not Directives

#132

Post by jbooth »

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…

Yeah, but with C's old-school int values for errors, you can always make an equality comparison. The error interface in Go doesn't specify equality, so you can do "if err == io.EOF" in some cases and you're up a creek in other cases. Sure you can do if err.Error() == "String I'm expecting", but as the parent said, fmt.Errorf can easily make that impossible.

Re: Go Lang: Comments Are Not Directives

#133

Post by aikah »

whateveracct wrote: post #124
vowelless wrote: post #117

Earlier quoted context omitted.

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

yet the "go way" makes computing really tough :

        x := 1
	y := 2.0
	z := x + y
Error : invalid operation: x + y (mismatched types int and float64)

So much that devs end up using float64 everywhere ...

Re: Go Lang: Comments Are Not Directives

#134

Post by TheDong »

whateveracct wrote: post #124
vowelless wrote: post #117

Earlier quoted context omitted.

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

Note that option 3 is the approach the 'rand' package took (see https://golang.org/pkg/math/rand/#Float32 ).

I guess not so much definitely not the "Go way", just not the go way for the math library.

Re: Go Lang: Comments Are Not Directives

#136

Post by Merkur »

fixxer wrote: post #116
Merkur wrote: post #114

Earlier quoted context omitted.

if you can agree that i got arguments that convince - i do you the favor. :)

I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.

okay, i'll jump :)

1) First of all change is not nessesary - because within the current "comment directive convention" the tooling needs can be achived. Even more so - they can be achived without changing the current spec of the language.

2) As I learned during this discussion there are "comment directive convention" that are older as go 1.4. I could imaging they play a role deep inside the go tooling. i.e. I could imaging that the cgo stuff has some deep roots. It would some work to change all occurences - that is glass clear - because even now there are legacy directives // +build //link that are not updated to the "new convention" //go: foo

3) I dont know about the internal mechanism that the go team needs to observce to change the spec of a language, that is perhaps in wide productive use within the google. But i can imagin there is procedure. Changing the spec meight just not be possible before Go 2.0 because of policy.

4) It meight not be desired to introduce something that smells like a macro language into the code. There meight be some animosity againt it - give the clean code philosopy that Go aimes for.

No, i dont realy believe that. I am Sorry to have accused! On contrary: The yacc tool gives great power to expand the language. But yacc is a heavy lifting tool and not something like a macro every one could use. Its also not part of the spec, just given as magic comment - no prommise made.

5) One counter argument that is invalid: I am pretty sure the go team cares about semantic. :-) All programmers do breath semantic. Of course there are different tastes.

6) You basicly cant prevent magic... in comments or otherwise its the reason its called magic.

7) those commented directives can stay in all levels of the build process - without adaptions of the spec. This means tools have the potential to hook on source, on ast, etc.

Re: Go Lang: Comments Are Not Directives

#137

Post by fixermark »

tomjen3 wrote: post #121
zaphar wrote: post #103

Earlier quoted context omitted.

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.

That's the point---rather than create a tooling ecosystem that forces a particular IDE choice upon developers, Go is aiming for a set of minimally-sufficiently-powerful tools that IDEs can hook into.

Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. I know Eclipse, but I avoid using it in all contexts where I can---it's slow, its project model borders on filesystem hostility (and still sometimes requires a "throw up your hands and delete a bunch of dotfiles" solution to fixing breakages in it), and even after years of refactoring and improvements it will still go "out to lunch" on garbage collection and force a pause in my process that most IDEs will not. Being forced to use Eclipse would be a hindrance for me in picking up Go (and I think a similar argument can be made for being forced to use (X|X element of IDEs) across all developers).

Re: Go Lang: Comments Are Not Directives

#138

Post by zaphar »

tomjen3 wrote: post #121
zaphar wrote: post #103

Earlier quoted context omitted.

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.

It isn't a big deal for you maybe. But I work in many different languages in a day. Switching IDE's/editors is a context switch I shouldn't have to make. Go is one small step in that direction.

You don't see an official recommendation because it's not necessary. Pretty much anything you use is going to have comparable functionality due to the work of the go team. Which is how I know that the Go team cares about tooling.

Re: Go Lang: Comments Are Not Directives

#139

Post by ticviking »

fixxer wrote: post #96
_pmf_ wrote: post #49

Earlier quoted context omitted.

Go is typical "hurr durr, Java an C# are obsolete" write-only code by people who only ever work on ephemeral greenfield projects with a lifetime of 3 months and therefore can tell exactly what software development is all about.

Such an inflammatory troll... Do you you even know who is involved in the Go project?

I think that's actually the point.

At their level of prestige they can kinda work on whatever they like instead of having to live through and slog through the kind of crap code that accumulates on a project where you have people far below their level working along side people only slightly below their level.

If you only ever work with fellow top performers, you never need the language and tool features that make it less to work with idiots.

And then they do things like this comment stuff.

Re: Go Lang: Comments Are Not Directives

#140

Post by pfortuny »

EugeneOZ wrote: post #29
marcus_holmes wrote: post #17

At 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.

I remember I reacted hysterically in Twitter about this change, somebody gave me link to your post and after reading first response of Brad Fitzpatrick I realized there's no chance for arguing or discussion - all decisions are final and community feedback isn't required.

This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link).

http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...

Post reply on HN