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.
Order by: Score:
Dirty?
by drstorm on Wed 11th Nov 2009 15:02 UTC
drstorm
Member since:
2009-04-24

I've read some docs on it and it seems very dirty to me. To elaborate, too many things are implicit and there are many built-in global functions (like len(), for example).

Having built-in functions reminds me of the days of Pascal.

Now, I said that too many things are implicit and here is an example of this: Any type, variable, constant of function of a package is public if and only if its name starts with an Uppercase letter.

Also, some things are not logical to me. For example:

import ("fmt", "os")

Why not just
import fmt, os


Functions can return more than one value (which is cool) like this:
func foo(i int) (a, b int) {}

A function that returns only one value looks like this:
func bar(i int) int {}

So, I ask, why do we need parentheses when returning more values? Why can't we just write this:
func foo(i int) a, b int {}


Now, I don't want to be all critical. There are some good aspects of the language and some interesting ideas. Those implicit things I mentioned have an up side as well. Once you know the language well, I guess you can write code very fast.
Also, the Go code compiles very fast. It's worth noting that it is a compiled language like C and yet it features many things from languages like Java, namely Garbage Collection and (I think) Reflection.

Oh, and by the way, the Go does not seem to be object-oriented (I am not sure.) and does not support exceptions...

Thanks for reading, and I would like to hear your comments of this. ;)

Reply Score: 7

RE: Dirty?
by oskar.h on Wed 11th Nov 2009 15:21 UTC in reply to "Dirty?"
oskar.h Member since:
2008-07-29

Dirty perhaps.. but the mascot is so cute!

Reply Score: 2

RE[2]: Dirty?
by Bryan on Wed 11th Nov 2009 19:27 UTC in reply to "RE: Dirty?"
Bryan Member since:
2005-07-11

Rob Pike and Ken Thompson, who are leading the project, worked together previously on Plan 9 at Bell Labs, which had a similar looking mascot:

http://en.wikipedia.org/wiki/Glenda,_the_Plan_9_Bunny

It wouldn't surprise me if this one was also drawn by Renee French (Pike's wife).

Edited 2009-11-11 19:28 UTC

Reply Score: 2

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 Score: 1

RE[2]: Dirty?
by drstorm on Wed 11th Nov 2009 16:08 UTC 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 Score: 2

RE[3]: Dirty?
by ndrw on Wed 11th Nov 2009 16:54 UTC 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 Score: 1

RE[4]: Dirty?
by drstorm on Wed 11th Nov 2009 22:19 UTC in reply to "RE[3]: Dirty?"
drstorm Member since:
2009-04-24

OK. That is Prototype-based programming which is a kind of OO, but I don't see how is that more object-oriented than Java. Is JavaScript more OO than Java?

Unlike Go, in Java everything is an object and although you could write a procedural Java code by putting everything in one static class, all those "static" keywords scream that you are doing it wrong.

In Go, however, you can write very C-like procedural programs without even knowing that you can make objects.

The point is, I still don't know how Go can be considered more OO. In fact I argue that it is, in fact, just the opposite.

Reply Score: 4

RE[5]: Dirty?
by google_ninja on Thu 12th Nov 2009 01:46 UTC in reply to "RE[4]: Dirty?"
google_ninja Member since:
2006-02-05

OO is (mostly) about leveraging polymorphism to create flexible code. Inheritance based polymorphism is probably the most tightly coupled and rigid form of polymorphism.

It's not something you really get until you fully implement something in a language that is not class oriented the way that most of the c++-ish systems languages are. Really grokking something like ruby or smalltalk will totally change the way you look at these things.

Also, dynamic dispatch + duck typing does not nessicarily mean prototypal. For example, ruby is a strongly typed language where objects can (and often do) vary from their type. In js, you can do
"".prototype.foo = new function() { .. }
that will add foo to all instances of string. in ruby, attaching a method to the string class is one option, another is to attach it to the instance, like

s = ""
def s.foo
..
end
s.foo # calls method
"".foo # method not found, only exists on s

Anyways, all that to say that while prototypal programming is one way to do this sort of thing, doesn't mean there aren't others.

Reply Score: 2

