8 ms·
Griping about Go
- dekken_ 8y ago#notasuspectURL
- rhacker 8y agoI heard it's better now but when I was trying to do grpc I couldn't get this to build: https://github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy https://github.com/improbable-eng/grpc-web/tree/master/go/gr... Basically there was dependency that changed, and it caused it to not build. The maintainer was just pointing fingers at google. I had no idea what to do, but it just scared the crap out of me.
- pcwalton 8y agoWhat's worse, defer's function-scoped nature means that the only way to compile it is to dynamically push closures onto a stack at runtime and then pop them off one-by-one before returning. The compiler may be able to optimize this in specific cases, but in the general case the semantics are extremely dynamic for no real benefit. Designing defer in this way is an especially strange decision for a language that in many ways is architected to make life easy for the compiler writer.
- cremp 8y agoTo add on; recover itself is a nice code-smell. If you're using recover, it's probably time to rewrite the func. I say this because Go forces you (minus just ignoring with _) to error check; so panic's shouldn't happen to start with.
- echlebek 8y agoWell, panic should mostly be happening as a result of nil pointer deref, slice out of bounds, etc. You wouldn't want those types of operations to return error values.
- d0100 8y agoBut for those you can do a manual bounds & pointer check.
- skj 8y agoYour code is allowed to panic if there is a bug. For instance, the caller passed in a nil pointer where there needed to be actual data. Errors are for when the input (specifically the I/O) is wrong, a precondition isn't met, or some other error that doesn't mean there is something fundamentally wrong with your code. If to make the problem go away you need to fix the code, panic is OK.
- cpuguy83 8y agoThe problem is that it doesn't really force you to do error checks... and really most code I've seen doesn't really handle the error either so much as just bubble it up like a mini-exception.
- apta 8y ago> I say this because Go forces you (minus just ignoring with _) to error check; fmt.Println("foo") Where did golang force you to error check? How about (taken from here: (https://www.reddit.com/r/programming/comments/ak305l/goodbye... https://www.reddit.com/r/programming/comments/ak305l/goodbye...): r1, err := fn1() r2, err = fn2() if err != nil { return err }
- agumonkey 8y agoAre they even aware of it ? I mean like ML discussions about it.
- Thaxll 8y agoI don't understand what you're saying but defer cost a few ns so it's very fast and usually not a performance problem. ( ie: don't use it in hot path )
- deathanatos 8y agoIf I am understanding him correctly: If defer were statically scoped, that is, if it were scoped to curly braces, you would "know" at compile time when and if a defer is going to run (relative to that scope). That is, a defer boils down to just "at the end of this scope, run this code" and nothing more, and all the compiler has to do is move that code/function call to the closing curly brace. (Similar to how a C++ compiler knows when to run a destructor for an object.) However, by having them be function scoped, this isn't so anymore; e.g, a defer occurring in an if() statement needs to happen at the end of the function, but only if the if occurs. If you loop over a defer, we need to accumulate those. (And the golang tour even explicitly calls the behavior out.[1]) So, instead of just running the defer at the end of the if / inside the if statically, we need to push the defer onto a runtime stack of yet-to-be-run defers that we'll evaluate at the end of the function. This now has to happen at runtime, not compile time, and makes the function compilation more complex, and requires a stack somewhere to push this stuff onto. From a compiler writer's perspective, I would agree w/ the parent: this seems much more complex, and runs counter to golang's otherwise simple design philosophy. [1]: https://tour.golang.org/flowcontrol/13 https://tour.golang.org/flowcontrol/13
- pcwalton 8y agoIt's not that defer is slow in absolute terms†; it's that it's slower than it needs to be for no good reason. The corresponding C++ feature (RAII) is "free" (as in, it adds no overhead over manually writing the cleanup code), while defer is not. Defer would be easier to use for the programmer, easier for the compiler writer, and faster at runtime if it were block-scoped. †Though the linked list that the compiler has to generate could hit malloc, which costs more than a few nanoseconds.
- cyphar 8y agoI haven't tested this since then, but this wasn't the case in 2014[1]. I haven't noticed these issues since then, but back then it cost hundreds of microseconds -- 8 orders of magnitude more than "a few ns". EDIT: I just re-did the relevant tests on Go 1.11.5. It's significantly better than in 2014 but it still costs between ~20us and ~50us ("only" 4 orders of magnitude more than "a few ns"). goos: linux goarch: amd64 BenchmarkPut-8 50000 27502 ns/op BenchmarkPutDefer-8 30000 46774 ns/op BenchmarkGet-8 50000 29812 ns/op BenchmarkGetDefer-8 20000 89701 ns/op PASS [1]: https://lk4d4.darth.io/posts/defer/ https://lk4d4.darth.io/posts/defer/
- rwj 8y agoA common idiom is the defer, for example, file.Close() only if there wasn't an error when the file was opened. You can also put them in an if statement. This means that the deferred function aren't strictly tied to their scope. Putting the defers on the stack is also part of how the runtime unwinds the stack during a panic.
- pcwalton 8y ago> Putting the defers on the stack is also part of how the runtime unwinds the stack during a panic. All exception ABIs on all major platforms can do this without any overhead in the no-exception case. The compiler embeds static metadata (in a subset of DWARF, on Linux) alongside the function, and the unwinder parses that metadata in order to determine which destructors to invoke.
- favorited 8y agoIs there a reason that go's defer is only function-scoped?
- fortytw2 8y agoAs opposed to... entire program scoped?
- mynegation 8y agoAs opposed to any set of matching curly brackets in C++, i.e. just "scope"-d. Do not know the real reason but my wild guess: for simplicity.
- kazinator 8y agoI'm guessing there are some interesting things you can do when the defer list is scoped to the function. Like perhaps this pattern works: loop i over whatever { defer foo(i) } I.e. a loop's iterations can put things into the defer list, which is then executed when the function exits. Whereas if the defer list were block scoped, then each defer would execute immediately on the termination of its enclosing iteration. Also, there is problem with conditional defers like: if (condition) defer whatever Okay, so that is in the surrounding scope. Now I need to add some piece of logic: if (condition) { defer whatever piece of logic } Now it's scoped to the curly braces and executes immediately after "piece of logic" is done? In terms of performance, the defer list has to be an actual run-time object; the compiler can't always optimize away the existence of the defer list. If defer is block-scoped and used in numerous nested scopes of the same function, where the compiler isn't able to remove it, then you get multiple defer list instantiations in the function's stack frame, which is a kind of bloat. These have to be initialized to the empty state on each entry into a block. At most defer list to initialize on entry into a function is less time and space overhead. A more flexible design would be defer to work with named blocks: foo: { bar: { defer h() foo; defer g() bar; defer f(); } } h() is deferred to the termination of foo (thus using foo's defer list); likewise g() in relation to bar, and the f() defer is function scoped.
- dana321 8y agoI avoid using defer
- sagichmal 8y agoThat seems dumb; `defer` is an excellent and idiomatic tool for many use cases, principally but not exclusively resource cleanup.
- echlebek 8y agoThe other commenter wasn't very kind towards you, but I'd definitely encourage you to use defer to get correct semantics around releasing resources. It's the best tool that the language gives you for that.
- dana321 8y agoSorry, but for me its not a great method of releasing resources. I tend to (for example) open a connection in one function, do something with it in another function, close it in another. I'm not writing traditional go programs, i wrap things in an api.
- echlebek 8y agoSounds like that practice would make resource lifetimes hard to reason about. And without defer, you don't have the opportunity to clean up resources if a goroutine panics.
- kazinator 8y agoThe higher level procedure which uses these three functions could use defer to ensure that the closing function is called.
- dana321 8y agoI would have to re-arrange my call stack so that the read or write functions would be inside the open statement, then it would close it at the end anyway so its kind of pointless for my uses. I try and totally avoid panics and never throw them unless its at some initial parser stage. But this is made me rethink the structure of how some of my tags operate in my interpreter / transpiler.
- cdoxsey 8y agoThe whimsical nature of interfaces is definitely different coming from other languages. An `io.Flusher` might be nice, but it's not really necessary. You can just write: type Interface interface { io.Writer Flush() error } func someFunction(w Interface) error { w.Write(nil) w.Flush() panic("etc...") } Or even drop the type name: func someFunction(w interface { io.Writer Flush() error }) error { w.Write(nil) w.Flush() panic("etc...") } But maybe that looks too weird.
- rbrtl 8y agoThis is something I'm still struggling to grok. The interface idioms feel so different to my Java instincts, like loose fitting clothes after years of skinny jeans.
- skj 8y agoBasically, the interfaces get defined where they're used, not where they're implemented.
- apta 8y agoGolang's interfaces are a half-baked feature, not so different from the rest of the language. What they basically were aiming for is called "structural typing". However, other languages that have that feature have a much better approach, without sacrificing readability, functionality, or discoverability, and ending up causing bugs in the standard library like golang did.
- hombre_fatal 8y agoHere's one of my favorite gotchas in Go: why does this error? https://play.golang.org/p/6LTbtuocu5- https://play.golang.org/p/6LTbtuocu5-
- nemothekid 8y agonil interfaces is one of the strangest things in language, and after learning Rust after using Go for years, I think not having Option types is the real wart in the language. I've never really cared about Generics, but having nullable types is a real mistake to me.
- DaiPlusPlus 8y ago> but having nullable types is a real mistake to me. Nullable types by themselves are fine, the language and the compiler just needs to make handling “is X null?” work the same way as option types do - or better yet: languages were a variable is only in scope if it is not null.
- deleted 8y ago[deleted]
- hombre_fatal 8y agoYeah, nullable types are one thing. Go's null interface is another: https://play.golang.org/p/N_3BiUOkRJo https://play.golang.org/p/N_3BiUOkRJo It's probably the first and last to have this quirk.
- echlebek 8y agoIt errors because the type of `err` is `error`, not *formatError. That's why you are supposed to return the error interface, instead of a concrete type. The value ends up being a non-nil interface value that holds nil. To avoid encountering this issue, return `error`, not something else. https://play.golang.org/p/jZ5Fa24bbUz https://play.golang.org/p/jZ5Fa24bbUz
- 8y ago
- vldo 8y ago> Usually this can be resolved by creating a new function and calling that from the loop. But frequently not. [etc.] For me this is the appeal of the language; I really prefer things confined and manually scoped rather than having things globally scoped which would cause a lot of debate just around that. You often have to think about what you want to expose and where, but that's a good thing in my opinion.
- cpuguy83 8y agofor _, f := range fs { func() { defer f.Close() }() }
- aphextron 8y agoEdit: This place has become a joke. It was nice having pluralistic discussion while it lasted. Goodbye.
- Animats 8y agoAutomatic closeout remains a hard problem. "Defer" has the same problem as RAII - what if the closeout fails? Python's "with" clause, and how it interacts with exceptions, is one of the few constructs that can handle multiple closeout faults correctly. Trying to get rid of exceptions seems to force workarounds that are worse than exceptions. C++ and Java exceptions were botched and gave the concept a bad name. Go's "panic" and "recover" are an exception system, but not a good one. Python comes closer to getting it right. Key concepts for successful exceptions: - A predefined exception hierarchy. Catch something in the tree, and you get everything below it. Python added this in the 2.x era, and it made exceptions usable. (Then they messed it up in the 3.x era, putting too much stuff under "OSerror".) This solves the problem of "Have I caught everything"? - The case where a closeout event raises an exception has to work. This is hard. Attempts to get it right resulted in such horrors as "re-animation" in Microsoft Managed C++. It needs something like the Rust borrow checker model to make sure that object lifetimes are properly enforced on all error paths.
- skybrian 8y agoException hierarchies are hard to get right. Java botched it too, making checked exceptions look bad. I like Go's use of a single error type in most public API's. Combine with checked exceptions and you would have two kinds of functions: those that can fail and those that can't. It keeps the "what color is your function" problem to a minimum.
- pjmlp 8y agoJava checked exceptions are based on CLU, Modula-3 and C++ exceptions clauses. Naturally one just blames the one that actually got famous using them.
- paulddraper 8y agoJava 7+ has everything you describe for Python 2.5+.
- likpok 8y agoThe problem in Java is checked exceptions, which can be frustrating -- either leading to try {} catch{ /* ignored */} or bubbling up the exception (probably preferable, but more work). IDE support makes this nicer, and Java's tooling is certainly first-rate in my experience.
- barrystaes 8y agoThe article is on a suspect domain: https://https.www.google.com.tedunangst.com/flak/post/griping-about-go Is there any legit reason to have https.www.google.com in there?
- rbrtl 8y agoMy AV blocked the website for Phishing. Guessing it's got a bad reputation, or as you say, it's just "suspect".
- draw_down 8y agoI think that’s what we call “a joke”.
- comex 8y agoFYI, you appear to have been shadowbanned for a while.
- mlvljr 8y agoMust be one of those trolls
- eadmund 8y agoLooking at his history, it looks like it happened ca. November 2017: https://news.ycombinator.com/threads?id=draw_down&next=15676609 https://news.ycombinator.com/threads?id=draw_down&next=15676... Looking back for a few pages before that, I don't see any moderators warning him. He does seem to post an awful lot of single-sentence replies, so maybe it was automated? I have my own concerns about the lack of transparency around moderation & banning.
- nicoburns 8y agoHow come we can see his posts if he's been shadow banned?
- comex 8y ago
- nvarsj 8y agoDefer also encourages the unsafe behavior of not checking error results. You can't propagate errors from it. About the best you can do is wrap whatever function you were deferring in another function, and then panic if there is an error.
- shabbyrobe 8y agoYou can actually propagate errors from it. It's not pretty but it works: func Pants() (rerr error) { defer func() { if err := doStuff(); err != nil && rerr == nil { rerr = err } }() // ... return nil } I use this function all the time with `io.Closer` implementations: func DeferClose(err *error, closer io.Closer) { cerr := closer.Close() if *err == nil && cerr != nil { *err = cerr } } func Pants() (rerr error) { f, _ := os.Open(...) defer errtools.DeferClose(&rerr, f) // ... return nil }
- LandR 8y ago> I mostly like go, but after working with it a bit more I realize there are a few jibs of which the cut I do not like. What is this supposed to parse to?
- logicchains 8y agoI believe the author meant "a few jibs the cut of which I do not like".
- LandR 8y ago> https://www.merriam-webster.com/dictionary/jib https://www.merriam-webster.com/dictionary/jib Looking up jib on a dictionary, none of the definitions sound like they make sense in this context at all. Oh well.
- gmac 8y agohttps://www.urbandictionary.com/define.php?term=I%20like%20the%20cut%20of%20your%20Jib https://www.urbandictionary.com/define.php?term=I%20like%20t...
- haihaibye 8y ago"Like the cut of their jib" means you like it. They tried to invert it in a clever way, badly.
- AnIdiotOnTheNet 8y agoEmphasis on "badly". I hope they don't write code this way.
- LordHeini 8y agoI think go has some serious other problems. Like the billion dollar mistake. Why is this repeated in any new language? It is just plain awful and stupid. This is easily my biggest gripe with the language (apart from missing generics). Go combines that greatly with the bonkers error handling: if err != nil {...} Half of all go code ever written consists of the line above. Now combine that with defer (or go routines) returning errors...
- ernsheong 8y agoBlog seems to have collapsed under HN weight (link is bad too). Archive of archive of page: https://app.pagedash.com/p/d5c8c4bf-d88a-470b-a7f3-adb986ccb1fe/4tbHK69h6Z0EaM51gvUm https://app.pagedash.com/p/d5c8c4bf-d88a-470b-a7f3-adb986ccb...
- atilaneves 8y ago> as opposed to passing large byte slices or strings around. In theory, this should be more efficient Why would passing a "large" slice be inefficient?? Maybe on x86 due to a lack of registers, but on 64-bit?
- abbiya 8y agowhat kind of domain is this ? https://https.www.google.com.tedunangst.com/flak/post/griping-about-go https://https.www.google.com.tedunangst.com/flak/post/gripin...