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

In praise of –dry-run

henrikwarne.com

Post reply on HN
Print view View original

171–175 of 175 posts

Re: In praise of –dry-run

#171

Post by zbentley »

HackerThemAll wrote: post #170
zbentley wrote: post #167

Earlier quoted context omitted.

In my case, I’d use a ZFS snapshot. Many equivalent tools exist on different OSes and filesystems as well.

Really? Should I be snapshotting the volume before every "rm"? Even if it's a part of routine file exchanges between machines? (As it happens for many production lines, especially older ones). I think the current semantic of "rm" works fine. But I understand the new world where we'll perhaps gonna be deleting single files using Terraform or cluster of machines, or possibly LLMs/AI agents.

Oh, I don't think we should change the semantics of "rm"--not because reversibility is unimportant (shameless self-promotion: it is: https://blog.zacbentley.com/post/on-reversibility/), but because baking it into "rm" is the wrong layer.

Folks usually want reversibility in the context of a logical set of operations, like a Terraform apply. For shell commands like "rm", the logical set of operations might be a session (having a ZFS snapshot taken on terminal session start, with a sane auto-delete/age-out rotation, would be super useful! I might script that up in my shell profile in fact) or a script, or a task/prompt/re-prompt of an AI agent. But yeah, it definitely shouldn't happen at the level of a singular "rm" call.

Since filesystem snapshots (in most snapshot-capable filesystems, not just ZFS) are very simple to create, and are constant-time or otherwise extremely fast to perform, the overhead of taking this approach wouldn't be too hard.

Re: In praise of –dry-run

#172

Post by awesome_dude »

cake-rusk wrote: post #161
awesome_dude wrote: post #143

Earlier quoted context omitted.

I typically reach for Go when I am building things, bubbletea, a TUI library uses the Elm architecture and enforces it on people using it. Did not like, Won't use again. MVC is well understood and works perfectly in my experience. edit: Even though you were tongue in cheek about F# - this stood out on the page > The functional programming community has design patterns and principles as well.

IMO the ELM architecture only works with pure functions. It doesn't work with languages which cannot provide this compile time guarantee. Also functional programming needs a different mindset / training. You won't benefit from it until you understand what it actually brings to the table (and what it leaves out).

I have to ask - I like some of the paradigms of Functional programming (IMO it makes concurrent programming a lot easier because state is never shared)

Why hasn't it cut through, like OO did?

and

Beam has been around since the 90s, had a good marquee project (RabbitMQ) but still has low adoption

Re: In praise of –dry-run

#173

Post by mycall »

james_marks wrote: post #44
Darfk wrote: post #42

Earlier quoted context omitted.

Totally agree it shouldn't be for basic tools; but if I'm ever developing a script that performs any kind of logic before reaching out to a DB or vendor API and modifies 100k user records, creating a flag to just verify the sanity of the logic is a necessity.

Yep. First thing I do for this kind thing is make a preview=true flag so I don’t accidentally run destructive actions.

Now I like that idea as an environment variable that takes precedence over the command parameters.

Re: In praise of –dry-run

#174

Post by cake-rusk »

awesome_dude wrote: post #172
cake-rusk wrote: post #161

Earlier quoted context omitted.

IMO the ELM architecture only works with pure functions. It doesn't work with languages which cannot provide this compile time guarantee. Also functional programming needs a different mindset / training. You won't benefit from it until you understand what it actually brings to the table (and what it leaves out).

I have to ask - I like some of the paradigms of Functional programming (IMO it makes concurrent programming a lot easier because state is never shared) Why hasn't it cut through, like OO did? and Beam has been around since the 90s, had a good marquee project (RabbitMQ) but still has low adoption

I am not sure I if I can speak to that in general but personally I discovered functional programming late. Object oriented programming was all the rage when I got initiated and that is all that was taught in colleges.

Re: In praise of –dry-run

#175

Post by mwarkentin »

IanCal wrote: post #152
jasode wrote: post #133

Earlier quoted context omitted.

>That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. Not to take anything away from your comment but just to add a related story... the previous big AWS outage had an unforeseen race condition bet…

Overkill I’m sure for many things but I’m curious as to whether there’s a TLA kind of solution for this sort of thing. It feels like it could although it depends how well modelled things are (also aware this is a 30s thought and lots of better qualified people work on this full time).

Or something like https://antithesis.com/
Post reply on HN