RE[5]: Dirty?
by ndrw on Thu 12th Nov 2009 03:33 UTC in reply to "RE[4]: Dirty?"
ndrw Member since:
2009-06-30

Java's OO semantics have deficiencies that Go solves. To me it is equivalent to "Go can be considered more OO".

It doesn't mean that Java is bad - it's actually my favorite system-level language. But that's mostly because of its robust frameworks and the fact I've learned to live with its limitations.

The Java OO deficiencies (those that matter to me) are:
- non-OO primitive types,
- no multi class inheritance (for a good reason - it can get messy very quickly),
- limited interfaces (the only way to implement an interface is to write it by hand or inherit it from a (single!) base class).

Go simply doesn't have these limitations.

I agree with you that one can write procedural programs in Go (and Java, C++,...). However, this doesn't make the language non-OO, it's just user's choice not to use these capabilities.

---
Sorry about my comments regarding the Go syntax issues. I just can't help thinking that even a bad syntax (which it isn't) is at worst a nuisance.

Reply Score: 1

RE[2]: Dirty?
by Tuishimi on Wed 11th Nov 2009 17:00 UTC 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 Score: 2

RE[3]: Dirty?
by Lennie on Wed 11th Nov 2009 20:08 UTC 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 Score: 2

RE[3]: Dirty?
by galvanash on Wed 11th Nov 2009 20:41 UTC 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 Score: 3

RE[4]: Dirty?
by drstorm on Wed 11th Nov 2009 22:25 UTC in reply to "RE[3]: Dirty?"
drstorm Member since:
2009-04-24

I agree that it's practical and it would go well with Python's block indentation, but if you add too much of these "shortcuts" to a language you can make it difficult and full of "gotchas".

Reply Score: 2

RE[3]: Dirty?
by Tuishimi on Thu 12th Nov 2009 06:05 UTC 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 Score: 2

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

It DOES have some nice features tho... channeling... etc.

Reply Score: 2

RE: Dirty?
by Almafeta on Wed 11th Nov 2009 17:14 UTC in reply to "Dirty?"
Almafeta Member since:
2007-02-22

I think the inconsistant syntax, however, will be massaged out once the language gets further from the experimental stage.

Reply Score: 2

RE: Dirty?
by mightshade on Wed 11th Nov 2009 17:27 UTC in reply to "Dirty?"
mightshade Member since:
2008-11-20

So, I ask, why do we need parentheses when returning more values? Why can't we just write this:
"func foo(i int) a, b int {}

"
I find that especially odd, since control structures (if, for, ...) do not use parentheses, and "Go needs fewer parentheses" is listed as an advantage of Go's formatting.
Of course, apart from that, Go might still be a nice language.

Reply Score: 1

RE: Dirty?
by frytvm on Wed 11th Nov 2009 22:45 UTC in reply to "Dirty?"
frytvm Member since:
2009-11-11


Functions can return more than one value (which is cool) like this:
"func foo(i int) (a, b int) {}

A function that returns only one value looks like this:
func bar(i int) int {}

So, I ask, why do we need parentheses when returning more values? Why can't we just write this:
func foo(i int) a, b int {}

"
I'm not sure if there are any technical reasons, but IMHO the parentheses make it more obvious that it's all part of the return type.


Oh, and by the way, the Go does not seem to be object-oriented (I am not sure.) and does not support exceptions...

Go is fairly object-oriented, although a little differently from c++/java (no type hierarchy). Still, it has methods, interfaces, and the like.

As far as exceptions, the FAQ http://golang.org/doc/go_lang_faq.html
suggests that the authors are leaving it as an "open issue" for now, so they might still enter in some form, I guess.

While the lack of exceptions and generics/templates (also an "open issue") make me a little worried, Go still seems like a nice improvement over C for most programs. I'm surprised they didn't make a bigger deal of Go's support for proper closures (at least according to the spec) and anonymous functions, though - making C++ functors is quite painful.

Reply Score: 1

...
by Hiev on Wed 11th Nov 2009 15:35 UTC
Hiev
Member since:
2005-09-27

I was excited at the moment I read the title, but after reading the specs and the tutorial, I didn't find it sexy.

Edited 2009-11-11 15:36 UTC

