I don’t think they mean that it can’t, just that the better way to think about the advantages it gives an experienced engineer is more along the lines of “autocomplete v2”, i.e. a keystroke-saver.

Is it a keystroke saver if you need to review every line it proposes to you?

Yes because often times while I'm unable to recall the exact idiosyncratic keywords incantation that I need, copilot will retrieve them automatically. This saves me a context switch to MSDN docs or stack overflow.

It automates a great deal of boilerplate crap that you have to do especially in web frameworks such as angular.

Yes. For my part, it's a very obvious boost in exactly that sort of keystroke-saving way.

Here's an example I just now tried in the codebase I had open. I literally typed in the following Go in a function:

  mean := geom.Vec3D{}
  for 

Copilot then autocompleted this, me pressing tab to accept each line, to:

  mean := geom.Vec3D{}
  for _, detection := range filtered {
    mean.X += detection.X
    mean.Y += detection.Y
    mean.Z += detection.Z
  }
  mean.X /= float64(len(filtered))
  mean.Y /= float64(len(filtered))
  mean.Z /= float64(len(filtered))

It's not a perfect platform by any means, but it's also pretty useful for this sort of autocompletion.

I can picture autogen boilerplate being collected and distributed in versioned "community expansion packs" to popular languages, and I'm not looking for fragmentation like that in my tools. I really don't want my IDE involved like this.

I'd rather see Copilot used to expand existing libraries. Pulling potential additions to your own library off of Copilot would be an interesting twist on the situation. A hacktoberfest-alike based off this would be weird.

Nobody is forcing you to use it... Others like myself find it useful and to be a huge timesaver. If it doesn't benefit you, then just don't use it. Why must people be so vocal about not liking something? I get that you don't think it would be useful for yourself, but it sounds like you've never used it, yet are against it enough to come bash on it in a thread.

I think you should give it a try and see what you think about it. I was hesitant about it at first but was very surprised at how much time it could save me from having to look up things on Google. I've found it especially useful when I'm switching to a language I may be less familiar with. I can understand the basic logic of what I want to do, but would have to spend time looking up how to do it in this specific language. Orrr... I just have copilot help me out and generate such a solution.

It's obviously not going to be a tool that is applicable to everyone. Just like how many manual labour oriented contractors have a bunch of tools, each of them may have their own set of tools that slightly differs from the other person. That is okay, and there would be no need to try and bring someone else down for their choice to use a certain tool.

No, I think it's amazing. My point is why not write its suggestions down somewhere and cut out the middle man.

My concern is that I'd get locked into a specific IDE.

This is a good example of why I dread Copilot: even if Go specifically couldn't express this any more concisely, there is a language that can and Copilot's very existence makes it less likely for that other language to be used as much as it deserves.

Besides, the generated example seems to be missing code to gracefully handle the case where len(filtered) is zero. Maybe there's a precondition that prevents that from happening or maybe a division by zero is exactly what you'd want, but at face value it looks like the bot did a rush job.

Zero is gracefully handled; the mean of a zero-sized set is best represented by NaN, and this would be idiomatic in most languages' IEEE754-style handling.

Saturation is not. This is what really bugs me: If I'm going to drag in a billion GPUs of external computation (or a dependency, which is basically the same thing but with human brains), I want it to provide the hard algorithm I can't write, not the easy one I can. I am not limited by typing speed.

I also wonder what a "detection" is.

Agreed about saturation and the choice of variable name, but the code would trigger a division by zero and not result in NaN: https://go.dev/play/p/vYm4tSNEJ7M

(Also, in--say--Ruby and JavaScript 1.0/0.0 is Infinity and not NaN.)

Your playground link shows a build error. 0.0/0.0 at runtime will be NaN. And in basically every language, 1.0/0.0 is Infinity. But we're talking about 0.0/0.0.

Both good examples of coding where you should be thinking instead, though.

I think if anything there is far too much thinking going on here, for the tiny example I copied from the window I literally already had open with the function I was working on.

For what it's worth, Copilot (correctly) inferred a loop variable called "detection", I imagine based on similar usage earlier in the function. And there is already a conditional in place to prevent invalid operations; if I remove it I see a new suggestion:

  if len(filtered) > 0 {

This tool is far from perfect, but it very much sounds like you folks haven't used it. If that's the case, I would encourage you to research it like all tooling and draw some informed conclusions about it's applicability instead of making assumptions.