Go Lang: Comments Are Not Directives • Hacker News Board

Re: Go Lang: Comments Are Not Directives

#141

Post by masklinn » Mon, May 11, 2015, 3:55 PM UTC

aikah wrote: post #133

whateveracct wrote: post #124

Earlier quoted context omitted.

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

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

Which makes complete sense given it's webscale enough for nodejs.

Re: Go Lang: Comments Are Not Directives

#142

Post by 0xdeadbeefbabe » Mon, May 11, 2015, 3:58 PM UTC

Merkur wrote: post #136

fixxer wrote: post #116

Earlier quoted context omitted.

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

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

I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.

Re: Go Lang: Comments Are Not Directives

#143

Post by fixxer » Mon, May 11, 2015, 3:58 PM UTC

Merkur wrote: post #136

fixxer wrote: post #116

Earlier quoted context omitted.

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

1, 2, and 4 are pretty strong arguments.

I've written a handful of go generate utilities to do everything from CRUD boilerplate to produce Python clients. Generally, I have found the current approach simple enough and don't have any motivation to change. I would like to see more definition in terms of best practices as defined by the core authors (perhaps release a few more of those internal tools). They have done a little to try to coax the community into their way of thinking, but I think we need more. Coming from C/C++, your motives aren't unreasonable, but I also fear the innovation might encourage sprawl well beyond the original concept definition. That restraint is pretty common in the history of the language and a way of thinking that I like.

As with so many that desire generics, maybe the solution is simpler: Go might not be the right language for you.

Re: Go Lang: Comments Are Not Directives

#144

Post by zak_mc_kracken » Mon, May 11, 2015, 4:09 PM UTC

threeseed wrote: post #20

dward wrote: post #13

Earlier quoted context omitted.

It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?

Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Saying "it's open source so you can just add feature X or change feature B" only works if you are part of some core team or are respected via other means. Github is littered with projects that have lots of Pull Requests…

> Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork.

Or d) that I have any time in my life to undertake such work.

Re: Go Lang: Comments Are Not Directives

#145

Post by zak_mc_kracken » Mon, May 11, 2015, 4:10 PM UTC

dward wrote: post #13

zak_mc_kracken wrote: post #12

Earlier quoted context omitted.

> Our conservatism should be a testament to how much we care about quality. Offering code generation as a solution to code reuse is not caring about quality, it's laziness.

It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?

You have a very naïve view of the world and an unrealistic conception of what open source is.

Re: Go Lang: Comments Are Not Directives

#146

Post by peterwaller » Mon, May 11, 2015, 4:14 PM UTC

lclarkmichalek wrote: post #123

chimeracoder wrote: post #98

Earlier quoted context omitted.

> 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

> Do you have any examples of the standard library using panics to signal handle-able errors

Are those 79 handle-able errors, or are they programming mistakes?

Re: Go Lang: Comments Are Not Directives

#147

Post by lloeki » Mon, May 11, 2015, 4:19 PM UTC

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…

> 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"

Have a package for each type, so you can import the one you need (e.g something like math/uint64), and eventually can rename it on import as is best fitting. Also, make it an external package in golang.org/x (like godoc&al) so as not to be bound to promises regarding language stability while at the same time offering a centralized implementation.

> 4) Just use the most "general" number type and write min/max for that

This is precisely what strconv.ParseInt does[0], with some obscure, runtime evaluated integer magic values of all things (instead of readable, type-safe, compile-time asserted enums).

[0]: http://golang.org/pkg/strconv/#ParseInt

Re: Go Lang: Comments Are Not Directives

#148

Post by Merkur » Mon, May 11, 2015, 4:26 PM UTC

0xdeadbeefbabe wrote: post #142

Merkur wrote: post #136

Earlier quoted context omitted.

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

> 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. I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.

well, i see - my statement was flawed. :)

Re: Go Lang: Comments Are Not Directives

#149

Post by krylon » Mon, May 11, 2015, 4:27 PM UTC

coldtea wrote: post #65

andrewchambers wrote: post #58

Earlier quoted context omitted.

Go has the best and most consistent std library I have seen.

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.

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.

Re: Go Lang: Comments Are Not Directives

#150

Post by 0xdeadbeefbabe » Mon, May 11, 2015, 4:29 PM UTC

Merkur wrote: post #148

0xdeadbeefbabe wrote: post #142

Earlier quoted context omitted.

> 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. I put up with whatever semantics are necessary to get the CPU to do the right thing, but I'm more excited about CPUs than semantics.

well, i see - my statement was flawed. :)

You stand corrected then :) (or not). Does this comment thing make you want to flee to the safety of Java? I would put up with Java semantics if I were fulfilling a community service sentence.