has anyone tried Go?

I've been playing with Google's Go language a little bit recently, and I'm really beginning to enjoy writing Go code. one of the things I like most about it is its built-in multiprocessing and concurrency features. communication channels are built into the language and runtime, so concurrent threads (goroutines) can talk to each other in a well-defined way, without needing a lot of extra boilerplate code. any function may be spawned to run asynchronously with the "go" keyword, including functions defined inline (lambdas/anonymous delegates). the basic package collection is quite extensive as well, in much the same way that the java and .Net frameworks include modules for common tasks like network communication, cryptography, and regular expressions.

I'm not saying that it's a replacement for any other language(s), but I definitely think it has a lot to offer.

any opinions on this language?

O_o

I think they really screwed up.

Don't get me wrong; the language isn't bad. They just borrowed so heavily from other languages they repeated a lot of the same mistakes. It reminds me a lot of C# and D in that regard. They could have made a clean break from that style of programming language and in the process may have avoided a lot of old problems.

*shrug*

As it is, I feel that it is just another internet language; exactly that and nothing more.

Soma

Quote:

---

Originally Posted by phantomotap

O_o

I think they really screwed up.

Don't get me wrong; the language isn't bad. They just borrowed so heavily from other languages they repeated a lot of the same mistakes. It reminds me a lot of C# and D in that regard. They could have made a clean break from that style of programming language and in the process may have avoided a lot of old problems.

*shrug*

As it is, I feel that it is just another internet language; exactly that and nothing more.

Soma

---

Fair enough. Just for the sake of argument, what kind of new language would blow your socks off? Basic features, things it avoids, etc.

I honestly wonder where we go now, and how much benefit it provides. You could always make a language that it is a little more optimal, but the existing languages that have already carved out their place could do that too. Seems like a new language is only worth its while if it is some paradigm-shattering game changer. Even then, could such a thing exist and have practical utility--not simply being an academic plaything?

To my eye, the the next uncharted territory is the developing quantum computing, and however that kind of programming will look, and relate to our current computing technology. I really don't know if today's familiar architecture has room for another language revolution.

Quote:

---

Just for the sake of argument, what kind of new language would blow your socks off?

---

One that didn't repeat so many of the mistakes of the past while still offering native support for "OOP", "functional", "set", and other common programming forms and not getting in my bloody way.

The problem with many languages is that they were based so heavily on C++ that the same mistakes were made making them of limited interest in comparison with C++ where C++ also fits. Looking at the real world, the D programming language is often forwarded as a "better" C++ because it isn't as ugly; the problem is that D is only a different flavor of ugly. That doesn't make D a bad language; it just happens that the vast majority of complaints thrown at C++ apply equally well to D making D far less interesting than it might have been.

A lot of languages based on C++ are too devoted to a particular facility. Looking at the real world again, the Java languages "Oh. My. God. OOP! Exceptions!" approach forces a lot of design decision on a program that rightly belongs with the programmer. Forcing the programmer to jump through hoops to use the language isn't really that big of a deal. It doesn't make Java a bad language; it just happens that a lot of developers want to design programs for a purpose without the language getting in the way.

The languages that weren't based so heavily on C++ tend to have far fewer features. Looking at the real world yet again, the C# language is slowly adding C++ features that it didn't have from the start. That's a shame. C# is limited to ".Net" areas (including "Mono") while having only a few features C++ doesn't have and removing a lot of features C++ does have. That doesn't make C# a bad language; it just happens that C# is incapable of expressing a lot of the code C++ programmers like me write.

Soma

can you elaborate on what parts of go you didn't like? what mistakes did they repeat, specifically?

*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

many of your points hit the nail right on the head. especially with regard to threading. in go, you have no control over whether a goroutine spawns in a hardware thread or not, nor do you have any way to determine whether or not it did.

I do wish that the google standard compiler collection supported dynamic linking, in addition to static. I think it would probably help to alleviate some of the concern you express in your second to last paragraph.

strict layout is for the benefit humans. there's no reason why a compiler should need code to be organized in a specific way. there is also nothing to stop you or a business entity from enforcing a layout.

I'm not sure I understand what you mean by "ambiguous terminals." care to elaborate on that one?

Quote:

---

in go, you have no control over whether a goroutine spawns in a hardware thread or not, nor do you have any way to determine whether or not it did.

---

I think patches have fixed part of this; I just don't know why the option wasn't available from the start. I can see what they were targeting, but the lack of control so related is an obvious oversight.

Quote:

---

there's no reason why a compiler should need code to be organized in a specific way.

---

^_^

