Go 1.9 is released • Hacker News Board

Re: Go 1.9 is released

#111

Post by stcredzero » Fri, Aug 25, 2017, 4:45 PM UTC

baq wrote: post #77

hueving wrote: post #67

Earlier quoted context omitted.

"Programmers Need To Learn Statistics Or I Will Kill Them All"... What an insufferable asshat. PSA: There is no reason to behave like this and this is an incredible way to alienate a bunch of people. You either offend people directly with the murder implication or they don't take you seriously because you sound like you're throwing such an extended temper tantrum that you managed to write it all in a blog.

or you can stop being offended by words put out on the internet by strangers... which is what i always recommended to basically everyone.

It's like Doonesbury, but it came from the 80's: http://imgur.com/82QXoAj

Re: Go 1.9 is released

#112

Post by eloff » Fri, Aug 25, 2017, 5:17 PM UTC

cpuguy83 wrote: post #34

throw4625 wrote: post #33

Earlier quoted context omitted.

This is the biggest problem with Go errors and one of my biggest gripes with the language. Exceptions have stacktraces that give you context about where the error originated. Go errors don't have this and it costs me a lot of time debugging things. https://godoc.org/github.com/pkg/errors helps, but it's still more of a pain than it should be.

Errors can be anything. It's just an interface.

Which to be clear, is a language design mistake. Go would be a much more productive and friendly language if errors would just have stack traces on them when they're created. There's no reason to have the poor developer adding dozens of debug prints all over his (and sometimes third-party) code manually into every place that could have returned the error just to try and discern where it comes from. Or grepping for strings in the error message, or throwing darts at printouts of the source. That's just a massive step backwards from what we've had since the 80s and 90s. I know Go prides itself on being simple, but really the errors are too simple and we're all worse off because of it.

Re: Go 1.9 is released

#113

Post by sebcat » Fri, Aug 25, 2017, 5:54 PM UTC

ptman wrote: post #79

sebcat wrote: post #66

Earlier quoted context omitted.

To expand on this: $ cat foo.go package main import ( "fmt" ) func main() { fmt.Println("Hello") } $ go build foo.go $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped compared to: $ cat bar.go package main import ( "os/user" "fmt" ) func main() { u, err := user.Current() fmt.Println(u, err) } $ go build bar.go $ file bar bar: ELF 64-bit LSB executable, x86-64, versio…

You can usually build fully static by doing CGO_ENABLED=0 go build even when using os/user or net/

At a computer with go1.4.2 freebsd/amd64 ATM (earlier was go1.8.1 linux/amd64 IIRC) and the above os/user example results in a dynamically linked ELF when built with CGO_ENABLED set to 0.

Re: Go 1.9 is released

#114

Post by logicallee » Fri, Aug 25, 2017, 6:15 PM UTC

dgellow wrote: post #52

logicallee wrote: post #42

Earlier quoted context omitted.

also necessary for reads? Also, do you have any good references to proper best practices around concurrent and parallel programming? (in Go.) Like just basic things. Code I can copy and paste without it having obscure race conditions because that use of mutex is absolutely correct, and something that lets me understand the limitations. I feel like it is very easy to do things "wrong" or not notice some edge cases. In…

I would suggest you to read the book "Concurrency in Go", by Katherine Cox-Budai, 2017: http://shop.oreilly.com/product/0636920046189.do

Thank you for the recommendation!

Re: Go 1.9 is released

#115

Post by stewbrew » Fri, Aug 25, 2017, 7:03 PM UTC

jhgb wrote: post #108

stewbrew wrote: post #83

Earlier quoted context omitted.

Now make that a compile time thing that happens on imports and that doesn't generate temporary source files and whoop you have modules with generics. Oops, I forgot that there are some unsolvable obstacles to be resolved.

