I just feel that it is yet another language. Nothing really special about it except that it is new and is far from mature. We'll have to see.

Having spent the day wrestling with some tricky BGP parsing in regular old C, and then having spent part of the trip home thinking about what a new systems language that combined the speed and simplicity of C with proper memory management, built-in concurrency support etc. would look like, I read through the Go materials with a good bit of interest. First impressions:

• I really like multiple return values. You can do that in Perl, sort of, by returning a list.
• The concurrency model is interesting. I've thought for a long time that this was something that really needed to be built into a language, and Go does it at a basic syntactical level.
• I don't see anything in the way of built-in containers, other than statically-allocated arrays.
• I like the rethinking of things like for loops, switches and printf(). Too many languages (I'm looking at you, Java and Perl) simply copy these verbatim from C.
• Interesting that they took Java's concept of interfaces and divorced it from any kind of type hierarchy.

There's a lot of work yet to be done, but it's among the better candidates for Next Big Thing that I've seen in recent years.

The gopher is probably the best programming language mascot ever.

I think the compilation speed is more important that people realize. I don't think it's "yet another programming language." I think it might be a big deal.

I watched the hour long video: http://www.youtube.com/watch?v=rKnDgT73v8s. Before that, I was skeptical.

YACL

Yet another C Language. Yet another for syntax. What's the contribution again?

Oh and he broke the cardinal rule of C languages:

If you want your new C-syntax language to succeed, run far far away from any syntax that uses :=

(I am making no judgement on the usefulness of :=. I am simply stating a fact that every adaptation of the C language that has used that syntax has failed to catch on in popularity. See A Modest Proposal: C++ Resyntaxed ^[1].)

I've only watched the talk ^[1], read the FAQ ^[2] and skimmed some other stuff on the website ^[3]; not actually tried it. But here's my take.

Pro:

• Strict typing; no implicit conversions. This will catch many more errors at compile time, and is a huge selling point in my book.
• No need for explicit types on variable declarations (i.e. automatic type inference, like var in C# 3.0).
• Interfaces with support for "multiple inheritance", reminiscent of Haskell type classes and ex-C++0x concepts.
• Method declarations separate from the types they operate on, so extension methods (also on interfaces) are trivially possible.
• Garbage collected.
• Fairly clean and seemingly quite consistent syntax.
• Closures.
• Easy to use, lightweight concurrency constructs (channels, goroutines and the select construct).
• Fast! Fast compiling and fast code.
• Decent Unicode support.
• Some slightly ugly but really practical idioms (see Effective Go ^[4]), such as iota and the improved switch.
• Comes from Google. Even if that doesn't say anything about the quality of the language itself, that fact still gives it momentum and publicity. That is something an open source project badly needs.
• BSD licensed, no pesky GPL. Also good for momentum.

Con:

• Lack of functional constructs like map and filter. Everything feels very imperative still. Python does a much better job here. But with the things present in the language, these constructs could be implemented as a library (i.e. not requiring syntactical support).
• No generics (yet). The interface system partly makes up for it, but I think Go could really benefit from a generics system similar to Haskell's.
• No overloading. We see in Haskell (liftM, liftM2, liftM3...) that this can be a pain.
• Unlike variables, there's no type inference for methods and functions.
• Not a very clean syntax (e.g. like Python). Feels like C with less braces.
• No mutually recursive imports.
• Simple-minded garbage collector. But that's being worked on.
• Interfaces can be implemented implicitly. You just define all the methods needed. That seems convenient at first sight. But if you rename a method without knowing that it was needed to implement some interface... boom. (Same problem as with duck typing, but less so, because errors are detected at compile time.)

Bottom line: I think Go is an interesting development. There are few languages that offer such a rich feature set but still compile directly to machine code. There are no ground-breaking new developments, but Go does bring together some concepts that haven't been brought together before. I'm curious to see how the language will fare in practice.

A type-safe language with concurrency support, garbage-collection, a succinct C-like syntax and compiles 120,000 lines of code in about 8 seconds on a Mac laptop. The C/C++ edit-compile-link cycle has essentially been "eliminated".

Let's throw in that it was designed by a couple of famous former Bell Lab guys for a little buzz.

Hmmmm....I'd say we have a winner.

One problem I have with Go is that they speak of it as a "system" language. In my mind, a system language is something you write kernels or real-time stuff with, and mandatory non-deterministic garbage collection rules out Go for most such tasks. Then it turns out that by "system language" they really mean "server applications". Sure, Go looks fine for that purpose, but not many people consider it system programming.

Links:

Ars-Technica ^[1]

PC World ^[2]

Google Open Source Blog ^[3]

Tech Talk Video ^[4]

Go with Google - Yet Another Language! ^[5]

Getting started with Google's Go ^[6]

First thought: wow, D done right! Proper mix of Python and C.

After watching the TechTalk ^[1]:

• Syntax is a bit ugly (could be prettier)
  • Don't like := syntax
  • You still need for i = 0; i < 10; i++?? seriously?
  • Too many braces, stars, ampersands.
• The interface thing is brilliant! Can't wait to use it.
• The channel concept is interesting, not sure what to think about it though.

I have just seen the introductory video ^[1]

This I what I liked ( from what I understood )

• Braces are used ALWAYS ^[2]!

  I have always had problems with that in production code. It may be considered as an small improvement, but once, I spend >3 hrs. debugging an error caused by a misplaced if. It is a nightmare.

wrong

  if x > 0  
       return 0;

or

  if x > 0 return 0;

right

  if  x > 0   { 
      return 0;
   }

or

  if x > 0   { return 0; }

always!!

• Visibility upper case for "public" stuff ^[3].

Visible outside the package:

func Print(v ...) { 
}

Not visible outside the package

func print( v ... ) {
}

Yes, it may be an small improvement in the code syntax too, yet, important and a easy way to create public methods/attributes etc. and finish with a lot of discussions.

• Interface ^[4] you can plugin "anything" that accomplish the interface ( like in duck type if it says quack is a duck ) and yet have compile time checking for safety.

So the interface declare the quack method

type Quack interface {
    DoQuack()
}

And then we can may create a function using that type:

func callIt( duck Quack ) {
    duck.DoQuack()
}

To use it we only need "something" that respond to the message, for instance, a Duck and a Person they perform the function DoQuack diferently

type Duck struct {
    count int
}


func( d* Duck ) DoQuack() {
    d.count++
    for i:= 0; i < d.count ; i++ {
        fmt.Print("quack!" )
    }
    fmt.Print("\n")
}

type Person struct {}

func ( o* Person ) DoQuack() {
    fmt.Printf("Ehem, I'll try it... quack?\n")
}

Finally the check if the "struct" complies with the interface is performed by the compiler when the type is used:

func main() {
    var quack Quack
    quack = &Duck{} 
    callIt( quack )
    callIt( quack )
    callIt( quack )
    quack = &Person{}
    callIt( quack )    
}

prints:

quack!
quack!quack!
quack!quack!quack!
Ehem, I'll try it... quack?

• Syntax

Something I didn't quite like is the syntax ... :-S I don't know how to explain it, but at this point ( 2009 ) programming languages should just flow. Go syntax, makes me stop and think twice what each line is. Probably that's just matter of getting use to it.

There are plenty of features, like the channels and the goroutines ( similar to threads ) that look pretty cool, but I think It would take me some more time to grasp them.

Finally from a sample from the install page:

http://golang.org/doc/install.html

I can see that: real programmers use cat ^[5]!!!

$ cat >hello.go <<EOF
package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}
EOF
$ 6g hello.go
$ 6l hello.6
$ ./6.out
hello, world

Nice

Hey - this looks like a real smasher!

… concurrent

Go promotes writing systems and servers as sets of lightweight communicating processes, called goroutines, with strong support from the language. Run thousands of goroutines if you want—and say good-bye to stack overflows.

[ Go website ^[1]]

Could Go really be the end of this wonderful experience? I will miss S.O.! SO MUCH!

Go is to C as Google Wave is to Email.

That means, "Go" and "Wave" are both Google's answer to "what would X be like if it were invented today?" (X = system progamming language or email)

When they say Go is for "system programming", I see Go as the best language thus far for software that runs in userspace but does not directly interface to users. That is daemons like httpd, udev, d-bus, upstart etc would be most conveniently written in Go. Classic unix command-line tools would also be easier to write in Go, except they've already been done in C and don't need the concurrency. Notice that Go is not for scripting nor GUIs, and in the interest of portability there is no way to add assembly code for writing a kernel, and you don't want garbage collection in a kernel language anyway.

Also, Go is designed for concurrent programming on a multiprocessor system - so its not meant for your old mobile phone but your desktops and servers. The "hello world" binaries at around 600KiB is oversized for embedded work, and garbage collection won't do in low-memory environments. But we may see it on mobile computing devices like Android phones.

No one has mentioned yet: Go has already a huge amount of libraries ^[1]! Including XML parser, unicode support, zip compression, json, regexp, bignum, etc. And for everything else you can link your external C code. It looks like it would be easy to start big Go projects right away.

• The lack of type hierarchy ("static duck typing") is rather brilliant, I think. Why didn't anybody think of that sooner? EDIT: Why didn't I know about this sooner? (Thanks, @Nemanja)

• The channel concept looks really cool and will make lots of hard things easy.

• Garbage collection, given their claim of 10%-20% penalty, is a hugely worth it. So much uninteresting C/C++ code is juggling references, and paradigms with GC can be so much cleaner.

• Some of the syntax will take some getting used to. Confused by &'s and *'s right now.

• Reversing the order of names and types in declarations (vs C) is the right thing to do and took some guts.

EDIT: One more point. Having now played with it for a bit, I'm disappointed you can't define methods on classes outside the local package. E.g. this doesn't work:

func (v int) square() int {
  return v * v;
}
two := 2;
four := two.square();

(Probably, some people are glad of that, and would be even if my example were more sensible.)

To add methods, you have to "alias" the type and name it explicitly:

type Number int
func (v Number) square() Number {
  return v * v;
}
var two Number = 2;
four := two.square();

I'm really in 2 minds about it. I think I've looked at a large number of languages over the years, loved some, loathed others, always looking for the "perfect" one (where is it??).

I really, really love that people want to try their ideas out. I don't care if it goes nowhere from that POV, but a lot of great products have come from scratching an itch. I'm not really sure that a new language will actually solve things as expected -- it will probably take a lot of time and effort to shake-out those niggly bugs and issues, especially as it's meant to be a close-to-the-hardware language (isn't it?).