Well, at no point did you say "I'm only interested in the bits you didn't like that affect the compiler.".

*shrug*

I know that other tools can be written to enforce a particular style. They've even been written for C++. However, this sort of thing exists beyond a fixed standard which invariably means multiple variations will be developed. I have to, again, refer you to the excellent Ada code base that follows the USA military standard. Sure, in this case the standard was developed by a separate entity which is exactly what you are saying; (I'm not arguing the pint.) I'm only saying that a fixed standard would be beneficial to all those developers who might move between code bases... so essentially everyone programming in the language.

Quote:

---

care to elaborate on that one?

---

I can explain to a point without going into parser theory.

Any parser written for the "Go" programming language will have multiple stages. These stages may be built to form a stream, multiple machines, or combined into a single functional layer. One of these stages will process the character stream (source code) into a series of tokens. To parse "Go" these tokens are going to have to be tagged with some form of semantic information at some point in some fashion so that some stage can decide the true type of token because the grammar offers possibilities that leave the type of token ambiguous without that extra context.

It muddies the waters of parsing the language with "fixups" that exist beyond the grammar. I doubt, but I admit I haven't looked into it enough to know for sure, that the language specification doesn't cover all of these possible "fixup" needs.

Soma

The creators of Go state right up front, that they wanted their language to be like C++ in many ways. They felt it had to be that way, or it would never get a critical mass of users to keep it going, and pass straight from creation into obscurity.

Accepting the above precept, a lot of Soma's criticisms, become moot points.

I haven't spent much time with Go, but any language that can accomplish as much as Go has, in such a short space of time, is very exciting, imo. 10 times faster compile times with 85% of the run-times of C++, with full garbage collection, go routines, etc. ? That's a great start, and unlike C++, they've kept a lot of the complexity OUT of the language, (so far), while allowing some OOP concepts, into the language.

I look forward to spending more time with it.

Quote:

---

Accepting the above precept, a lot of Soma's criticisms, become moot points.

---

No. That's just stupid. Saying "We built the language on a foundation of the flaws inherent to C++ on purpose." does not eliminate my criticisms; that is what gives my criticisms such great weight.

They knew, as many other newer languages have known, that those design decisions were mistakes. That they made them knowing they were mistakes doesn't give them a pass; that only makes the decisions worse.

Soma

Please stop misquoting what I posted.

I never wrote:
"We built the language on a foundation of the flaws inherent to C++ on purpose."

That's your own fantasy.

The creators of Go wanted their language to look similar in it's format (which is much more rigid), and to have several similar operators, as well. A Go program looks somewhat similar to C++, but Go is NOT like C++, in many ways.

From the absolute POV you have, yes, Go is imperfect. From their relative POV, Go is a big improvement over C++. Ultimately, it's another tool that will undoubtedly be used for certain types of programming work, and will be unsuitable for others. I don't believe it's going to replace C++, even though C++ has become a bit of a horror show.

Quote:

---

Please stop misquoting what I posted.

---

I didn't quote you at all.

Quote:

---

From the absolute POV you have, yes, Go is imperfect. From their relative POV, Go is a big improvement over C++.

---

You say "the creators of Go wanted their language to look similar in it's format"? No! You must be joking!? It couldn't be that some of the exact problems I pointed out exist precisely because the developers borrowed too heavily from C++? Oh, wait; that is exactly what my post points out.

Repeating the intent from my post as an excuse to those problems sounds really ........ing stupid.

No. Let me tell you what happened here.

You got your knickers in a twist because you like "Go" and tried to soften my criticisms with stupidity because you could not offer any counter points.

So, I'm done with your stupidity; I'm going to give you the benefit of doubt and assume you were blinded into this stupidity by your love of "Go".

So, you say have some wonderful experience with "Go". I will not darken this thread with my own good self any further, but if you have any opinions that aren't regurgitated marketing blurb, let's here them.

Soma

I think you both need to calm down a bit. I didn't start this thread to start a fight.

I think soma has some very valid points, which shouldn't be summarily dismissed, simply because "go isn't C++." on the other hand, the fact still remains that go is not C++, and the intent was not to create a great language, or even a language that fixes the mistakes of the past, but rather to create a useful language, in which it is easy to develop concurrent software quickly. I believe that they have achieved this, at least in part. the lanugage-integrated go routines and intra-process communication channels make concurrency simple and straightforward. is it perfect? no. is it useful? that's a matter of opinion, but personally, I am finding new uses for it nearly every day.

I don't see any need to start a holy war over computer languages. every language has its purpose, and its place (except VB.Net... that's just a turd that won't flush ;) ).