I built a library to do something similar: https://www.npmjs.com/package/yaplib defer is the thing I miss the most coming from Go
Cool! I kinda feel like these should be built-in. But this looks useful for closing the DX gap here.
Adding Go's Defer to the TypeScript Compiler
21–30 of 31 posts
Re: Adding Go's Defer to the TypeScript Compiler
#22Is "defer" a good pattern? Aren't constructors/destructor pairs, like in C++/Rust, or "with" blocks in Python, better, because you cannot forget to call the destructor. I the first code example in the article, it is easy to omit "defer" and the compiler won't notice.
Re: Adding Go's Defer to the TypeScript Compiler
#23Earlier quoted context omitted.
If the idea of computers is that they remember stuff for you and do stuff for you, then both try/finally and defer seem like hacks to work around not having RAII like e.g. Rust or C++ where resources are closed/disposed of/deallocated automatically. Try X finally dispose of all resources. X, defer clean up X. Or how about just X and cleanup is done automatically, with the author of the resources deciding what is need…
it's mesmerizing that the fantastic ergonomics of RAII have not propagated to other languages. It's way easier to use, much clear, less typing, more predictable runtime behavior. RAII... terrible name, great concept!
It only works for stack allocations or when using reference counting, which isn't the ultimate performance of GC algorithms.
Re: Adding Go's Defer to the TypeScript Compiler
#24Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
If the idea of computers is that they remember stuff for you and do stuff for you, then both try/finally and defer seem like hacks to work around not having RAII like e.g. Rust or C++ where resources are closed/disposed of/deallocated automatically. Try X finally dispose of all resources. X, defer clean up X. Or how about just X and cleanup is done automatically, with the author of the resources deciding what is need…
Only when doing stack allocations or reference counting, any other heap management strategy and RAII can't help as well.
For example, combining RAII with lock free data structures, which usually ends up in techniques like hazardous pointers instead.
Re: Adding Go's Defer to the TypeScript Compiler
#25Is "defer" a good pattern? Aren't constructors/destructor pairs, like in C++/Rust, or "with" blocks in Python, better, because you cannot forget to call the destructor. I the first code example in the article, it is easy to omit "defer" and the compiler won't notice.
[deleted]
Re: Adding Go's Defer to the TypeScript Compiler
#26Earlier quoted context omitted.
If the idea of computers is that they remember stuff for you and do stuff for you, then both try/finally and defer seem like hacks to work around not having RAII like e.g. Rust or C++ where resources are closed/disposed of/deallocated automatically. Try X finally dispose of all resources. X, defer clean up X. Or how about just X and cleanup is done automatically, with the author of the resources deciding what is need…
I mean, sure, but RAII (in C++, at least) is implemented the same way as this article: with a try...finally block! RAII doesn't really fit into every language because they don't all have deterministic destructors/finalizers and objects with scoped lifetimes. Sometimes you only have one but not the other and you definitely need both.
that's a very broken metaphor - it might be "similar" to try-finally block if you only have one variable/object following RAII. But try-finally block(s) become complete mess when multiple variables are involved, and again requires way more typing/duplication than RIAA. And "similar" in terms of results, NOT similar in terms of performance as try {} block requires additional instructions to set it up, whereas RIAA is runtime free.
And regarding sibling post about finalizers -- another broken concept as you cant use finalizers with limited resources (ex. graphic contexts, db connections, handles, locks, etc) and then these languages that use finalizers become complete mess if you need to manage such resources.
Re: Adding Go's Defer to the TypeScript Compiler
#27Is "defer" a good pattern? Aren't constructors/destructor pairs, like in C++/Rust, or "with" blocks in Python, better, because you cannot forget to call the destructor. I the first code example in the article, it is easy to omit "defer" and the compiler won't notice.
Defer is easier to fit into TS/JS as GC isn’t observable ( it kinda is with FinalisationRegistry but with a huge list of gotchas ).
Defer only cares if the variable leaves scope. At the end they mention the new “using” syntax which only requires you to mark the declaration, not requiring an additional statement for the cleanup. It’s kinda nice but the resource needs to implement a cleanup method making it less flexible than defer.
Re: Adding Go's Defer to the TypeScript Compiler
#28Earlier quoted context omitted.
I mean, sure, but RAII (in C++, at least) is implemented the same way as this article: with a try...finally block! RAII doesn't really fit into every language because they don't all have deterministic destructors/finalizers and objects with scoped lifetimes. Sometimes you only have one but not the other and you definitely need both.
that's a very broken metaphor - it might be "similar" to try-finally block if you only have one variable/object following RAII. But try-finally block(s) become complete mess when multiple variables are involved, and again requires way more typing/duplication than RIAA. And "similar" in terms of results, NOT similar in terms of performance as try {} block requires additional instructions to set it up, whereas RIAA is…
> And "similar" in terms of results, NOT similar in terms of performance as try {} block requires additional instructions to set it up, whereas RIAA is runtime free.
By similar I meant from the compiler's point of view. `try...finally` is the low level primitive to ensure some code runs at exit. If something throws an exception then destructors must run when unwinding the stack, which is what `finally` is for! But if you disable exceptions then `try` blocks are probably all basically no-ops.
Re: Adding Go's Defer to the TypeScript Compiler
#29Earlier quoted context omitted.
Finally isn't bullet proof. If you execute a promise in a try block and it happens to end without resolving, the finally block will be never be executed. Fun stuff.
defer isn't bullet proof either. I think there's a linter about it and os.Exit. One can just wrap os.Exit in a helper to get the expected behaviour.
I would expect to have a method that explicitly stops program execution immediately without further side effects.
An unresolved promise that causes other code to be skipped while program execution continues after the block is, well, unintuitive to say the least.
Re: Adding Go's Defer to the TypeScript Compiler
#30Earlier quoted context omitted.
defer isn't bullet proof either. I think there's a linter about it and os.Exit. One can just wrap os.Exit in a helper to get the expected behaviour.
Also, if you pull the power plug, neither finally blocks nor defers would run. I personally consider it a clear and obvious deficiency in the semantics (and the implementations) of those programming languages but everybody refuses to listen to me.
Back in the days of spinning rust, we had RAID controller cards with batteries, so that if someone pulled the plug, there would be enough power to keep the drives going until any buffered writes were completed.
I certainly wouldn't mind if modern servers had something similar to make sure programs could stop gracefully. But then that doesn't help if you have a hardware failure...