These days, I've come to the conclusion that no single language will adequately solve any problem, and people should use several languages together for several types of systems -- e.g. C for low-level/very-fast "driver" code, wrapped by a TCL/Perl/Ruby/Python glue language. Maybe with an Erlang/Scala back-end MQ service, and a Haskell parser/DSL for the less technical to write their plugins/snippets/blah.

I don't know, that example's very made-up, and I know there are a lot of folks who hate the idea of learning a new language, but it does annoy me that so me teams, companies and corporations are still so badly afflicted with tunnel-vision over languages.

Hello World compiles to a bit over 500KB on a linux machine. How will a system designed by this look like where simple tools are half a MB in size.

Super-fast erlang for the masses? :) Seriously ... I like the emphasis on concurrency-oriented programming. Also it's important to remember that systems languages are not the same as application programming languages - a much smaller user-base with far more specific needs.

What will be interesting is when the operating system built on Go comes out ... C is to UNIX as Go is to ... ? We'll see. Who was it that said: History don't repeat, but it sure does rhyme?

When I read about it I see a lot of inspiration from Python (a language I like) although I can't see it mentioned explicitly as an inspiration.

• No inheritance or explicit interfaces; interfaces are duck typed (but checked at compilation) makes for something very interesting!
• mapping type is part of the language, map, reminds me of Python's very powerful dict.
• Array slice syntax a[1:3], and you query a collection's length with len(m) ^[1]
• Acknowledgement of coroutines

