The program isn't particularly helpful for me because my workflow doesn't map out at all. First, we collect sights that we (the group!) want to see. Then everyone prioritizes what is more and less important to them. Then we check what discounts there are on public transport and which tourist tickets are available. This creates constraints as to what we might have to do on the same day. Then we sort the sights on the map. This creates further constraints as to what we have to do on the same day. And then we try to reconcile all of these constraints and interests by spreading the sights out over the days. I have no idea how I could do that with your program.
Thanks for the feedback. I agree that everyone have their own workflow and this might not suit your prefered workflow. Having a 'idea list' is requested several times and I have started working on implementing it. But I don't think this app supports that 'democracy' collaboration yet, nor ticketing constraints...
This text is not about go, it's about agentic coding. I have and am using this across different languages. On this project (which is a go backend) I still have TypeScript in the frontend and I have some Python based tasks too. The rules apply universally.
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.
reply