On HN, reposts are fine (which is to say, aren't treated as dupes) when a story hasn't had significant attention in the last year or so. This is in the FAQ: https://news.ycombinator.com/newsfaq.html.
But it's great to link to examples of past threads, because readers like to look at them—so this was a good contribution! just not with the tag "duplicate".
Edit: basically, there are two disjoint cases when it makes sense to link to a previous submission of the same story:
(1) when a prior submission of the same story had significant attention in the last year or so, then linking to it with the word "duplicate" or "dupe" is helpful;
or
(2) when a prior submission had significant attention more than a year ago, then linking to it with the phrase "past discussion" or "discussed at" (or something like that) is helpful.
(And for completeness: when a submission has not gotten significant discussion, it's best not to link to it at all. There are plenty of those in the archives, and they're mostly harmless.)
Thanks for that last note, it's been my argument for a while and I've had a few discussions with people on that point, e.g., <https://news.ycombinator.com/item?id=40849927>. I'll try to remember this comment to share for those cases.
I am wondering what this statement actually means:
> The reverse predicate from this section should not be used in practice - most Prolog implementations actually provide a built-in version which is a lot more performant than our implementation.
I think it can be read as: If you care about speed do not use Prolog, instead write a "built-in" solution.
While the most precise naming might be "a singly linked list representation of a stack", "free list" (https://en.wikipedia.org/wiki/Free_list) is an ancient term of art for this problem.. so much so that wikipedia (at least the version today) even suggests "freelist" all one word as a spelling.
The initial linking together of all free space (also cache friendly, btw) is often called "threading the free list", although this terminology is less standard than "free list" itself.
Exceptions are easier for the programmer. The programmer has to write less and they clutter the code less. But exceptions require stack traces. An exception without a stack trace is useless. The problem with stack traces is: they are hard to read for non-programmers.
On the other side Go's errors are more work for the programmer and they clutter the code. But if you consequently wrap errors in Go, you do not need stack traces any more. And the advantage of wrapped errors with descriptive error messages is: they are much easier to read for non-programmers.
If you want to please the dev-team: use exceptions and stack traces.
If you want to please the op-team: use wrapped errors with descriptive messages.
Messages and stack traces in the error are orthogonal to errors-as-values vs. exceptions for control flow. You could have `throw Exception("error fooing the bar", ctx)`. You could also `return error("error fooing the bar", ctx, stacktrace())`. Stack traces are also occasionally useful but not really necessary most of the time IME.
Go's error handling is annoying because it requires boilerplate to make structured errors and gives you string formatting as the default path for easy-to-create error values. And the whole using a product instead of a sum thing of course. And no good story for exception-like behavior across goroutines. And you still need to deal with panics anyway for things like nil pointers or invalid array offsets.
Go messages are harder for both devs and users to read. Grepping for an error message in a codebase is a special hell.
Besides, it's quite trivial to simply return the exception's getMessage in a popup for an okay-ish error message (but writing a stacktrace prettifier that writes out the caused by exception's message as well is trivial, and you can install exception handlers at an appropriate level, unlike the inexpensibility of error values)
I tend to use "catch and re-raise with context" in Python so that unexpected errors can be wrapped with a context message for debugging and for users, then passed to higher levels to generate a stack trace with context.
For situations where an unexpected error is retried, eg, accessing some network service, unexpected errors have a compressed stack trace string included with the context error message. The compressed stack trace has the program commit id, Python source file names (not pathnames) and line numbers strung together, and a context error message, like:
[#3271 a 25 b 75 c 14] Error accessing server xyz; http status 525
Then the user gets an idea of what went wrong, doesn't get overwhelmed with a lot of irrelevant (to them) debugging info, and if the error is reported, it's easy to tell what version of the program is running and exactly where and usually why the error occurred.
One of the big reasons I haven't switched from Python to Go for HashBackup (I'm the author) is that while I'd love to have a code speed-up, I can't stomach the work involved to add 'if err return err("blah")' after most lines of existing code. It would hugely (IMO) bloat the existing codebase.
The default setup is pretty crappy but with some tweaking of the ssh connection setup, It does a decent job and I used it for actual work for several years.
It's been a long time. Most of the stuff I was able to get from conversations on the Emacs IRC channel of freenode. Many of those "tricks" are documented here https://www.emacswiki.org/emacs/TrampMode but I don't know if it's out of date.
https://github.com/rybbit-io/rybbit/blob/master/server/GeoLi...