Reply Score: 5

Comment by Eddyspeeder
by Eddyspeeder on Wed 11th Nov 2009 15:36 UTC
Eddyspeeder
Member since:
2006-05-10

I think it's pretty impressive to devise a wholly new programming language intended to compete with the "major languages" of today. Its major benefit: being just two years old (project started in 2007), rather than twenty (or forty, with some regenerations). This should have the potential of being headline news.

It remains to be seen how this language finds its way into the programming world. I'm missing a book (open-source of course) that teaches starting developers how to go about their way with Go. Fortunately, at this point, their connection for existing developers (mainly C/C++) is really decent.

I'm downloading the TechTalk video just now, it ought to be an interesting watch on my way home.

Reply Score: 1

Another dead language
by moondevil on Wed 11th Nov 2009 15:45 UTC
moondevil
Member since:
2005-07-08

After reading the tutorial, I can say that it is already dead for me.

Compared with mainstream languages, and languages that are currently gaining momentum as well, Go doesn't have much to offer.

And several syntactic elements look real strange, as many people already noted on the forums.

I won't care about it.

Reply Score: 3

RE: Another dead language
by Tuishimi on Wed 11th Nov 2009 17:07 UTC in reply to "Another dead language"
Tuishimi Member since:
2005-07-06

Same here. I'd rather use Euphoria and/or groovy for pet projects. Heh. Actually I'd rather still be coding in VAX Ada and VAX BASIC. LOL!

Reply Score: 3

RE: Another dead language
by dagw on Thu 12th Nov 2009 13:10 UTC in reply to "Another dead language"
dagw Member since:
2005-07-06

If they manage to combine fast compiling with fast execution and the ability to do low level systems programming then they could be on to something. Not many other languages are working on that combination of features.

Reply Score: 2

Not sure
by sanctus on Wed 11th Nov 2009 15:45 UTC
sanctus
Member since:
2005-08-31

I like the idea

but, is this just jocaml with C syntax?

Reply Score: 2

Why the focus on fast compilation?
by flynn on Wed 11th Nov 2009 15:55 UTC
flynn
Member since:
2009-03-19

I think the designers of Go placed too much emphasis on fast compilation speeds. Apparently during early development they rejected a LLVM based solution because of slow compilation speed. Is compilation speed really that important? Maybe they should have gone the GHC route and provided a compiler and interpreter bundle. The GHC compiler can be a little sluggish sometimes, but the interpreter allows for quick iterative development by quickly catching all compile time errors when you load a source file. Leaving the slower, heavyweight compiler mainly for compiling optimized release builds rather then testing and debugging.

Reply Score: 1

Valhalla Member since:
2006-01-24

flynn wrote:
"I think the designers of Go placed too much emphasis on fast compilation speeds. Apparently during early development they rejected a LLVM based solution because of slow compilation speed. Is compilation speed really that important?"

