Hacker News Reader

Comment by ohCh6zos | Hacker News Reader

Defer is a bad feature in Go and I'm hesitant to see it spread to other languages. It exists as a hack because error handling in Go is convoluted.

View on HN

Being able to close an open resource when a function returns is generally useful. It has nothing to do with error handling.

Defer is weird in Go, being tied to function scope instead of immediate block scope.

You're right, that is a better way to put it than what I said.

Function scope allows constructs like

    for _, lock := range locks {
        lock.Lock()
        defer lock.Unlock()
    }

To acquire locks in a loop and release them at the end of a function. Otherwise the previous lock would be dropped each time the loop executes.

I've never seen the advantage to having a block structured defer: it's easy to add a new function, it's not always possible to remove a block.

Named scopes would alleviate this problems, and I wish more languages would adopt them.

..Except that in C that'll turn into stack allocations and will easily segfault due to a stack overflow. So you can't actually use it like that in practice (unless you can guarantee your loop will be called a small number of times). You probably even won't notice while writing the code, and will just get random segfaults wherever you have a defer in a loop when you hit a large enough iteration count. Never mind it being very inefficient while it doesn't.

That's a good point. I was wondering about Zig's defer, which has a block scope, and I suspect it's exactly because of this issue.

Go can allocate defers on the heap, but that's a different story.

Well, we are earnestly analyzing a silly little example program, but okay :). The equivalent C code wouldn't produce stack-allocated mutexes unless that's what the programmer wanted. E.g. the POSIX pthread functions don't care where your mutexes are allocated, since they are always passed by reference.

It's not the mutexes that'd be stack-allocated, but the list of things to call back to at the end of the function. The locks list could be modified or freed by the end of the function, but something still must hold the list of things to deferred-unlock.

The pthread_cleanup_push/pthread_cleanup_pop thing presumably keeps its own heap-allocated vector, backed by malloc or something. C itself can't willy nilly heap-allocate, so that list will be on the stack. But the stack is tiny compared to how long loops can be. Hence stack overflow.

C libraries -- including the runtime implementations of features like this -- can heap allocate just fine. They just need to return pointers on the stack to the heap allocated values, either directly or indirectly (e.g. buried in a struct return value). As is always the case with C, the burden to free the memory is on the caller: no problem.

Given a possible implementation, this loopy mutex example could have a tiny stack footprint: a single pointer to the shared cleanup() function; and a single pointer to the head of a (heap allocated) linked list of pointers to mutex (i.e., the function arguments). And the function pointer would not necessarily require allocation at all, as we can statically point at the function definition here. So we are down to a single word of stack allocation.

Who's going to construct the linked list, and where does it live? That's what the parent comment is pointing out.

In the general case I see no alternative to either the compiler generating one alloca() per defer or heap allocating defer callbacks. Both are terrible solutions for C, because alloca can overflow, while heap allocations can fail with an error code and defer has no way to catch that error. Besides, C programmers just won't use the feature if it requires allocation out of performance concerns. Block-scoped defer is the only reasonable semantics.

Same question in return: who's going to alloca() or heap-allocate the defer callbacks? How is that substantively different from maintaining a linked list? As soon as compiler support is on the table -- i.e. we're not limited to using some too-clever cpp macrology and a support library -- then virtually any implementation is possible. There's obviously more than one way to do it.

> C programmers just won't use the feature if it requires allocation out of performance concerns.

I agree that many C programmers wouldn't touch the feature for performance reasons. But let's not pretend that every C program is a video driver, a AAA game or a web engine. Many, many large C programs would benefit immensely from `defer` semantics -- otherwise, why would the GCC feature exist -- and they are performance-tolerant enough that a little heap allocation would be a reasonable tradeoff for increased safety.

But I'm not really defending `defer` in the first place...

> Block-scoped defer is the only reasonable semantics.

I agree with you completely. :) I was never defending function-scoped `defer`, but answering claims about the necessity of stack allocation. There are possible defer implementations that wouldn't blow the stack: that's my only point.

> But let's not pretend that every C program is a video driver, a AAA game or a web engine.

While true, the culture in C and C++ circles pretends otherwise, hence why we have unsafe by default and safety as opt-in in those languages.

The sky would fall if we lose that 1us.

