Linked by Thom Holwerda on Wed 11th Nov 2009 14:21 UTC
Google Google has invented a new programming language designed to reduce the complexity of coding without compromising the performance of applications. Called Go, the language has been tested internally at Google but is still at an experimental stage, so the company is releasing it as open-source code in the hope that it will get help with its future development.
Thread beginning with comment 394016
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Dirty?
by ndrw on Wed 11th Nov 2009 16:03 UTC in reply to "Dirty?"
ndrw
Member since:
2009-06-30

All issues (?) you've pointed out are just your personal preferences regarding the syntax. Is it really that important whether the import statement uses parentheses or not? To me any reasonably readable, regular and compact syntax will do, as long as the language has semantics and libraries I need.

The language is OO (more than C++ or Java for that matter), has very flexible type system and built-in concurrency primitives. Feature set is pretty conservative but it feels right for system-level programming.

Whether it is enough - hard to say. To promote a new system level language Google needs more than just a compiler, debugger and a basic class library. For start they should make Go a core part of their frameworks, just like what Sun or Microsoft did with Java or .Net.

I'm also a bit concerned about the binary compatibility, this issue should be dealt with asap or Go may end up going C++ route, where each compiler/architecture uses different calling conventions, symbol names mangling etc.

Reply Parent Score: 1

RE[2]: Dirty?
by drstorm on Wed 11th Nov 2009 16:08 in reply to "RE: Dirty?"
drstorm Member since:
2009-04-24

The language is OO (more than C++ or Java for that matter)

Please do elaborate (especially about Go being more OO than Java).

Reply Parent Score: 2

RE[3]: Dirty?
by ndrw on Wed 11th Nov 2009 16:54 in reply to "RE[2]: Dirty?"
ndrw Member since:
2009-06-30

It uses interfaces to describe capabilities (i.e. duck typing), not a rigid class hierarchy. With no restrictions on what you can attach methods to, it is much more flexible and simpler mechanism than subclassing. "Subclassing" is still available through type embedding, btw. Whenever you embed other types, you automatically "inherit" their interfaces and implementations (of course, you can redefine some of their methods if you choose so).

Reply Parent Score: 1

RE[2]: Dirty?
by Tuishimi on Wed 11th Nov 2009 17:00 in reply to "RE: Dirty?"
Tuishimi Member since:
2005-07-06

I think his points are valid (regarding parens). They are not needed at their position for return variables. They come between ")" and "{"... the parser should not require the parens for a list of return vars.

It IS just opinion, but still, it seems like an extraneous thing that was unnecessary.

Built-in functions are fine with me... languages like Euphoria simply auto-include certain files that include oft-used functions. Same with Python, etc.

The bit about making a var/type public simply by capitalizing the first letter ... that just doesn't seem like a good idea.

But again, you are right, that is a matter of taste, I suppose. Like how some people get riled up about Python's indentation rules.

Reply Parent Score: 2

RE[3]: Dirty?
by Lennie on Wed 11th Nov 2009 20:08 in reply to "RE[2]: Dirty?"
Lennie Member since:
2007-09-22

"The bit about making a var/type public simply by capitalizing the first letter ... that just doesn't seem like a good idea."

I think I can hear someone in China sigh.

Reply Parent Score: 2

RE[3]: Dirty?
by galvanash on Wed 11th Nov 2009 20:41 in reply to "RE[2]: Dirty?"
galvanash Member since:
2006-01-25

The bit about making a var/type public simply by capitalizing the first letter ... that just doesn't seem like a good idea.


I personally think it is a wonderful idea. It may be somewhat arbitrary and it wont be obvious to new users because the concept is somewhat unique, but what it DOES do is create a reason for differentiating starting case on your symbol names, and even better it has consequences.

Almost all languages have conventions for this, but none of them have a reason for it - it is simply convention. Convention without concrete purpose results in coding errors because people start to assume things due expectations based on convention.

For example, in many languages the convention is all uppercase variables are constants. But there is no consequence for not adhering to this (other than it will confuse the crap out of other people).

In go, a variable starting with an upper case character is publicly scoped - that isn't a convention, it is a RESULT of making the starting character upper case.

Reply Parent Score: 3

RE[3]: Dirty?
by Tuishimi on Thu 12th Nov 2009 06:05 in reply to "RE[2]: Dirty?"
Tuishimi Member since:
2005-07-06

Here is an example of where the parens are missing in a list of operations (for-loop and if syntax)...

19 func main() {
20 flag.Parse(); // Scans the arg list and sets up flags
21 var s string = "";
22 for i := 0; i < flag.NArg(); i++ {
23 if i > 0 {
24 s += Space
25 }
26 s += flag.Arg(i)
27 }
28 if !*omitNewline {
29 s += Newline
30 }
31 os.Stdout.WriteString(s);
32 }

At first glance it all seems willy-nilly.

Reply Parent Score: 2