>Actually, case sensitive identifiers encourage this. If a library uses camelCase but your code base uses snake_case then you will be using a mix of camelCase and snake_case in order to use that library.

Which will be totally fine, as it involves different variables / things pointed at.

Whereas the "case/underscore insensitive" qualifiers lets you have 10 different versions of the same variable name, in the same codebase -- even without using any third party "library".

Besides, the problem of "third party library uses a different style" is easily solved by having a tool like go fmt that enforces a unique single style. End of story.

This. I can't count the number of times I've used two libraries with different casing just to have my own code end up as a mess of both..

I can see the point though that grepping, and things like editors which highlight the selected variable would have to take these rules into consideration. It's a valid concern but I feel the benefit of clean unified code is more important.

>This. I can't count the number of times I've used two libraries with different casing just to have my own code end up as a mess of both..

Whereas referencing the exported identifiers from the library with a different style than they are written with in the library's code sounds more satisfactory to you?

Yes, that way my code looks more like one entity than a mess of different things.

I can see why you are skeptical of it but once you've used it for a while it becomes second nature. And you can always mix if you want to. The thing is that you can choose how you want to do it. And there are extremely few cases where the casing actually makes the identifiers different (keeping it mind that the first character is type sensitive).