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

101–110 of 131 posts

Re: Go 1.9 is released

#101

Post by stouset »

randomdata wrote: post #95
fauigerzigerk wrote: post #68

Earlier quoted context omitted.

Can you point me to a quote where Go authors have encouraged people to fork a third party library in order to insert better error handling code? I don't want to insult anyone, but this seems like an utterly insane software engineering practice to me. It means you can't just update to the next version of that library any longer. You're taking it upon yourself to review and patch every single new version of that librar…

See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.

GP is right: this is insane.

Not only are people here suggesting that you fork your dependencies to add stack traces to errors, which is a problem no other modern language seems to have, but it's also going to be a security disaster when some common package is found to have a vulnerability and ten percent of projects ever bother to update it.

I feel like I've entered some sort of bizarro world where everyone has forgotten that programming doesn't have to suck and pretends that none of this is a problem.

Re: Go 1.9 is released

#102

Post by fauigerzigerk »

randomdata wrote: post #95
fauigerzigerk wrote: post #68

Earlier quoted context omitted.

Can you point me to a quote where Go authors have encouraged people to fork a third party library in order to insert better error handling code? I don't want to insult anyone, but this seems like an utterly insane software engineering practice to me. It means you can't just update to the next version of that library any longer. You're taking it upon yourself to review and patch every single new version of that librar…

See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.

I know the debate. It's a debate about versioning, not about maintaining your own fork in order to insert your own error handling philosophy into third party libraries.

Re: Go 1.9 is released

#103

Post by stouset »

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's fine if you think exceptions are bad, but throwing out the ability to easily determine where an error occurred (and might I add, from having seen go code in practice, having humans just become meat-based manual exception-handlers bubbling errors up to the top) is throwing the baby and the bathtub and the entire bathroom out with the bath water.

Re: Go 1.9 is released

#104

Post by cat199 »

hueving wrote: post #67
amenghra wrote: post #29

Earlier quoted context omitted.

Unless you perform a proper statistical analysis it's unfair to draw a conclusion from a single run. Furthermore, when I see a second run that's faster than the first one, I immediately wonder if it's the cache being cold for the first run and warm for the second. While I have your attention, https://zedshaw.com/archive/programmers-need-to-learn-statis... is worth reading.

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

... maybe it's meant to be a bit ironic/salty/sarcastic/venting?

Re: Go 1.9 is released

#105

Post by randomdata »

fauigerzigerk wrote: post #102
randomdata wrote: post #95

Earlier quoted context omitted.

See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.

I know the debate. It's a debate about versioning, not about maintaining your own fork in order to insert your own error handling philosophy into third party libraries.

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 been quite clear that Go is built for the problems that Google has. If your problems are different, it may not be the right tool for the job. A hammer doesn't have to be able to cut wood. There is no harm in choosing a saw instead.

Re: Go 1.9 is released

#106

Post by 4ad »

pjmlp wrote: post #84
arghwhat wrote: post #73

Earlier quoted context omitted.

Well, Go code is statically linked, but the runtime may try to dynamically load libc for DNS resolving. Use of cgo of course drastically change everything.

By default, nowadays the toolchain also supports generating dynamic libraries.

And by default, this feature is not used.

Re: Go 1.9 is released

#107

Post by pjmlp »

4ad wrote: post #106
pjmlp wrote: post #84

Earlier quoted context omitted.

By default, nowadays the toolchain also supports generating dynamic libraries.

And by default, this feature is not used.

So what, it doesn't make this "Go code is statically linked" into a fact, given that it depends on compiler flags.

Now if it said "Go code is usually/by default statically linked", then yes.

Re: Go 1.9 is released

#108

Post by jhgb »

stewbrew wrote: post #83
riobard wrote: post #70

I'm wondering if we could abuse type alias to fake generics somehow? E.g. // file tree.go type T = YourConcreteType type TreeNode struct { Value T } // rest of tree implementation Then you can just copy the file and replace YourConcreteType at the top and voila! Seems simpler to use than the unicode hack here https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

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 Go?) could have parameters that you'd have to supply when importing it. The things you could obviously supply would be at least constants, functions and types. (One might look at functions as types of computational processes, though, and at function signatures/interfaces as their respective type classes. This perspective could subsume functions as types, and perhaps integers as nullary functions returning an integer.) The question is how to reasonably do the import strings. Good thing about Go is that you already have provisions in the language in the sense that the string can be technically arbitrary. A subset of the reflection interface could additionally be evaluated at compile time to provide for ad-hoc specializations of generic code by writing straightforward code that would be easily eliminated/specialized in a module instantiation (like loops over struct fields etc.)

Re: Go 1.9 is released

#109

Post by PopsiclePete »

stouset wrote: post #101
randomdata wrote: post #95

Earlier quoted context omitted.

See: Any discussion related to go get and its design motivations. Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.

GP is right: this is insane . Not only are people here suggesting that you fork your dependencies to add stack traces to errors , which is a problem no other modern language seems to have , but it's also going to be a security disaster when some common package is found to have a vulnerability and ten percent of projects ever bother to update it. I feel like I've entered some sort of bizarro world where everyone has f…

I love programming in Go but the thought of forking and maintaining every single library I might use in one of my projects makes me also feel we've entered a new, bizarre, and terrifying world. This is literally one step away from "write your own OS and compiler, it's the only way to be sure you get the exact behavior you want".

Re: Go 1.9 is released

#110

Post by fauigerzigerk »

randomdata wrote: post #105
fauigerzigerk wrote: post #102

Earlier quoted context omitted.

I know the debate. It's a debate about versioning, not about maintaining your own fork in order to insert your own error handling philosophy into third party libraries.

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 of a third party library for that specific purpose is what I'm calling insane, and I don't think the Go authors have ever suggested such a thing.

Post reply on HN