undefined | Better HN

0 pointsyencabulator2y ago0 comments

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

0 comments

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.

yencabulatorOP2y ago

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_lav2y ago

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.

stouset2y ago

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.

1 more reply

alex_lav2y ago

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_lav2y ago

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.

j / k navigate · click thread line to collapse

0 comments

stouset2y ago

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.

yencabulatorOP2y ago

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_lav2y ago

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.

stouset2y ago

1 more reply

alex_lav2y ago

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_lav2y ago

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.

j / k navigate · click thread line to collapse