Let's hope that they sky doesn't fall. :)

It's healthy for culture-conscious programmers to reflect, now and then, on just how small a segment they represent. Cultured programming is fine, but it's like opera: the ordinary programmer recognizes a few of the tunes, but they don't sing along. It's hard to appreciate just how much uncivilized business code is out there, when nobody is getting HN likes for keeping that 1980's ERP running.

> Besides, C programmers just won't use the feature if it requires allocation out of performance concerns.

Nevermind embedded platforms where heap might be unavailable or just so scarce that its use beyond early initialization is strictly verboten. Or interrupt handlers where you simply can't call an allocator.. Block scoped defer could still be useful on such systems (e.g. with locks).

Of course. And if you were writing your embedded system in C++, you'd avoid EH and other non-zero-cost features. That doesn't mean that these features aren't useful in other contexts. I submit that the world of C and C++ programming is vastly larger and more diverse than the world of interrupt handlers and embedded systems.

...But as I pointed out in a sibling comment, I was never defending function-scoped defer. I agree with you. I was pointing out that the implementation of such a feature wouldn't require excessive stack allocation.

defer, as proposed here, isn't a library feature though, it's a part of the core language. I'd like to be able to use it, but if it can ever do a malloc (which is horrifically slow compared to not having one), it's just infeasible.

But I looked through the spec again, and it actually just says that defer outside the top level is implementation-defined, so this is irrelevant anyway.

I admit that I didn't read the actual article. :) I was using "library" in a broad sense, just to mean the runtime code that you didn't have to write yourself.

C doesn't exactly have "runtime code that you didn't have to write yourself" though. There's libc, but you can easily disable it, and having any form of defer be unavailable then is just bad. Everything else comes from your code, the headers it includes (which don't contain function definitions), and statically linked things.

Sure. And just like libc, you could easily disable (by not using) a theoretical libc_defer that provided defer semantics. Kind of like libm, you use it when you need it.

This has been a fun conversation, and I really enjoyed chatting with you about this. :) Take care.

That code is odd (though I assume idiomatic Go). I'd much rather have block scoping with something like this:

    for _, lock := range locks {
        lock.Lock()
        // Do something with lock
    }

And I don't really do Go, but in Rust, if I wanted to lock some arbitrary list of locks for a whole function, it would just be something like this at the top:

    let _ = locks.iter().map(|l| l.lock().unwrap()).collect::<Vec<_>>();

> To acquire locks in a loop and release them at the end of a function.

that looks like a super big gotcha, hasn't there been enough bugs with alloca() being called in a loop yet to show how risky and unintuitive this is ? block-scoped is explicit and explicit is good

Good implementations of defer are scope-based, so those would be clean up at the end of the loop pretty explicitly.

How often do you do something like that? Seems pretty rare. If you're managing locks maybe having an actual collection for them makes sense.

If I had to choose between allowing that pattern and allowing reasonable usage in all control constructs, I'd choose the latter.

