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

Go 1.9 is released

blog.golang.org

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Go 1.9 is released

#121

Post by fauigerzigerk »

randomdata wrote: post #120
fauigerzigerk wrote: post #119

Earlier quoted context omitted.

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

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

Not in Go. I have found them extremely useful as a diagnostic tool in languages that have ubiquitous stack traces.

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

As I said, the problem may not even originate in that particular third party library. The error may just be passing through, coming from my own code or from a different library altogether.

>How so? The simplest form of a fork is one that is an exact copy of the original.

Vendoring is not primarily about forking and then changing the code. The main purpose of vendoring is freezing dependencies.

Re: Go 1.9 is released

#122

Post by randomdata »

fauigerzigerk wrote: post #121
randomdata wrote: post #120

Earlier quoted context omitted.

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

>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? Not in Go. I have found them extremely useful as a diagnostic tool in languages that have ubiquitous stack traces. >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? As I said, the probl…

> The error may just be passing through, coming from my own code or from a different library altogether.

Then you will have a stack trace to work with. Again, this discussion would be more meaningful if you provided some real world examples. Hypothetical situations that will never happen in the real world are kind of pointless. You don't have to invent reasons to justify not using Go, if that is your intent. Frankly, I couldn't care less what tools you use, and it seems like it is justifiably not the right tool for your problems to begin with.

> Vendoring is not primarily about forking and then changing the code. The main purpose of vendoring is freezing dependencies.

But you are quite literally maintaining a fork. In 99% of the cases there will be no need to modify the code, be it in vendor or in another repository. Freezing the dependency has always been the primary goal of both approaches. The only difference vendor introduced is that the code resides under the vendor tree of each individual application, instead of in a global namespace that allows you to share your pinned version with all of your applications. That's it.

Re: Go 1.9 is released

#123

Post by fauigerzigerk »

randomdata wrote: post #122
fauigerzigerk wrote: post #121

Earlier quoted context omitted.

>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? Not in Go. I have found them extremely useful as a diagnostic tool in languages that have ubiquitous stack traces. >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? As I said, the probl…

> The error may just be passing through, coming from my own code or from a different library altogether. Then you will have a stack trace to work with. Again, this discussion would be more meaningful if you provided some real world examples. Hypothetical situations that will never happen in the real world are kind of pointless. You don't have to invent reasons to justify not using Go, if that is your intent. Frankly,…

>Then you will have a stack trace to work with

Only if a stack trace was added in the original location and then passed on at each intermediate step. As stack traces are not automatically created in Go, nor customarily passed on, there is usually no stack trace available.

>Again, this discussion would be more meaningful if you provided some real world examples. Hypothetical situations that will never happen in the real world are kind of pointless. You don't have to invent reasons to justify not using Go, if that is your intent.

I have been a real world developer for 25 years, and I have explained to you the sort of real life situations in which I have used stack traces to diagnose errors, either originating in or bubbling up through third party code.

If you want to call me a liar, fine, but otherwise don't call it a hypothetical situation that will never occur if I'm telling you that I have run into countless such situations.

I have been using Go and I have defended it on many occasions. But this sort of obstinate reaction of denial and deflection to the most obvious difficulties caused by any of Go's design decisions is really starting to put me off big time.

>But you are quite literally maintaining a fork. In 99% of the cases there will be no need to modify the code

Inserting error handling code is a modification and keeping it up-to-date with new versions of the library is the problem I'm talking about. I think I have made that very clear before.

Re: Go 1.9 is released

#124

Post by fnord123 »

to3m wrote: post #94
chillydawg wrote: post #88

Earlier quoted context omitted.

You need to first create a clean slate each time for running the experiment: no cache, no FILESYSTEM cache etc. Maybe a tonne of single use docker images? Even then filesystem caches will mess you up a little. Beyond that, you need to run the same build "several" times to see what the variance is. Without getting specific, if the builds are within a couple percent of each other, do "a few" and take the mean. If they'…

If the measurements are all over the place, why not take the fastest? The average is no good, because it'll be influenced by the times it wasn't running as fast as possible. I don't myself lose much sleep over worrying about the times it runs faster than possible.

I agree with this sentiment. Any time worse than the fastest is due to noise in the system (schedulers etc). So the fastest is the lowest noise run.

Of course, as I said in another comment it depends what you want to do with the measurement. If you plan to edit how long a run will take on an existing system, then you need to accept the noise and use the mean (or median).

Re: Go 1.9 is released

#125

Post by 9t3h4r3o5w1a4w2 »

jimjimjim wrote: post #85
stouset wrote: post #47

Earlier quoted context omitted.

Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136

it infuriates me when third-party stuff in other languages throws exceptions and you end up needing to check everything anyway. exceptions are a curse.

> it infuriates me when third-party stuff in other languages throws exceptions and you end up needing to check everything anyway. exceptions are a curse.

Anything can panic in Go. Go gives absolutely no guarantee something cannot panic. Errors as values are just a convention. So exceptions are a curse but Go has an inferior exception system, panics, but they are still exceptions.

The solution is checked exceptions.

Re: Go 1.9 is released

#126

Post by 9t3h4r3o5w1a4w2 »

eloff wrote: post #112
cpuguy83 wrote: post #34

Earlier quoted context omitted.

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

The problem is that Go errors are just a convention, they are not a feature of Go. It's just an interface, it could have been called FOO it wouldn't have made a difference. Go has exceptions, they are called "panic" by they are inferior to Java in the way they are handled.

Re: Go 1.9 is released

#127

Post by imaginenore »

vanderZwan wrote: post #8
alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

> each goroutine essentially owns some subset of the keys in the map With those constraints, why not create a small map for each goroutine at that point, and merge the maps afterwards?

Then you have to merge them on every read (after any modification).

Re: Go 1.9 is released

#128

Post by eloff »

9t3h4r3o5w1a4w2 wrote: post #126
eloff wrote: post #112

Earlier quoted context omitted.

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

The problem is that Go errors are just a convention, they are not a feature of Go. It's just an interface, it could have been called FOO it wouldn't have made a difference. Go has exceptions, they are called "panic" by they are inferior to Java in the way they are handled.

I know they're just a convention, but that was a mistake. It should have had more first-class language support so that they have stacktraces at least.

I'm seriously beginning to think that even with the limitations, panic is a better error handling mechanism for all exceptional error cases. At least it has stacktraces and doesn't clutter the code with error boilerplate. I don't think I'd be able to convince anyone of that on a real project though, I'd have to try it on a personal project.

Re: Go 1.9 is released

#129

Post by jhgb »

stewbrew wrote: post #117
jhgb wrote: post #116

Earlier quoted context omitted.

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

You could, but the strings are not the language proper. There's, e.g., no relational expressions in your import strings (yet!), so there's no ambiguity in parsing it. I'd actually use parentheses anyway, since type parameters are still parameters (this could give the parameter list a "Pythonic" syntax which has been shown to work well already).

Re: Go 1.9 is released

#130

Post by stewbrew »

jhgb wrote: post #129
stewbrew wrote: post #117

Earlier quoted context omitted.

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

You could, but the strings are not the language proper. There's, e.g., no relational expressions in your import strings (yet!), so there's no ambiguity in parsing it. I'd actually use parentheses anyway, since type parameters are still parameters (this could give the parameter list a "Pythonic" syntax which has been shown to work well already).

I don't fully understand your comment ("no relational expressions in your import strings") but parentheses are valid characters in filenames (thus URLs). I don't think Python is the best reference here.
Post reply on HN