My word, a whole bunch of what I'm reading is exactly what I have/had intended to implement in <i>my</i> toy language, prism. Bit-specified integer (and real) types, increment/decrement operators as statements (prefix only!), hell, even using "var <X> ..." for variable declarations. The guiding principles are divergent though. And the bit about deducted type relations (<a href="http://golang.org/doc/go_lang_faq.html#inheritance" rel="nofollow">http://golang.org/doc/go_lang_faq.html#inheritance</a>) leaves me with mixed feelings.<p>I'm actually happy! It means my stupid little language has some validity :P<p>For those who wish to deride it: <a href="http://code.google.com/p/prism/" rel="nofollow">http://code.google.com/p/prism/</a>
I'd have to disagree with the title "Python meets C++". There's very few features that have been brought over from either of those languages.<p>It looks like C with some very carefully chosen additions: memory safety, concurrency and maps.
I had a friend who was worried about the overhead of interfaces (are methods called by hash lookup on name or by something like a vtbl?), so I compiled a simple example program to test how dynamic dispatch works: <a href="http://scott.wolchok.org/vtbl.go" rel="nofollow">http://scott.wolchok.org/vtbl.go</a><p>The binary is at <a href="http://scott.wolchok.org/6.out" rel="nofollow">http://scott.wolchok.org/6.out</a> . If you search for deadbeef, you'll find a sequence of instructions ending in an indirect jump, so it is decidedly not some kind of string comparison.<p>The function in the compiler that generates calls through interfaces seems to be cgen_callinter in go/src/{6,8}g/ggen.c, but I can't decipher the terse code therein. Would be interested to learn more about Go method dispatch, especially as regards to dynamic linking -- does Go have it? What if I create a new interface that encompasses objects in a library built before I created that interface? Do I have to rebuild the library?
Doubt it will be successful, no beards: <a href="http://www.youtube.com/watch?v=rKnDgT73v8s" rel="nofollow">http://www.youtube.com/watch?v=rKnDgT73v8s</a>
<a href="http://golang.org/doc/go_faq.html#Concurrent_programming" rel="nofollow">http://golang.org/doc/go_faq.html#Concurrent_programming</a> "Do not communicate by sharing memory. Instead, share memory by communicating."
Chrome. Closure. Go.<p>It says great things about Google that these all clearly started as projects that they assumed <i>nobody would ever have to Google.</i> (Although <a href="http://www.google.com/chrome" rel="nofollow">http://www.google.com/chrome</a> is now #1 for [chrome]).
Ok, a language for engineers not for people that want to be truly expressive with the code they write. This is my impression when looking at the examples, they have something odd in the way the code looks like.<p>Now from the technical point of view, there are a few interesting points like the threading approach, but in general the language does not appear to provide great new ideas, nor to be a language where consolidated ideas are put together very elegantly.<p>It seems like that for system programming the "better C" that one could need is different than this, while for general programming what is really missing is something like Ruby and Python but made as fast as C and with low memory usage by mean of doing the right sacrifices to the language, but still retain most of the abstraction level.<p>Go is not as powerful as C++, not as high level as Java, not as raw as C for low level stuff. I don't like it.
<p><pre><code> hg log --rev 0:4 --template '{date|isodate}\t{author}\n\t\t\t\t{desc|firstline}\n\n'
1972-07-18 19:05 -0500 Brian Kernighan <bwk>
hello, world
1974-01-20 01:02 -0400 Brian Kernighan <bwk>
convert to C
1988-04-01 02:02 -0500 Brian Kernighan <research!bwk>
convert to Draft-Proposed ANSI C
1988-04-01 02:03 -0500 Brian Kernighan <bwk@research.att.com>
last-minute fix: convert to ANSI C
2008-03-02 20:47 -0800 Robert Griesemer <gri@golang.org>
Go spec starting point.</code></pre>
AT FIRST GLANCE:<p>Annoyances: braces; variable declarations more verbose than in C<p>Flaws: no discriminated unions; no generics or parametric polymorphism<p>Doubts: no exceptions; no macros (as far as I can tell)<p><pre><code> Edit: I take back the verbosity claim. := does inference
Edit2: interfaces replace generics, but are
type-checked at runtime, apparently:
http://golang.org/doc/go_for_cpp_programmers.html#Interfaces</code></pre>
"Go has its own model of process/threads/light-weight processes/coroutines, so to avoid notational confusion we call concurrently executing computations in Go <i>goroutines</i>."<p>I like this not just because it's CSP reborn -- new languages should be introduced with their own delightful disambiguating nomenclature.
Ars Technica on Go<p><a href="http://arstechnica.com/open-source/news/2009/11/go-new-open-source-programming-language-from-google.ars" rel="nofollow">http://arstechnica.com/open-source/news/2009/11/go-new-open-...</a>
You have to love a project where the designers are sitting on irc fixing build bugs as they come in. (No, this isn't unique for opensource projects, but it's always great to see.)<p>Thanks for giving me something to do with all my free time for the next couple of weeks.
For my doctorate I did everything in CSP and Occam, so it's wonderful to see the channel communication methods defined for this language.<p><a href="http://golang.org/doc/go_mem.html" rel="nofollow">http://golang.org/doc/go_mem.html</a><p>If you do things via synchronized channel communication then it eliminates (mostly) the need to spend all your time with mutexes and the like because the channel sync does that work for you. At the beginning it'll probably take people time to get there heads around it, but my recollection was that it was a game changer once you understood how the synchronization worked.
I use C when I have a program with tight timing and/or memory requirements. I see that this is a GC language, so am I right in assuming that it's not suitable for soft or hard realtime systems?
I wonder if Go is what will "replace" Python internally at Google? ( w.r.t. <a href="http://news.ycombinator.com/item?id=933493" rel="nofollow">http://news.ycombinator.com/item?id=933493</a> )
It's a very promising language, and the tutorial's not bad.<p>The main quirk I see right now is that the syntax feels more like a shuffling of characters, rather than actually simplifying anything. For instance, they save parentheses in for loops (great idea!), yet suddenly I need a useless "func" before every function. It also seems like there needs to be a default type for arguments, either "int" or "string", for it to feel truly simplified.<p>A feature I would really, really like to see in a language is the notion of automatically printing lone strings, or automatically printf()-ing lone string format lists. It's a little irritating after all this time that one must "echo" or "print" or System.out.println() or fmf.Printf() everything (much less import standard libraries to do it), when it is <i>such</i> a common task.
wow... first impression is this is my dream language... Can't wait to start messing with this...goroutines yay...I could be wrong but this looks really nice.
After reading "The Case for D" a little bit back, what these leaves me wondering is not, "Why this over C or C++?" but "How does this compare to D?"<p>After a quick glance, D piqued my interest more. D seems to fall a bit nearer to the C++ side of the fence than Java, but also boasts C++-level performance and relative safety.<p><a href="http://www.ddj.com/hpc-high-performance-computing/217801225" rel="nofollow">http://www.ddj.com/hpc-high-performance-computing/217801225</a><p>Neither of them will replace C or C++ in the near-term simply because those languages are so entrenched, but if I were looking for a language just to play around in for potential future use from these families, at this point it'd be D.
The home page touts "safety" as a feature the language but all it takes to crash the program is concurrent access to the builtin map: "uncontrolled map access can crash the program", according the faq.<p>Interesting so far besides some syntax ugliness and lack of macros, but not yet good enough for many system programming projects, especially given the state of the garbage collector. GC is the hardest thing to implement large-scale, concurrent, memory intensive applications (e.g, database servers). Java spent 18 years to perfect its GC to be the current state of the art, which still sucks for these applications.<p>I hope they can come up with a concurrent garbage collector that can work on > 16 GBs of RAM with sub ms max latency :)
Looks interesting! I feel that an improved C is what's mostly lacking in the programming language landscape nowadays.<p>So now Google's got its own OS (two actually), browser, and now its own programming language. Anything missing yet? Their own editor / IDE?
A lot of this looks very nice. One very simple thing I noticed was missing was a binary integer literal syntax. With a systems programming language, it would be nice to be able to write bit sets without shifts sometimes. Just use the obvious '0b10100101' syntax.<p>Also, I think the zero-prefix convention for octal literals is very confusing and possibly error-prone, but it seems to be used even in modern programming languages. Is there a good reason to keep using '0765' instead of something '0o765'?
"However, in Go, any type which provides the methods named in the interface may be treated as an implementation of the interface"<p>I've been wanting this in C# for a while now. Maybe one day...
It does certainly smack of "Not-Invented-Here Syndrome," but compared to the Dilbert like project management culture of my job I rather admire it.<p>I've just been getting in to generic programming with C++ (Stepanov's new book, awesome). So the fact that they don't have templates or operator overloading (the two critical pieces to STL style) was a bit of a downer. That being said the interfaces concept reminded me of generic functions (in CLOS). Sounds pathetic but I probably will give it a try just because it's from Google -- but I'm quite skeptical. With the really interesting work going on with Haskell, Clojure, Fortress, etc. it seems a shame to stay so close to C.
I am curious if someone could explain how a project in Go would compare to a project in Python or Ruby + a fancy array of custom C modules? This implies that it is possible to implement the nicer features of Go (for example concurrency support) in the modules supporting these languages. Or instead making kickarse fast compilers for higher level languages?<p>Is it too simplistic to say that at one end you have expressive languages designed for humans and at the other you have low level languages designed for speed?<p>edit: not meaning to insult humans who like fast languages.
I am just wondering how same link got posted twice ...
<a href="http://news.ycombinator.com/item?id=934140" rel="nofollow">http://news.ycombinator.com/item?id=934140</a>
....Both point to <a href="http://golang.org" rel="nofollow">http://golang.org</a> ..
might be influenced from this <a href="http://www.vitanuova.com/inferno/papers/limbo.html" rel="nofollow">http://www.vitanuova.com/inferno/papers/limbo.html</a>
And finally C 2.0 sponsored by Google.
Good move against Apple.<p>It (go + native client) might become a next major platform. Just think about low-level (and easier to code than C[++]) Javascript alternative.
What the hell??? Didn't they come out with programming language last week already or some such? I don't see the point exactly. I mean I can learn it, but then what? It's not going to be installed anywhere where I can do work, it's not going to have any third party libraries, it's not going be be supported by any decent editor for a while (I use vi, throw your rocks).<p>Google: what is the point? First it's browser plugins, then browsers, then two OS's, now programming languages? How about a nice new processor architecture a la PowerPC? It's better and faster you know. Maybe they'll also invent new people to be their user base. I can imagine that intro video: "Welcome to GPeople - the new Google interaction experience. When you interact with a GPerson you don't need to talk. They already know what you are thinking and will insert relevant advertisement into their conversation with you. The advertisement will be unobtrusive and will target your innermost fears..."
This new programming language from Google is quite a buzz on the web now. To be honest, I always got excited about tools that promised to speed-up and simplify development. But most of the time, those trendy tools are just even more time wasters. One language I find to be [almost] ideal is Scala. I believe that Scala will replace Java. Also, writing code for JVM gives you a huge advantage - you can create OSGi bundles. IMO, OSGi framework is the most mature module system. So I think that there's nothing good about this language except that it's created by Google.
I am not interested in really learning another programming language, and from the looks of it, the productivity claim is questionable. Not only can many of the examples they show be done in fewer lines of code in other languages, but you also do not need to re-learn the languages you already know. Many programming languages offer many of the features they are mentioning as useful so why learn yet another programming language unless it truly has something useful to offer that does not already exist. As one person stated, it has braces. I like braces for the purpose of organization, but I dislike variable declarations because it only serves to clutter the code and sometimes decreases productivity. The programming language needs to become more productivity oriented, and I do not think Go accomplishes this goal. Developers want to be creative with their code, but they would probably rather be more creative with their projects instead.