This rings true for me. The value of HN early in my career was exposing me to a firehose of industry content while I tried to figure out my place.

As I get further into my career, the signal to noise ratio is shifting quite a bit. I’ve seen many iterations of what’s being posted already, most of the comments aren’t novel, etc.

At this point HN is a habit. And a hard one to break.

Well, it tells us about the Go programmers on the forum. One possibility is that as Go has become more mainstream, Go programmers have become less competent on average.

Go is very close to C.

A C programmer who understands a for loop should be able to fix this, despite the fact it's Go:

  // We are generating n-1, n-2, ..., 1, 0

  func below(n uint64, to chan uint64) {
      for n--; n >= 0; n-- {
          to <- n
      }
      close(to)
  }

Maybe you're right: It could be that C programmers don't understand Go syntax and Go programmers tend to be less experienced.

EDIT: the version I pasted below is not what I originally typed into the site. I made several errors while copy/pasting and modifying the code to run locally without a channel.

It told me I have an error ("what happens at zero") when i do:

  func below(n uint64, to chan uint64) {
        for n; n > 0; n-- {
            to <- n-1
            n--
        }
        close(to)
    }

but running that function with several test inputs produces what I expected. Note, I removed the channel (replaced with println) as that doesn't add anything to the problem.

Note: I've been programming (including C and C++) for 3+ decades. I make mistakes all the time, but.... what exactly are you looking for here if my solution is not ruight?

EDIT: the pasted code is also incorrect, because I didn't complete converting the for loop into a while.

Why did you choose to decrement n twice on each iteration? What happens when n is odd vs even now?

Oh, sorry, I didn't paste the right code.

On my machine I used this code:

  package main
  import "fmt"
  func below(n uint64 ) {
      for n>0 {
      fmt.Println(n-1)
          n--
      }
  }


  func main() {
      below(10);
      below(0);
  }

The actual code I put into the bugfix site was:

  func below(n uint64, to chan uint64) {
          for n>0 {
              to <- n-1
              n--
          }
          close(to)
      }

but when writing this comment I went back and didn't modify the for loop to be a while.

The above code is correct, and of course it is accepted.

Why does it say "What happens at 0" when you omit the decrement?

When your code is wrong, the server gives you a clue hinting at what's wrong in the original code.

It doesn't know what's wrong in the code you submitted... it is not understanding deeply what's wrong with your code. It's not some huge multi-terabyte language model analyzing arbitrary code, or whatever.

It just knows your code is wrong and gives you a clue so you can try again.

If you omit the decrement, it's an infinite loop for n>1, presumably, you are detecting that?

The server is checking the output of the function.

Here is an example of what's running behind the scenes, to help you understand:

https://bugfix-66.com/contribute

The above code is what's being used for Bug #1:

https://bugfix-66.com/a6cb1e062ae0fdc47b43ec489aa40a958db728...

Is that pretty clear?

I also came to a solution very similar to the sibling comment here. I'd love to see why this doesn't work server-side but does work on my machine. What other tests are you running aside from checking each decrement is correct?

Show me your code, that you think is correct, and the server rejects.

I'll tell you what's wrong with your code.

Might I recommend appropriate debugging output? It would save the mystery and back and forth. Not everyone who uses your site has access to you on HN. :)

    func below(n uint64, to chan uint64) {
        for ; n >= 0; n-- {
            var t = n - 1
            to <- n
        }
        close(to)
    }

I've run this locally with to <- n replaced with a print statement and it works with unsigned integers.

Did you make other changes besides `to <- n` becoming print? Because as it stands, that will still produce an infinite loop.

Oh, yes. The for loop init should be "; n > 0; n--"

I don't program C or Go. I ran the logic and it works; I verified by running a modified version of this method on my computer.

    func below(n int) {
        for n--; n >= 0; n-- {
            fmt.Println(n)
        }
    }

I modified the type so I could punch in some sane integer, like 4. And this works.

    C:\git\bugfix66> go run .\bugfix66-2.go
    3
    2
    1
    0

Am I to assume that the bug is actually a type issue? Something to do with unsigned integers?

Wait. Oh. Ok. I get it. It does have to do with the type signature.

What happens if you start at n=0 for uint64?

(my real comment after I get some clarification from the bugfix site author is that I never, ever modify a variable in the initialization condition of a for loop, and i see that in the wild, I elide it.

You're using a signed integer.

While it is of course possible for people from other languages to do your puzzles, I'd expect most of the players to be Go programmers.

> Presumably people migrate elsewhere as they mature? I don't know of another forum like Hacker News, so where are they going?

As someone who has been reading and posting here regularly since 2009, here's what I'm finding: The further I get in my pursuits, the more my concerns and tribulations become specialized and weird. To get a useful answer from the public internet would require so much backstory and explanation that it's barely worth trying. And the answer would likely be wrong or not useful.

Instead real world social networks and specialized micro communities are where it's at. A lot of paid consultations as well. Pay a few hundred (or thousand) bucks to an expert and get the correct customized answer to a specific problem. Worth every penny compared to reading tea leaves off the wild internet.

But HN is still one of the highest signal broad communities out there so it's fun to stick around.

Does your bugfix problem actually test said code? Or does it just look for a specific change to be made, because I'm reasonably certain I input multiple correct solutions and they were all marked as having not solved the problem.

Yes, the code you enter is compiled and run against a suite of tests. Any change that fixes the function will be accepted.

Any change that doesn't compile (bad syntax) or fails the tests is rejected. Code that produces deadlock or panic or timeout is also rejected.

If you give me an example of a rejected solution, I'll show you why the solution wrong.

Please, can we not be so uptight and formal in an informal discussion forum?

This seems like unnecessary tone-policing. I said exactly what I think is incorrect in their comment and why, without any judgements about them.

If anything, my downvote comment was too childish. I was put-off by their line about not downvoting because it was “empirical”. Seemed to insinuate anyone who disagreed was just going against the facts.

Edit: oh, didn’t realize I was replying to you again.

It is a bit of a fair point though: you're only measuring "the success of people from HN who engage with your game", so it's not sound to draw conclusions about "the population of all HN users". Even if it is true that HN has a junior-skew, it wouldn't mean there is necessarily "somewhere else" -- lobste.rs aside, the eternal september effect (or other things) could be enough to keep the demographic population skewed junior.

I've been programming for about 15-20 years, and using HN since 2007 or 2008 or so. I opened your site while reading the voxel thread, and was a little baffled about what I was encountering -- "why am I suddenly reading buggy go code? I thought this was an example of a spacial curve!" -- so, I went to check out your other posts to figure out what your deal is, and here we are.

I don't know Go, and I don't really want to "play a programming game" right now. Your code seemed a little obtuse and intimidating -- long bitmasks and combinations of xors and abstract names -- no thanks! There's a bug in there? How surprising!

I do lots of programming at work and in my spare time, and to a degree, I just can't be arsed when someone jumps out of the woodwork with "a bug" that it isn't going to mean anything to fix, so I moved on. I'm an experienced programmer who you likely aren't measuring.

So I saw your comment here, and my first thought was: well, that's a big (logic) bug in the reasoning of a person who made a game of fixing bugs! Kinda tasty irony, and totally fair game for the poster above to call out, in my opinion.

(anyway, after all this, I am a little bit more interested to go try out the above-mentioned challenge. It's a neat idea for a game, and you seem to have put a lot of work into it. Best of luck!)