Go should be a C replacement and as such be suitable for embedded systems development. A language that is at its core:

• simple
• fast
• produces small executables (when desired)
• sane syntax (I would consider Go's an improvement)
• modern

Why can't Go combine the flexibility, safety, and richness of Standard ML or Haskell with the low-level expressiveness of C? For some reason it stops short.

Provide a compiler flag that strips out features for software that can't use fancy runtime stuff, like kernels for example. Go is a system language that doesn't have, even basic, ASM support? Poo. Languages like D are trying, but at the end of the day D feels like C++ redux; same ideas, same "tack-it-on" design process.

The BitC language ^[1] looked promising, but I fear it may die a slow death since its main driving force and creator has left for Microsoft to pursue related endeavors.

C is an old work horse, for sure. But I think it's time to put it out to pasture (or taken to the glue factory depending on who you talk to) and replaced with something modern.

I've been programming for more than a few years and I'll make a prediction based on that experience. 'Go' will be the next "C". It's not the "be all end all" language, but in the next 5 years it will take over a HUGE chunk of the programming community's attention.

Go's not perfect, but even at this stage of (im)maturity it's extremely impressive. The compilers work. They're fast. It's simple to write code to solve interesting (non-trivial) problems. The resulting code is adequately fast on one CPU. The same code can benefit from multi-CPU cores if they're available. The problem and resulting design of course need to be 'parallel' amenable, but the actual speed gains are (in my own experience) stupendous on appropriate problems. The library code is evolving (adding functions) but the basic stuff is already quite good in the areas you'd expect to need.

NOTE: AMD64 6 core CPU at 3.2 ghz for $300. as of 2010. In 2012 that might be 128 core CPU for the same price. ( for example -> http://news.bbc.co.uk/2/hi/technology/8392392.stm ) Will your current C/C++ code adapt automatically to take advantage of those new CPUs? My go code can - without any rewrite.

I've only used go for about 3 weeks but I'm ready to go out on a limb and say : Go is the Next Big Thing(tm) :-)

Hotei

Concurrency is a big plus. Syntax support for easy threading might be the next big thing.

Meanwhile, "no windows" is problematic.

The syntax will be a real barrier preventing adoption. Then again, Ruby and PHP have some weird syntax issues(PHP's $var thing, for example) and seem to be going just fine.

As soon as more libraries start showing up(GUI for the desktop, databases for the server), Go might actually have a chance.

I'm not unhappy about go's supported platforms:

• Linux
• Mac OS X

(on x86, amd64 and ARM)

(Schadenfreude)

Google employees clearly have too much time on their hands.

.. I need to apply asap.

I like how there is already a fairly big standard lib, I havent tried it yet though.

A language that supposedly combines the ease of development of a scripting language with the performance (almost) of C sounds like a dream come true to me. :)

Add to that the fact that it's worked on by two guys who made some very useful, long-lived products, and I suspect they may know what they're talking about.

So here's my question: do they use this language when they have the choice? The designers, as well as other Google engineers. If so, they will make it useful and usable, and it must do some good things already for them to choose it.

Yet another programming language. It doesn't at first look seem to provide any major breakthroughs in terms of either productivity or performance.

I am just not sure in what situations using it would be appropriate except for perhaps small personal projects.

From looking at the basic tutorials it seems to simply be a new replacement for c in the same way c++ and objective-c replace/extend c.

Sounds like Google's version of Ada, but I won't jump to conclusions just yet. Let's hope the standard won't be 900 pages long.

I have played around with Go for two days now. Its syntax is a bit weird and needs some time to get used to. I always want to put parentheses around my if and for statements and leaving out the semicolon feels just wrong. But after a short adaptation phase I already get some lines of code down that just work the way I've imagined it.

My main criticism so far is about the tools provided. The compiler (6g) has no options like gcc or most other compilers I know do. There's no debug or release mode, no speed/size optimization and even the strip symbols option in the linker (6l) seems to break the executable and is thus unusable. Ok, I can live with that. It's not like I aim for best performance or smallest executable. Having a fast compiler is more important.

I love D partly because it has unittesting and ddoc as integral part of the language. So I was excited at first when I heard that Go has these things as well. But so far I can't get either of them to work, and that's mainly because they are NOT part of the language.

godoc is a program, that creates a (HTML) documentation from all the packages that come with Go. But it's nearly impossible to get it to work if you have your own program, that doesn't reside inside the GOROOT subdirectories.

gotest is actually only a batch script that uses the Makefile(s) to compile the tests and run all methods that match a certain pattern. Yeah...Makefiles. I hate those. I don't use them. And it's not possible to use gotest without them. So my first little project is a build tool that makes Makefiles obsolete. From there to gotest2 shouldn't be hard.... ;)

Some more thoughts:

• I don't know why the language has 'goto' if they don't include other things with the explanation that it would just lead to more bugs...
• No dynamic arrays (and no simple array concatenation). They have containers in the library, but that doesn't feel the same.
• goroutines, they work great...adding 100k elements to a vector results in a few thousand casualties (overwritten elements) but no crash. I can already see the bugs this will create, but I still think it's a great feature.
• Channels. Seem to make writing any type of server a lot easier.
• Source code doesn't look as clean as Java or D.
• I'm missing some things in the documentation. The general usage of a certain package for example. The _test.go files for that package are often more helpful.
• writing := where you should have written = can easily lead to bugs that are hard to spot (depending on font, font-size and tiredness).
• I don't miss assertions or exceptions, yet. try-catch blocks look better than a second return value and an if block, but it's doing the same. And I can probably write an assertion function in 5 minutes that crashes my program if false.
• I don't use generics/templates in any language if I can avoid it. I just don't like them. And I most certainly will not miss them. But others may. They seem to have a huge fan-base out there.

Jeff Bone's awesome Go rant. A great read.

http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html

It's merely the latest of a series of languages from these same people (former god-like heroes to me) --- most recently Limbo, each successive one of which implements the same ideas in barely, idiosyncratically, every-so-slightly different ways.

And so for 20 years now these folks --- the shining lights, in many ways, of "practical" programming language, operating systems, and general systems research --- have continued to fail to "get" the fundamental practical needs of everyday programmers working in The Real World. "Go" is just another language written first for the compiler and only secondarily for the programmer --- and stuck in a 70s mindset* about the relationship of that programmer to the (digital) world within which they live and work!

Being Google I would have expected that that choose a name that's easily googleable. Really, is it that hard to find a unique name that actually lets people Google for resources about the language?

No Generics. So you see things like this in http://golang.org/pkg/sort/

func SortFloats(a []float)

SortFloats sorts an array of floats in increasing order.

func SortInts(a []int)

SortInts sorts an array of ints in increasing order.

func SortStrings(a []string)

SortStrings sorts an array of strings in increasing order

I, for one, welcome our Go overlords.

I've seen a lot of people taking issue with the := operand, but it should not be too strange to anyone who has written more than a basic makefile. I've been looking for something that more or less merges C and Python in an agreeable way. I found a language named Blue ^[1], which looks like its getting to that point but is developing rather slowly. Blue is also interpreted, which was a minus for me.

I think I can get up and running with Go in a month or less. I'm still seeing stars (literally, *) when studying the syntax, and my C brain instantly wants to think pointer arithmetic. So, yeah, its going to take getting used to.

My biggest complaints will probably come when I switch from C to Go to PHP within the same 48 hours while working on multiple projects. But, well, that's why we have aspirin, I suppose.

It gives me an uneasy feel it got the green light out of frustration with the python core performance.

Much in the same way chrome was announced as an alternative to the tragic memory leaks firefox2 was suffering at the time.

If that's the case, too bad it doesn't retain Python syntax.

This language, as Rob says in the google tech talk is meant as a systems language. Realistically the number of true systems programmers in the dev ecosystem is probably less than 5% of the whole. Dont get me wrong, I LOVE the fast compile time etc but what is needed is a language that is simple, that reduces the complexity of the development process. I dont know that there is a silver bullet. I think Ted Neward hit the nail on the head in a discussion about Agile - "We are in desperate need of simplicity in this industry. Whoever gets that, and gets it right, defines the "Next Big Thing"." I think that in that context GO is yet another language and not the next big thing we are looking for.

http://blogs.tedneward.com/2009/10/12/quotAgile+Is+Treating+The+Symptoms+Not+The+Diseasequot.aspx

I would be interested to see how go's concurrency model will scale to clustered computing. The 'goroutine' system seems interesting.

It compiles really fast! See this short youtube video ^[1].

There some interesting stuff such as the goroutine stuff and the "static duck typing" (which I'm actually quite curious about, I have to check that video). But, please, no generics, exceptions, method overloading or operator overloading? The common standard library packages which look like bare wrappers above the c stdlib? Bah! I'm not impressed.

I like the minimalistic approach. It seems like they have identified a number of core crucial issues and then created a language that deals with just those while holding back syntactic sugar.

I think Go will be a great language if it can survive its obscurity phase. However, I don't see it as a replacement for c++. It does several things right, concurrency is big win, and procedural syntax.

However, one of the stated goals is replace c++, and be a system programming language. I don't think it meets those goals well.

Garbage collection is generally a sign of an application language. In don't see how a language can claim it's a system language and yet require a garbage collector.

Duck typing is giving python headaches. C++ templates are having a simlar issue they are trying to solve with concepts. There needs to be a way to explicitly say what interface a type needs to fulfill. I'm not advocating Java/C# style interfaces, but they need to solve that sooner than later.

Also as a c++ programmer, I can't move to a new language that doesn't offer templates. Java/C# generics are ok but I prefer D2/C++ style full power templates.

Reading "Go's type system has no hierarchy, so no time is spent defining the relationships between types" ( FAQ ^[1]) sounds scary to me. Whether I go to statically typed C# or dynamically typed Ruby, I can have my classes and my inheritance and my interfaces/mixins. That's how I think, and I don't know how I'd do creating a large-scale application with no inheritance.

The lack of generic types and exceptions is also odd to me, and feels like a step backward ( language design FAQ ^[2]).

• The only definitive improvement I see is the interface and type systems being untangled.
• The concurrency model looks like it will cause profound performance issues related to data access.
• Pretty much everything but the interface system is doable in C++ with the appropriate libraries/functions.
• Type system is probably less expressive than C++, especially the lack of overloading.
• They are correct in OO systems discussions having a focus on object modelling instead of solution finding.
• Wait, another replacement for C++ with garbage collection?

The typing approach has a certain value, I suspect, and would be interesting to explore at least.

I would conclude - here and now, in my opinion - I don't see a serious future for this language outside of a webserver market having to support many many lightweight threads. I may be quite wrong, of course.

Thoughts based off of: http://golang.org/doc/effective%5Fgo.html , http://golang.org/doc/go%5Ffor%5Fcpp%5Fprogrammers.html , http://golang.org/doc/go%5Flang%5Ffaq.html .

What can it really do for me (that I care about) that some other language I already know can't already do?

Until Google (or someone) comes up with a language that I can do something really cool in one line like...

Computer.MakeMeASandwich();

... I don't think I'll consider it to be anything else but yet another language.

I mean, even if it could do that, without Generics I can't imagine how it's going to be more efficient to code anything. I'll have to have a separate GetBeer method to get me a Great Lakes IPA or a PBR. Or I'll have to return generic beer and cast it as something else. And who wants to drink generic beer?

Lack of exceptions because of multiple return values is a mistake for me.

Interface system is good.

Pointers are bad, but necessary for a system language.

Finally array checked arrays in o.s. language. FFS people.

Agnostic about how the garbage collection can scale with parallelism. Java can get 5% in code that is well written but java has decades of JIT experience.

No JIT -> probably good, but precludes some optimizations probably including the very useful escape-analysis.

Lack of parametric types is huge mistake, capable of sinking evolution of the language to the application domain.

Syntax has a good idea (names first), but lousy execution sometimes.

Inheritance... I like polymorphism, i hate inheritance. So the decision to separate the interfaces from it is HEVAN.

Overloading is a huge source of bugs both in programs and in compilers. Good riddance.

Map embedded type. Sucks if no alternative is possible to declare. And without generic types it will not. Parametric Types, for me but not for you bahhh!

I like the 'sort of duck typing', reminds me of an answer I gave for what I'd like in C# 4.0 (http://stackoverflow.com/questions/138367/most-wanted-feature-for-c-4-0/253441#253441)

hey ho. Oh and I was interested until, "no windows". I've seen references indicating it is possible, but I've got other things that need my time.

The language is kind of what I would expect as Rob Pike's next language. Rob's done a great body of work, and this is a good logical next step. But what has me green with envy is the lightning-fast compiler. I wish I could compile C, Haskell, and ML one-tenth that fast! Luckily I write a lot of code in Lua ^[1] which also compiles blindingly fast (albeit to bytecode).

yet another programming language, this time by google!! Actually there is already a language with the same name, so it is slightly confusing having more than one language with the same name.

http://www.geek.com/articles/news/google-didnt-google-go-before-naming-their-programming-language-20091113/

I think it looks like it has huge potential - there are several very interesting concepts in there, not the least of which is GC and language support for concurrency: "don't communicate by sharing data, share data by communicating".

But frankly (and I am no MS fanboy) it's irrelevant until it is available for Windows, and probably even Mac. For me it's irrelevant until it also runs on the various hand-held and phone devices out there.

Everything postet before is very correct and comprehensive, but I haven't seen this:

• no Conditional Compilation. The Argument is you don't need it. Your built system should do it, or in other words: use file granular conditional compilation. I am not convinced on this. ( I discovered much copy and paste code where only single casts were changed :/)

• no assertions. The argument is that assertions are often misused for real error handling. This is certainly correct, but personally I like assertions (And evangelize their proper use).

• no constant parameters, functions. The argument - as with assertions - is that const is often times misused or too difficult. Certainly right, but still I think it's a great thing.

I don't see that omitting these things as a solution, but postponing difficult decisions. I hope it doesn't get in the way of the language. I really really like Go.

The cool things:

• gofmt as a prevention for style discussions. I spent much time defining my / a good style on c, so I like the idea of having a consistent style across all code. (even by force)
• There are so many other little things that make me like this language. (It's just too many)

I have to admit that the con points mentioned above held me back to code even a single line. All I did for now is reading up and studying the mailing list discussions. Nevertheless, when a project which needs a system language comes I will give it a try.

What would be good is a new native code compiled language that is not C / C++ / D / Pascalish.

Especially for embedded systems.

Seeing := as a shortcut to declare and assign a value to variables took me back to some of the first programming experiences I had, since they were in Pascal. :o)

Yet another language with a built-in algorithm. Great for short examples and nothing but pain for tasks that don't exactly fit into provided system of threading with channels.

I would be interested to see when it will have IDE support and will be available for windows also.

Well I think it's a neat looking language and the concurrency bits are extremely nifty. Also the removal of millions of paren's are great too(I'm programming in C#! Not Lisp! why must I have 3 different casts with 8 different sets of parens!?)

That being said. It's just another language. There are not any points yet that make it viable to compete with C/C++. The language is decently better. Decently better will not cover the expenses of retraining and all that though.

I do like that this is a lower level language(runs on the actual machine) yet has garbage collection.

I think it would be neat to test just how good it is at handling low level things by writing a kernel in it. (course parts will be bootstrapped with C, but still)

The initialization :

s:=0;

It would be better if "=" is used instead of ":=" to represent an initializing declaration.

I liked the Minimization of use of parenthesis in "for" and "if" statement

 for i := 0; i < 10; i++ {

  if s==0 {   }
}

its quite similar to C++, which made me wanna check it out, I think the language is carefully planned, but I still think its too early to be used. Might wanna wait until it gets to 1.5 before I decide whether to study it or not.

I think this says it all:

say good-bye to stack overflow(s)

function for finding factorial

func Factorial(n int) (fact int) {
  if n == 0 {  fact = 1;  }
  else {  fact = n * Factorial(n - 1);   }
  return;
}

I don't understand why compiling time can be so important for Google. Someone can explain, please?

The iota keyword seems to me really weird. It's a sort of automatic-pseudo-variabile to be used in const, in order to emulate enums.

I think that enums are simpler and cleaner than the iota sintax.

I would prefer, btw, a more expressive metalanguage rather than this strange thing. Or better, a reflection structure, that let use the language itself as its own metalanguage. I understand that reflection is expensive, it requires, I think, more steps to compile, and bigger structures (meta structures are required as well). I don't think that a preprocessor could be considered as an innovative idea.

I mark go's syntax good. The better syntax languages I used are lisp, python, and xml. If programmers are looking for the middle point between machine-code and natural English, they are near that point; but, if we are looking for the golden point closer to natural English from machine-code, go is around that point.

Many years ago, java released programmers from memory-management; today, go will release us from cpu-management.

Without going into a rant, i think i will never use it.