*shrug*

I'm not sure where I would begin.

The tuple and collection syntax?
The function definition syntax?
Allowing ambiguous terminals?
Allowing arbitrary layout?
Confusing language facilities with library facilities?
The lack of implicit binding to shared state from the native thread syntax?

*shrug*

I'll stop with those because I don't expect anyone to read all of this anyone, but on the off chance someone does read it hold this to your mind: I was asked specifically for my opinion so don't get fussy that I've offered it.

The tuple and collection syntax is a point of obscurity. Like many of the languages this syntax was borrowed from the syntax attempts to patch tuple and collection mechanics into single item syntax so forcefully the simplicity of the syntax becomes a point of obscurity. I've seen some code samples in the wild that was attempting to brag about the syntax which, after removing the comments, I could no longer follow. I like my sugar. I like it a lot. You don't need to cram every conceivable mechanism into the same syntax. It would like overloading the binary multiplication operator (*) in C++ for a matrix facility to do scalar, matrix, and vector multiplication and also for some reason the union set operation. It is sometimes better to just introduce a new operator.

The function syntax is flaky enough (like C++) that parsing it is a bloody hassle. Okay. Fine. We have a provision for the language from Google. How little that means if the tools Google provides isn't sufficient. The easier a language is to parse the more sophisticated tools can be allowing more competition for building such tools. The upshot to an easy to parse language is easier development time in the form of less effort needed to track down and debug problems.

I hate ambiguous terminals! I've written parsers of all kinds and all flavors now for fifteen years. I can't overstate how much I hate this kind of ambiguity. Sure. I know. The majority or programmers don't need to write tools for the languages they use to develop. However, the ambiguous terminals make computer assisted (automated) code review more difficult. I don't like to fluff around with so very many different tools just to get a good handle on my C++ code. A large part of that need comes from the difficulty of parsing C++. I know this is the same criticism I had for the function syntax, but like I also said, I can't overstate how much I hate this.

Have you ever used a language built from a strict layout? Yes. It is easier to parse. No. I'm not going to complain about that. (Well, I'm going to complain about it anymore for now.) I know that people like the freedom to do what they want. I also know that programming languages having fixed form are far easier for humans to consume. They may not like the layout, but the layout is, by definition, always somewhat familiar. Have you ever worked on Ada source written to the USA military specification? It is glorious.

The language needs some of the facilities it has to play nicely with the standard packages it supports. I don't question that. I question the decision to couple some of it so strongly. The standard packages are fairly large, but they don't seem to do all that much, and they don't do much at all in isolation. This is problematic for a lot of new languages and displays some level of "We own this!" style of thinking to the world. A general purpose language needs a vast support system, but the other side of the argument wins. The vast support system belongs in a library not bound up tightly to the language. This interferes with "Not Invented Here" which, let's face it, is still largely the rule of the day. This bothers me because I can't separate the nature of my code within the language from what packages the language standard provides. It simply isn't a necessary evil for the majority of the facilities the language offers, yet I simply can not easily develop a package of my own that is as portable as it should be because everyone implementing the Go language (I'm assuming that it could be widely adopted here even though it probably will not be adopted by most.) may not waste time providing a lot of those packages preferring to ignore the bound facilities in favor or library only variations. That sadly means I would probably write my own library only facilities as many would.

Is every library, language, and system destined to get threading constructs wrong by default? I don't need to use high level constructs to implement my code if I also must use low level constructs to make the code work properly. AND I DON'T WANT TO USE LOW LEVEL CONSTRUCTS! Is it so much to ask for smart sharing of resource to be a thing? Really? I can't have a facility that distinguishes between an isolated copy, "TLS", and shared state without always writing it myself?

Soma