This language was written to scratch Google developer's own itch, so compile times were obviously an important factor for them. I like seeing a new language aimed at system level programing, glancing at the syntax it looks like it's based on c. The language itself has some nice properties, like corout...(oops) goroutines with an outspoken aim of easing programming for concurrency, multithreading (which I guess will be it's biggest draw). Being targeted at system level programming performance will obviously be important and using automatic garbage collection is more expensive than manual, however great development has been made in the field of garbage collecting so it will be interesting to see what it performs like (anyone know what method they use?). Anyway, good to see a new non-managed language, I'll reserve further judgement until I've actually tried it and had a chance to see what the performance is like. Saying that it is 'near' c speed doesn't really say that much since 'near' can be VERY broadly defined as we've seen in the past.

Reply Score: 2

cb_osn Member since:
2006-02-26

Being targeted at system level programming performance will obviously be important and using automatic garbage collection is more expensive than manual, however great development has been made in the field of garbage collecting so it will be interesting to see what it performs like (anyone know what method they use?).

It's really debatable whether the cost of automatic garbage collection is more than that of manual memory management, especially as the size and complexity of the program grows. I used to be firmly in the manual camp, but these days, it seems to be better to let the machine keep track of your memory, especially if correctness is required.

That said, Go's garbage collector is (currently) based on a very primitive mark and sweep algorithm. It's basically a child's toy compared to the generational, iterative, compacting collectors found in the JVM and CLR.

Anyway, good to see a new non-managed language, I'll reserve further judgement until I've actually tried it and had a chance to see what the performance is like.

It's certainly interesting for language geeks, and I've spent too much time already digging through it because I like these things, but I don't see a new non-managed language truly having much use going forward. The ability to distribute a single binary that can run on (and be optimized for) x86, AMD64, PPC, MIPS, Arm, etc has too many advantages to ignore. And there is no denying that the potential for optimization in a JIT compiler far exceeds that of a static compiler-- even if we're not quite there yet.

Edited 2009-11-12 00:40 UTC

Reply Score: 3

cool, but the name sucks
by stanbr on Wed 11th Nov 2009 15:57 UTC
stanbr
Member since:
2009-05-22

The language is nice, but Go is not a good name... it's hard to google for it, and Go Programming Language would be GPL, and is not easy to google it too.

But I will check it out.

Reply Score: 5

RE: cool, but the name sucks
by Tuishimi on Wed 11th Nov 2009 17:01 UTC in reply to "cool, but the name sucks"
Tuishimi Member since:
2005-07-06

Wouldn't that be irony? It being hard to Google a Google language? ;)

Reply Score: 3

Why break conventions?
by Yamin on Wed 11th Nov 2009 16:21 UTC
Yamin
Member since:
2006-01-10

I will never understand languages that decide to break conventions. Maybe the 'new' way is marginally better, but is it worth mucking with the mind of developers who have to code in multiple languages.

var v2 string; // const std::string v2;
var v3 [10]int; // int v3[10];

oh jeez, let's put the type after the name to be opposite of C. I find myself working with java and C# and have to second guess myself every now and then where the array [] goes. In C# (int[] arr1; ). In java String s[]; Now we have another permutation on something rather irrelevant.

They kind of address this in the lang design faq, but not directly, and its more to do with multiple declarations on the same line.


On the good side, I like their native support for Go Routines (threads), Go Channel (Message passing), unit testing

Always good to see another language though. I'll see if their *quick* compile time really plays out. Knowing Google... it probably does.

Reply Score: 4

RE: Why break conventions?
by joshv on Wed 11th Nov 2009 17:34 UTC in reply to "Why break conventions?"
joshv Member since:
2006-03-18

In C# (int[] arr1; ). In java String s[]; Now we have another permutation on something rather irrelevant.


In java - String[] s; and String s[]; are equivalent - one of the few odd places in java where there are two ways of doing exactly the same thing.

Reply Score: 3

RE[2]: Why break conventions?
by Delgarde on Wed 11th Nov 2009 20:22 UTC in reply to "RE: Why break conventions?"
Delgarde Member since:
2008-08-19

"In C# (int[] arr1; ). In java String s[]; Now we have another permutation on something rather irrelevant.


In java - String[] s; and String s[]; are equivalent - one of the few odd places in java where there are two ways of doing exactly the same thing.
"

Right. Java convention prefers the former, since it arguably makes a lot more sense to keep the type information together. But the compiler accepts both syntaxes...

Reply Score: 2

RE[2]: Why break conventions?
by Yamin on Wed 11th Nov 2009 21:32 UTC in reply to "RE: Why break conventions?"
Yamin Member since:
2006-01-10

aaah, I stand enlightened ;)

I guess I don't need to be careful about that in Java. Might save me what is left of my brain cells.

Reply Score: 2

RE: Why break conventions?
by google_ninja on Thu 12th Nov 2009 01:50 UTC in reply to "Why break conventions?"
google_ninja Member since:
2006-02-05

Pretty sure there are a lot more languages out there where the type goes after the variable rather then before. works that way in c# 3.5+ too

var bar = new Foo()

Reply Score: 2

Comment by Anon9
by Anon9 on Wed 11th Nov 2009 17:30 UTC
Anon9
Member since:
2008-06-30

It seems to me like a cross between Smalltalk and C with better concurrency features.

[OT] I really have enjoyed working with the D programming language lately. D is a systems programming language that more similar to C++ than any other language, but IMO D is much nicer that C++. [/OT]

