[alex_lav]

> It is interesting to see them add things like the "clear" function for maps and slices after suggesting to simply loop and delete each key one at a time for so long.

Slowly walking back dogmatic positions is just how the Go team works.

I say this as a person that wrote Go full time for a handful of years.

[yencabulator]

No, it's because a use case was discovered that the for loop approach can't handle: NaN keys.

[stouset]

In my experience, that's exactly how this plays out every single time.

    Dev: Can we have a function to clear a map?
    
    Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time.
    
    Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals?

    Go: We've implemented a compiler optimization to detect this and rewrite it to the faster code it would have been if it we were to implement it.

    Dev: Isn't that… way harder than just writing the method? Anyway, I noticed this solution doesn't actually always work because of this edge case.
    
    Go: Just handle the edge case every time then.

    Dev: That's the point. I can't.

And around and around we go.

[yencabulator]

You're distorting the real story to fit your bias. Once the NaNn edge case was discovered, work to deal with that edge case was started.

[alex_lav]

Can you link to any unit of work that solves this edge case? Because all I can find are bugs and issues created 2015/2016/2017 that were closed and unresolved.

[stouset]

This isn't remotely close to the first or even the tenth time I've seen this exact pattern play out. Finally there's some straw that forces the golang team to backpedal on a dogmatic position, but along the way there's dozens of comical defenses of the current state of things.

[philosopher1234]

So you say, with no actual reference. Maybe what you refer to happened in your head, and not in the real world.

[alex_lav]

1. Generics

2. Clear

Are the two already covered not enough?

[alex_lav]

I used to really like Go. Now that I don't work with it, I find that the further I go on without it, and with using other tools, the less and less I'd want to go back.

[alex_lav]

I would argue Go's inability to manage NaN keys is irrelevant to the desire for "clear", in that I would argue that the NaN keys issue should be fixed _regardless_ of clear.