I have been wondering for quite some time how one could implement that. That is, not in the sense of how to code that, but rather how few changes one would have to make to the language to get as many effects as possible in the direction of genericity. There is some inspiration in Lua, Scheme48 and some dialects of ML (functors, I believe?) in the form of "higher-order modules", where the module (would be package in G…

Are you saying, it wouldn't be too difficult to implement this in the go compiler but the crucial question is (just) the syntax of the import string?

Re: Go 1.9 is released

#116

Post by jhgb » Fri, Aug 25, 2017, 7:10 PM UTC

stewbrew wrote: post #115

jhgb wrote: post #108

Earlier quoted context omitted.

I have been wondering for quite some time how one could implement that. That is, not in the sense of how to code that, but rather how few changes one would have to make to the language to get as many effects as possible in the direction of genericity. There is some inspiration in Lua, Scheme48 and some dialects of ML (functors, I believe?) in the form of "higher-order modules", where the module (would be package in G…

Are you saying, it wouldn't be too difficult to implement this in the go compiler but the crucial question is (just) the syntax of the import string?

The interface to the feature is perhaps more important than the complexity of the implementation because it will affect many more people - only a few programmers will work on the compiler but tens of thousands of programmers will be writing code using it. I make no claims as to how complex this would be to implement, but it probably wouldn't stand out. The interesting thing is that this shouldn't necessitate any changes in the language of generic modules (no s and such). It merely parameterizes some types and constants in a module. As such, after a certain phase in compilation, the process is the same as for a non-generic module so perhaps it's a low-complexity change in the implementation, too (not just in the language spec).

Re: Go 1.9 is released

#117

Post by stewbrew » Fri, Aug 25, 2017, 7:43 PM UTC

jhgb wrote: post #116

stewbrew wrote: post #115

Earlier quoted context omitted.

Are you saying, it wouldn't be too difficult to implement this in the go compiler but the crucial question is (just) the syntax of the import string?

The interface to the feature is perhaps more important than the complexity of the implementation because it will affect many more people - only a few programmers will work on the compiler but tens of thousands of programmers will be writing code using it. I make no claims as to how complex this would be to implement, but it probably wouldn't stand out. The interesting thing is that this shouldn't necessitate any chan…

> no s and such

Funny. The first thing that came to mind was:

    import (
        bar "github.com/name/bar"
        baz "github.com/name/baz"
        foo "github.com/name/foo"
        foo_bar "foo"
    )

Re: Go 1.9 is released

#118

Post by randomdata » Fri, Aug 25, 2017, 9:07 PM UTC

fauigerzigerk wrote: post #110

randomdata wrote: post #105

Earlier quoted context omitted.

They have always maintained that Google does modify the packages and maintains any necessary merging and maintenance of the package. It is not just about versioning. This is why they maintain their own repository of third-party libraries in the first place, and why the tooling is designed to support their forking methodology. Again, this may be a poor operational choice for those outside of Google, but they have also…

You seem to be forgetting what your original claim was. It was not that Google maintains forks of some third party libraries for some reason or other. That wouldn't be surprising at all. You claimed that >the Go authors have always strongly promoted that you fork and maintain your dependencies And you said that in response to a need for stack traces and specific error types. Burdening yourself with maintaining a fork…

> You claimed that

Which is true. Their stance on maintaining your own forks is pervasive through all the tooling and their explanations of how the tools are designed to be used. There has been emphasis that if you want the tools to work well, you need to fork and maintain your dependencies.

You are, of course, free to do whatever you want. You can even feely let a random third-party maintain your dependencies, and hope they don't break anything, if you so wish. Many do exactly that. Despite what some people like to claim, the Go authors are not benevolent dictators that completely rule how you must develop software. They've simply published tools that worked for them, and granted a license that allows you to use and modify them in any way you see fit.

> And you said that in response to a need for stack traces and specific error types.

Technically the discussion was about how stack traces aid in debugging. It is a fair point. They most certainly do. And if you are interested in the stack within a third-party library, that suggests that you intend to debug said library.

If you are debugging a third-party package, you have already decided to fork it by virtue of what debugging requires. Adding stack traces to ease debugging of the package, if you so desire, is not a great undertaking on what is already a fork you have decided to maintain. You, of course, can submit your changes to the upstream maintainer, but in the meantime you are still holding on to a fork that you have decided to maintain. There is no guarantee that anyone else will want your changes. There is really no escaping that fact. It is not insane. It is simply pragmatic.

If you are only ever going to maintain your own code, the stack trace up to your call out to the buggy third-party package will still be available, if you choose to provide it, allowing you to work around or otherwise deal with the buggy package in your code.

Re: Go 1.9 is released

#119

Post by fauigerzigerk » Fri, Aug 25, 2017, 10:08 PM UTC

randomdata wrote: post #118

fauigerzigerk wrote: post #110

Earlier quoted context omitted.

You seem to be forgetting what your original claim was. It was not that Google maintains forks of some third party libraries for some reason or other. That wouldn't be surprising at all. You claimed that >the Go authors have always strongly promoted that you fork and maintain your dependencies And you said that in response to a need for stack traces and specific error types. Burdening yourself with maintaining a fork…

> You claimed that Which is true. Their stance on maintaining your own forks is pervasive through all the tooling and their explanations of how the tools are designed to be used. There has been emphasis that if you want the tools to work well, you need to fork and maintain your dependencies. You are, of course, free to do whatever you want. You can even feely let a random third-party maintain your dependencies, and h…

>If you are debugging a third-party package, you have already decided to fork it by virtue of what debugging requires.

I think we disagree on two separate issues that shouldn't be conflated.

The first issue is whether the only purpose of a stack trace coming from a third party library is to actually debug that library. I suggest that this is not the the case.

I may simply want to understand what's going on in there. Maybe I'm passing incorrect data to that library, but the returned error is not specific enough to tell me what I did wrong. Maybe the error is somewhere further down in my own code (e.g. in a callback), in a different library altogether or related to the environment (missing file, broken database connection, ..). Or I may just want to post the stack trace in a support forum to get help.

I have often been looking at stack traces from third party libraries, but I have rarely wanted to debug those libraries.

Our second disagreement is perhaps a more gradual one. You seem to suggest that maintaining a fork is something completely normal or even desirable. I think it is something extremely undesirable - a last resort.

In any case, I do not believe that the Go creators have ever suggested that maintaining a fork is something you should do willy nilly or something that everybody should do all the time. This is different from the use of vendoring for versioning purposes. If the Go creators did in fact promote such a thing, I would strongly disagree with them.

Re: Go 1.9 is released

#120

Post by randomdata » Fri, Aug 25, 2017, 10:24 PM UTC

fauigerzigerk wrote: post #119

randomdata wrote: post #118

Earlier quoted context omitted.

> You claimed that Which is true. Their stance on maintaining your own forks is pervasive through all the tooling and their explanations of how the tools are designed to be used. There has been emphasis that if you want the tools to work well, you need to fork and maintain your dependencies. You are, of course, free to do whatever you want. You can even feely let a random third-party maintain your dependencies, and h…

>If you are debugging a third-party package, you have already decided to fork it by virtue of what debugging requires. I think we disagree on two separate issues that shouldn't be conflated. The first issue is whether the only purpose of a stack trace coming from a third party library is to actually debug that library. I suggest that this is not the the case. I may simply want to understand what's going on in there.…

> I have often been looking at stack traces from third party libraries, but I have rarely wanted to debug them.

If you have found stack traces are already readily available in third-party packages – that you can claim you do it often – what's the issue? Maybe this thread would be better served by real world examples of where the lack of stack traces in Go has actually bitten you?

> Maybe the error is somewhere further down in my own code (e.g. in a callback)

To be fair, the Go authors have also driven home the fact that you need to make your errors meaningful with the full context necessary to determine the path of the error (granted, not necessarily a full-fledged call stack). They have been abundantly clear that you should never simply `return err`. If this is an issue, it is because the code was written poorly.

And if a package is written poorly, and you don't want to fix the issues with it, perhaps you should reconsider using it in the first place?

> This is different from the use of vendoring for versioning purposes.

How so? The simplest form of a fork is one that is an exact copy of the original. If a package is already suitable to your needs, there is no reason to modify it, other than to perhaps merge in updates that the upstream author has made.

You can either keep that fork in a global repository, or you can keep it in vendor. There is no fundamental difference between either of those. At all. Vendor is just a convenience feature to allow the fork to stay in your application's tree.

Of course, if the library is poorly written or doesn't perfectly suit your needs you may have to make modifications to it. But that is true of every library written in every language in existence. It is not insane to do that, just pragmatic.