My poor use of golang's defer woke me up
blog.daemonl.com
My poor use of golang's defer woke me up
1–10 of 25 posts
Re: My poor use of golang's defer woke me up
#2I've been bitten by similar complexities around indirectly managing the database connection pool in Go, too. There might be a little too much magic in the library (such as successfully iterating to the end of a resultset implicitly releasing the results).
Re: My poor use of golang's defer woke me up
#3I've been bitten by similar complexities around indirectly managing the database connection pool in Go, too. There might be a little too much magic in the library (such as successfully iterating to the end of a resultset implicitly releasing the results).
That one I'm still not clear on. I THINK I should be closing that particular rows set already, the SQL is LIMIT 1 and I check if !rows.Next(){return ...}, yet... here we are :-)
Re: My poor use of golang's defer woke me up
#4Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will.
You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing code is way easier than writing it from scratch
Re: My poor use of golang's defer woke me up
#5Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will. You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing c…
Yep. I know. I even deleted the github repo.
I'm seriously not sure what I was doing.
Remove all traces of a bad idea?
Re: My poor use of golang's defer woke me up
#6Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will. You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing c…
Sometimes you just need to burn the pictures of you with your ex and move on. In some way, you should "KEEP" everything, after all digital space is cheap right? But you can keep a lot of code around that you will never revisit in the future.
> but trust me, re-writing code is way easier than writing it from scratch
Not always true, and not even often true.
Re: My poor use of golang's defer woke me up
#7Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will. You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing c…
Sometimes you just need to burn the pictures of you with your ex and move on. In some way, you should "KEEP" everything, after all digital space is cheap right? But you can keep a lot of code around that you will never revisit in the future. > but trust me, re-writing code is way easier than writing it from scratch Not always true, and not even often true.
> > but trust me, re-writing code is way easier than writing it from scratch
> Not always true, and not even often true.
In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that idea. If you have the time, a full rewrite almost always turns out to be better code than the old version, as long as you can hold off on trying new experiments in the process.
Re: My poor use of golang's defer woke me up
#8Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will. You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing c…
grep -a 50 -b 50 string /dev/disk0 ftw
Re: My poor use of golang's defer woke me up
#9Earlier quoted context omitted.
Sometimes you just need to burn the pictures of you with your ex and move on. In some way, you should "KEEP" everything, after all digital space is cheap right? But you can keep a lot of code around that you will never revisit in the future. > but trust me, re-writing code is way easier than writing it from scratch Not always true, and not even often true.
> > but trust me, re-writing code is way easier than writing it from scratch > Not always true, and not even often true. In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that ide…
You can always take the experience, but often the old code exists in such a misguided architecture that it is better to scrap it vs. unwind multitudes of bad uninformed decisions (b.c. you know better now!).
Re-writing code is actually almost always harder than writing it from scratch, but we do it for other benefits: interoperability with legacy components, legacy of expected behavior (warts and all), risk (the old code is debugged), and culture (programs in the team know that code). But if you don't have those requirements, you will often come out behind in rewriting all code rather than going with a green field.
It also depends on whether the work one is doing is cutting edge (lots of experimentation and learning required) or basic dev work over relatively well known concepts.
Re: My poor use of golang's defer woke me up
#10> [...] sudo less /var/log/upstart/app.log, 99999... oh, this log ACTUALLY has 99999 lines. Waiting, Waiting (note to self: google the command to jump to the end, there must be one).
G (as in shift-g) jumps to the end of the file in less. Or use tail instead.