Reply Score: 3

Free open source labor
by WorknMan on Wed 11th Nov 2009 18:11 UTC
WorknMan
Member since:
2005-11-13

I love this:

At this point, Go isn't used in any user-facing Google service or application, since it still has to mature, which is where external programmers come into the picture. "We need better libraries and tools, and the open-source community is great at helping you with things like that," Pike said.


In other words, "We desire for the open source community to write free sh*t for us." I don't write open source software for a living, but if I did, I'd be sort of offended by this. Here's a novel idea... if they need more coders/testers, why don't they hire some, instead of expecting the open source crowd to do it for $0?

Of course, I realize that not everybody is in it for the money, but if you're going to write/test code for a for-profit company, you should expect to be paid for it, IMHO.

Reply Score: 6

RE: Free open source labor
by sbergman27 on Wed 11th Nov 2009 19:49 UTC in reply to "Free open source labor"
sbergman27 Member since:
2005-07-24

I don't write open source software for a living, but if I did, I'd be sort of offended by this.
...
Of course, I realize that not everybody is in it for the money, but if you're going to write/test code for a for-profit company, you should expect to be paid for it, IMHO.

Developers would not be writing and testing for a for-profit company. They would be writing and testing for an open-source project which they and others presumably find useful. "Others" being Inclusive of Google, of course, which did the major grunt work to get the project this far, and released into the OSS community.

I'm not a current Go developer at Google, but if I were, I'd be offended by your ingrateful post.

Edited 2009-11-11 19:50 UTC

Reply Score: 3

They have $22 billion in cash
by nt_jerkface on Thu 12th Nov 2009 16:51 UTC in reply to "RE: Free open source labor"
nt_jerkface Member since:
2009-08-26

Previous poster is right, Google is ran by cheapskates.

If they want some more libraries then they should hire some more developers.

Reply Score: 2

RE: They have $22 billion in cash
by sbergman27 on Thu 12th Nov 2009 17:00 UTC in reply to "They have $22 billion in cash"
sbergman27 Member since:
2005-07-24

If you don't want to contribute, don't contribute. Simple as that. Though neither of you seem like the sort of people who contribute code to OSS projects, anyway. Am I right?

As the score stands now regarding this project, it's Google and its paid employees which have done all the contributing.

Edited 2009-11-12 17:01 UTC

Reply Score: 2

wish..
by ahmetaa on Wed 11th Nov 2009 18:35 UTC
ahmetaa
Member since:
2005-07-06

i think problem with Go is that it is initially designed by two old (maybe long bearded) respectable unix guys. But because of their mind set Syntax seems cryptic and somewhat too low level - alien. i wish they got two higher level masters from Google into their group (Rossum and Bloch). I also wish Google came up with next generation Java instead..

Reply Score: 3

Google TechTalk on Go language
by bannor99 on Wed 11th Nov 2009 18:37 UTC
bannor99
Member since:
2005-09-15

Rob Pike give a 1hr talk on Go on Oct 30.

http://www.youtube.com/watch?v=rKnDgT73v8s

Reply Score: 1

RE: Google TechTalk on Go language
by Lennie on Wed 11th Nov 2009 20:20 UTC in reply to "Google TechTalk on Go language"
Lennie Member since:
2007-09-22

What also bothers is me is, Rob Pike doesn't have any facial hair. Ken Thompson has, so I guess it's ok.

Reply Score: 5

Another Go Language??
by systyrant on Wed 11th Nov 2009 19:46 UTC
systyrant
Member since:
2007-01-18

Google isn't the first to call a programming language Go.

Here's a link to the other Go's book.

http://www.lulu.com/content/paperback-book/lets-go/641689

Reply Score: 2

RE: Another Go Language??
by fretinator on Wed 11th Nov 2009 19:54 UTC in reply to "Another Go Language??"
fretinator Member since:
2005-07-06

From Wikipedia:
---------------------------------------------------------
It should be noted some issues with google's choice of name "Go" is in conflict with that of a previously released programming language called "Go!" by F. G. McCabe and K. L. Clark in 2004. The naming issue is discussed on Google's Go page, with current popular consensus that it should be renamed as "Issue 9"
---------------------------------------------------------

