We, as a field, should be very careful about forgiving our tools of the sin of complex and tedious design because those flaws can possibly be remediate with LLMs.

The complexity of boilerplate does not only exist for the author but every future author.

It is not my experience that LLMs and other complex automations are nearly as good as refactoring and changes as they are at generating boilerplate in the first place. In the end this code lives on as a human concern despite the automation.

I agree. I also don't think there is a single perfect programming language yet.

I do think however that programming languages and libraries are the assembly language for AIs to interface with legacy systems targeting human usage.

So it's important for these to be easily understandable.

Go fills that sweetspot better imo. Until something else appears perhaps.

But you're absolutely right that we should make sure to still improve these languages and it is right to worry that LLM don't incentivize new languages (smaller code corpus, less data?). As for Go, it is improving steadily so I'm still confident in that regard.

I am new to go, but to me, the language looks bigger than it needs to be. Why do slices and maps need to be part of the language and not just part of a standard library? I suppose the reason is special syntax, but having to learn that special syntax makes the language feel bigger.

They are part of the language, because they require generics to be implemented if you want to implement them in the standard library. Go didn’t use to have generics, so those constructs were hacked into the core language.

I see. That makes sense. So maybe it is generics that are so fundamental that they need to be part of any language. Seems that Java, C#, and Go have all learned this lesson.