I can see one use that when using lock ordering to prevent deadlocks (http://tutorials.jenkov.com/java-concurrency/deadlock-preven...), but then, the locks to be taken are a fixed set, and one probably would have function take_locks(lock *) and release_locks(lock *), and one could do defer release_locks.

Also, Wikipedia (https://en.wikipedia.org/wiki/Deadlock, https://en.wikipedia.org/wiki/Deadlock_prevention_algorithms) doesn’t seem to know about it. Even though I expect/guess it to be popular in embedded work, that makes me wonder whether lock ordering is used much.

Could also be an omission in Wikipedia. It has https://en.wikipedia.org/wiki/Banker%27s_algorithm, which I hadn’t heard of, and that Wikipedia says of

“In most systems, this information is unavailable, making it impossible to implement the Banker's algorithm. Also, it is unrealistic to assume that the number of processes is static since in most systems the number of processes varies dynamically”

I see this code and all I can think is that you’re going to be spending the rest of your life debugging threadsafety issues. I can contrive a case where this is useful, but where in the real world?

The semantics of block-scope defer are much simpler, easier to understand, and faster. The compiler always statically knows which defers execute at any given point, which aids optimization. With function-scope defer, the semantics are extremely dynamic, requiring bookkeeping of a runtime stack of defer thunks, and compilers have a hard time optimizing it.

Function-scope defer is something that surprises everyone I explain it to. Programmers naturally expect defer to be block-scoped.

>With function-scope defer, the semantics are extremely dynamic, requiring bookkeeping of a runtime stack of defer thunks, and compilers have a hard time optimizing it.

As far as I know, most functions have only one defer, and Go optimizes such cases quite trivially, by inlining calls to the deferred function at every function exit at compile time, without managing an additional stack. If there are several defers, then yes, the slow path is used.

How does it handle a single defer in an if?

It's very common for a function to have multiple defers ... but defers in a loop are a misuse of the feature.

You mixed up the two I guess?

What in your view makes defer a bad feature of Go? Maybe my bar is low, but each time I jump back to C I wish I had defer and end up abusing __attribute__((cleaup)) instead.

> error handling in Go is convoluted

Is it worse than in C that there is no concept at all? Is it better that everyone is on their own to do it their own way every time?

I’m not above making the eaiser, but to your point when I see their example of:

  double* q = malloc(something);
  defer [qp = &q]{ free(*qp); };

That doesn’t look like the C that I know.

The C you will get to learn is also planning to have lambdas, and they are being based on C++ design rather than Apple's blocks, so the example assumes they will also be in C2X.

It’s already exists in other languages and it exists because a function could have multiple different exit points. Even if Go had different error handling there might well be different exit points. Hence why defer isn’t a Go-specific feature.

>It exists as a hack because error handling in Go is convoluted.

What's the alternative, though? Sprinkle your code with try..finally's? RAII like in C++?

Result types

Defer is used to automatically release resources on function exit, I'm not sure how result types will help here. Can you give an example?

It's an alternative to try...finally or RAII.

Context managers, or an Auto-Closable interface with syntactic support.

Also why is RAII bad? It's an awesome feature in C++.

>Also why is RAII bad? It's an awesome feature in C++

I didn't mean it's bad (I used to be a C++ developer myself and enjoyed RAII a lot), just wondering what are the alternatives that the OP doesn't consider "hacks". RAII would require to introduce constructors/destructors in the language, with all the gotchas (and probably you'll want a full-fledged OOP after that), which is apparently against Go's design principles as a simple language.

>Auto-Closable interface with syntactic support.

I don't see much difference here in practice; the whole difference is that in C#, for example, you use "using" on a whole object, while in Go it's a "defer" on a specific method of the object (or a standalone function). You are not limited to a single method and can use it on any method you deem necessary.

Auto-closeable/RAII, however, is less flexible in ad hoc situations specific to a certain function (you have to define dummy classes just to make sure a function is called no matter what), Go allows to use "defer" on a lambda. Auto-closeable also ties control flow to an object, which makes sense in an OOP-focused language, but Go isn't one.

I agree with most of your points, but I wanted to also point out that you don't need C++'s ctor/dtor spaghetti to have useful RAII: Rust achieves it without even having first-class constructors (and opt-in custom destructors via Drop).

RAII is fine. If it's a language feature, APIs can provide that to you so you don't have to write RAII wrappers all the time.

Otherwise a generic _bracket_ operator could be introduced, similar to Python's `with` statement. In C it might be a bit hard to parameterize, but even if it just requires you to use a void, it's still an improvement vs. not having anything at all. (Talking about language features so `__attribute__((__cleanup__))` doesn't count.)

Imagine something like this:

    FILE* handle = bracket(fopen("data.bin", "rb"), fclose) {
        fread(..., handle);
        return;
        fwrite(..., handle);
    } // <-- implicitly calling fclose(handle), always

Edit: After writing this sample I could even an optional `else` block in case `fopen` returned `NULL`.

Edit2: Of course, syntax fine-tuning would be welcome. For instance, `handle` should be restricted to the bracket's scope.

Defer has nothing to do with error handling. Defer is a great feature in Go, I've never seen someone complain about it.

Defer CAN help with error handling, but you need other language features for that. You need well defined error types or exceptions in some way or another.

Zig has errdefer which only runs if an error occurred below the statement within that scope. It allows you to always keep cleanup locally, but you can still handle errors for your business logic somewhere else.

errdefer is cool, but I don't think C should support it. Mainly because you'd need to spec errors at a language level, and doing that today is probably impossible.

Reply on news.ycombinator.com