I assume "Issue 9" is a loose reference to Plan9.

Reply Score: 3

RE[2]: Another Go Language??
by steve_s on Wed 11th Nov 2009 20:44 UTC in reply to "RE: Another Go Language??"
steve_s Member since:
2006-01-16

I assume "Issue 9" is a loose reference to Plan9.


Loose reference yes. Also a direct reference to the fact that the name conflict is issue 9 in the google code issue tracker for the go language project:
http://code.google.com/p/go/issues/detail?id=9

Reply Score: 2

Interesting
by agnus on Wed 11th Nov 2009 20:02 UTC
agnus
Member since:
2006-05-10

I really like their approach on polymorphism and concurrency!

It looks, to me, like a mix of Objective-C and Java. I had wished for something like this would be supported by Java as I mostly prefer composition to sub-classing. Even James Gosling seems to agree:

http://www.artima.com/intv/gosling34.html
http://www.artima.com/intv/gosling13.html

Reply Score: 1

Meh.... :)
by obsidian on Wed 11th Nov 2009 20:58 UTC
obsidian
Member since:
2007-05-12

The syntax reminds me a lot of the "D" programming language. I'd probably prefer to use D though, given that it has goodies like lazy evaluation.

Reply Score: 2

RE: Meh.... :)
by moondevil on Wed 11th Nov 2009 21:33 UTC in reply to "Meh.... :) "
moondevil Member since:
2005-07-08

I also find D quite nice, but not sure if it will ever gain traction.

Still waiting on D 2.0 to come out. And out is all about the low level calls when you need to use D on Windows?

Reply Score: 1

I would love this if it had generics
by Zifre on Wed 11th Nov 2009 22:56 UTC
Zifre
Member since:
2009-10-04

Some aspects of this language seem really nice, especially the concurrency support and speed. I don't particularly like the syntax, but it's alright. However, one feature I really can't live without is generics. If they added generics I'd probably start using it right now for all my projects.

Reply Score: 1

Looks really cool
by google_ninja on Thu 12th Nov 2009 01:57 UTC
google_ninja
Member since:
2006-02-05

I find coding in languages without dynamic dispatch and type inference nowadays feels like working with a chisel on stone when you are used to a paintbrush on canvas. It is fantastic to see someone (other then scala) bring this to a systems language, and the fact that it is unmanaged makes it downright unique. Also, compiling 120k lines of code in 8 seconds, and 1k lines in 20 milliseconds is downright delightful. Compiled languages tend to be horribly unproductive when working through the refactor/compile/test cycle compared to languages that take out the middle step.


They are pretty far from prime time still (standard library seems rather anemic), but I think this is one of the most interesting new languages I have seen in a very long time. If they are able to match c performance with those kinds of features, all the current systems languages will have going for them is the mountains of existing code already written in them.

Reply Score: 2

Useless without a platform
by iliks on Thu 12th Nov 2009 13:45 UTC
iliks
Member since:
2008-07-08

The real problem with low-level programming is libraries that allow performing useful stuff, not how many parentheses and where you write declaring array variables.

E.g. Fortran is still used in numerical computations because there are vast libraries of already developed code, going back to 1960's.

