[starttoaster]

Is it a perfect language? Far from. But it's a language where I've recognized more pros than cons to using it. My primary complaint lately has been with the inflexible unmarshal functions that cause weird behaviors with converting serialized objects into structs. A recent example is if you use cobra-cli, arguably the most common CLI framework, which ships with another dependency, Viper, for managing your app configuration. If you unmarshal a config with a map[string]anything, where the map keys may contain periods, it just cuts off everything at the first period because it uses periods behind the scenes as a delimiter _for some reason._

Basically, take some yaml like:

```

stuff: 1

things.and.stuff: 2

```

If you unmarshal this yaml into a `map[string]int`, the string keys will actually be, "stuff" and "things". Completely dropping the ".and.stuff". Wild. Keep in mind, this is specific to the Viper unmarshaller, the stdlib json or yaml unmarshallers actually handle this fine, I just have other similar complaints about those.

Given this is my main complaint, not performance or general syntax, I do enjoy writing applications in the language though.

What's the language you're using these days that you feel accomplishes the jobs you need it for better than Go? And preferably also has strong concurrency builtins and is typed.

[nradov]

But those issues aren't the point. The fact that tools like Copilot and ChatGPT work so well for routine coding tasks is an indictment of pretty much all current popular programming languages including Go. From an information theory perspective this means we're still coding at too low a level and writing code with low entropy. There is room for new languages that allow for coding at a higher level of abstraction and factoring out the boilerplate.

As for specific languages, that's not really my area of expertise. Mojo looks promising in some ways. But it may never be suitable for systems programming.

[starttoaster]

I think, at least in their current form and possibly for the near future, that some kind of new language that relied on abstract human operator queries piped to an LLM, would lead to too high of levels of ambiguity of output for most enterprises to accept. To me, this kind of thinking is excellent as a potentially mid to far off goal. But, again this is just my opinion, thinking of it as a short term goal seems naive. It brings to mind the memes of non-technical people asking ChatGPT to make them a basic website, and they send it to a software developer in their family as an html file and go "Are you worried these things are going to make your job obsolete? I just made a website."

Anyway, with it in mind that I believe that is not a short term goal: in the short term, I still need to make money. So I write Go for a paycheck. And based on what I believe the tools available around me today are capable of, I think by _today's_ standards, it is nice to work with in a wide variety of tasks.