Fast compilation? Hmmm. Why would I need fast compilation when the language itself has weak library (I've had a look at it, it is quite patchy) and this won't allow me to easily 'say' what I want to say solving concrete low-level programming problem?

Edited 2009-11-12 13:50 UTC

Reply Score: 1

Useless without a platform
by iliks on Thu 12th Nov 2009 14:00 UTC
iliks
Member since:
2008-07-08

The real problem with low-level programming is libraries that allow performing useful stuff, not how many parentheses and where you write declaring array variables.

E.g. Fortran is still used in numerical computations because there are vast libraries of already developed code, going back to 1960's.

Fast compilation? Hmmm. Why would I need fast compilation when the language itself has weak library (I've had a look at it, it is quite patchy) and this won't allow me to easily 'say' what I want to say using concrete low-level programming problem?

Edited 2009-11-12 14:03 UTC

Reply Score: 1

Limbo
by ziba on Fri 13th Nov 2009 01:40 UTC
ziba
Member since:
2009-11-13

It looks like a remake of the Limbo programming language (part of the Inferno operating system ;)

It was also conceived by Kernighan, Ritchie & Pike while they were at Bell Labs...

http://en.wikipedia.org/wiki/Limbo_%28programming_language%...
http://www.vitanuova.com/inferno/limbo.html

Reply Score: 1

FealDorf
Member since:
2008-01-07

semi-C syntax + concurrency - delegation/inheritance
0. The whole "type after variable" feels very weird in this as compared to other languages which do the same.

1. No inheritance or delegation..
It seems to have the Dylan (and CLisp) style of decoupling the class from the methods; but I really find the method syntax confusing.

func (this Class) method(arg1 Arg1, arg2 Arg2) Ret {}

It looks clean but I keep getting mixed up on lot of occassions. The new C++0x syntax on the other hand:

[] Class::method(Arg1 arg1, Arg2 arg2) -> Ret {}

While more senile, I actually find it easier to read.

2. The mechanism for maps was very awkward to me.

Although I don't think it offers anything new. Also I don't quite get how it can have C++ like speeds..

Reply Score: 1

vivainio Member since:
2008-12-26

Alhough I don't think it offers anything new. Also I don't quite get how it can have C++ like speeds..


The interface stuff is completely new, I think. It's also insanely cool - static duck typing without the template complexity :-).

Edited 2009-11-13 11:17 UTC

Reply Score: 2

FealDorf Member since:
2008-01-07

I had thought about it.. It's (probably) not like templates.
The deal is; first I thought it was the (removed) C++0x Concepts i.e., interfaces for templates -- which is *exactly* the same as this (cept for the extra syntax).

But if it's like implicit C++ concepts, then every time you pass an object of a different class it would compile a new function meant specifically for that class. Considering how there's no inheritance, that would seriously increase the executable file size..

The alternative is that it's similar to pure-virtual classes, which wouldn't give it C++-template like speeds..

Reply Score: 1

vivainio Member since:
2008-12-26

But if it's like implicit C++ concepts, then every time you pass an object of a different class it would compile a new function meant specifically for that class. Considering how there's no inheritance, that would seriously increase the executable file size..


I trust they have something clever cooked up for this. It may also be that google doesn't care about the size that much.

It's also very possible to use polymorphic vtables for this. Just create a different per-class vtable for every interface the class implements.

Instead of speculating I'd rather just wait for someone to explain what exactly they are doing ;-).

Reply Score: 2

vivainio Member since:
2008-12-26


It's also very possible to use polymorphic vtables for this. Just create a different per-class vtable for every interface the class implements.

Instead of speculating I'd rather just wait for someone to explain what exactly they are doing ;-).


http://www.reddit.com/r/programming/comments/a3hku/mark_c_chucarrol...

Reply Score: 2

FealDorf Member since:
2008-01-07

Ah, that's *exactly* what I was trying to say earlier but I wasn't sure if I had the right words... Nevertheless, that means it is as efficient as "virtual C++".

Which would also explain the benchmarks:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=g...

Reply Score: 1

vivainio Member since:
2008-12-26



There is no point wasting too much time on benchmark comparisons right now, esp. for the "6g" compiler which doesn't optimize seriously yet.

Go by no means forces you to use interfaces, direct method calls don't go through the interface jump table.

Reply Score: 2

FealDorf Member since:
2008-01-07

No, but it sure gives one a rough estimate of how 'fast' a language because I don't think optimizations can contribute to a great change in it, especially because it's not like Java or C# which has a complex type system or so, but then I'm not so knowledgeable in this area.
Also, interfaces are not used in that submitted code (which is by the Go creators)..

I'm just sceptical about the "as fast as C" claims when the languages are of much higher-level. And Go is sufficiently high level. After optimizations I expect it to optimistically meet the speeds of C# Mono implementation but not too much more than that..

Edited 2009-11-14 15:37 UTC

Reply Score: 1

sad and stupid
by RRepster on Mon 16th Nov 2009 02:07 UTC
RRepster
Member since:
2008-06-18

just the very idea that we need to "open source" a programming language shows how stupid the whole IP/copyright/patent issue has become.

Reply Score: 1