
Google Go: A New Programming Language That’s Python Meets C++ - snewe
http://golang.org/
======
omnigoat
My word, a whole bunch of what I'm reading is exactly what I have/had intended
to implement in _my_ 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
(<http://golang.org/doc/go_lang_faq.html#inheritance>) leaves me with mixed
feelings.

I'm actually happy! It means my stupid little language has some validity :P

For those who wish to deride it: <http://code.google.com/p/prism/>

~~~
omnigoat
Well, in the interests of actually furthering discussion:

I feel as if string and map simply could have been part of the standard
library. My solution to the this for prism was to have a section of the
standard library (which doesn't exist yet) marked as "integral", to
effectively have an implicit "import string, map from std.__integral__" at the
top of every translation unit.

The absence of overloading operators seems to contradict their claims of
improving the visual "flow" and feel of programming. There are cases where
savvy operator overloading works wonders: vectors/matrices/quaternions,
strings, complex numbers, etc. To be able to write my_string + my_other_string
is far more elegant than strcat(my_string, my_otherstring). Consider what
happens when you have four of five strings you'd like to concatenate!

The choice of CSP reflects Google's mentality: Their problems lend themselves
very well to CSP. Other domains (in my opinion) work better with a STM model.
But that's clearly a design choice, and I think it's fine!

~~~
agl
Operator overloading has good points and bad points: we're erring on the side
of simplicity for now.

However, you can write "abc" + "def" in Go and it does what you expect.

~~~
astine
=> "egi"?

~~~
spicyj
I'm sorry if this is a stupid question, but where'd you get that? I don't get
it. :(

~~~
skarlath
"abc" + "def"

a + d = e (1 + 4 = 5 = e) b + e = g (2 + 5 = 7 = g) c + f = i (3 + 6 = 9 = i)

I think he was making a joke about how + with strings doesn't necessarily mean
string concatenation.

~~~
patio11
I think the point is even better than a joke: there is a _danger_ in allowing
things like, e.g., operator overloading (or redefining methods in the standard
library), because programmers have different feelings about what the code
"obviously" means.

If in your language, + means string concatenation by convention, then + darn
well means string concatenation. If in your language + means "contextually
appropriate depending on what arguments you pass to it", then

"abc" + "def" => "egi"

doesn't strike me as obviously wrong.

More broadly, consider a language in which we teach initiates that "Plus adds
things in the way you'd expect!"

map = {}

map2 = map + {"key" => "contents"}

What are the contents of map and map2 now? Uh oh. More worrisome:

map = MemcachedWrapper.new

map2 = map + {"key" => "contents"}

What just happened?

~~~
tsuraan
This whole line of reasoning reminds me of the Java3D API. Java, of course,
takes the approach that only the designers of the langauge were smart enough
to know when to abuse operator overloading (e.g. with strings), so for the
Java3D math API, they couldn't have nice syntax for vector arithmetic. Instead
of having nice operators for addition (+) and accumulation (+=), they just
have english, and they want it to be terse, so the accumulation method is
.add, and there is no addition method for vectors. It's not terribly
confusing, but seeing vec1.add(vec2) rather than vec1 += vec2 is ugly and you
still have to read the documentation to know what the .add method does.

Avoiding operator overload doesn't avoid poorly named methods, nor does it
avoid the need for documentation. All that it does is force programmers to do
ugly things when dealing with math, and there is a lot of math-based
programming out there.

------
akamaka
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.

It looks like C with some very carefully chosen additions: memory safety,
concurrency and maps.

~~~
mbrubeck
I agree. From the FAQ:

 _"Go is mostly in the C family (basic syntax), with significant input from
the Pascal/Modula/Oberon family (declarations, packages), plus some ideas from
languages inspired by Tony Hoare's CSP, such as Newsqueak and Limbo
(concurrency). However, it is a new language across the board."_

Two of the designers were Rob Pike and Ken Thompson, both instrumental
developers of Unix/C and Plan9/Inferno. Thompson created the B programming
language that C was based on.

~~~
dhess
Don't forget Russ Cox, who I believe stuck with Plan 9 longer than either Rob
or Ken.

I'm excited to see CSP in Go. I've been advocating its use for concurrency
since I learned about Plan 9's channels, but most people paid no attention.

~~~
uriel
Russ still maintains 9vx and Plan 9 from User Space.

------
swolchok
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:
<http://scott.wolchok.org/vtbl.go>

The binary is at <http://scott.wolchok.org/6.out> . 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.

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?

------
benreesman
I was ready to be dismissive until I read who was behind it. This is part of
the Bell Labs legacy. Kickass.

~~~
amichail
How come who was behind it is important but who says what on HN is not?

One could have extra information right beside each submitter/commenter's name
(e.g., ... founder, Google employee, PhD in ..., etc.).

~~~
DougBTX
There are some usernames I will recognise, and their comments do mater more to
me. Also, if someone does say something interesting, you can often learn more
about them from their profile page should you wish to.*

And, yes, it would amuse me for a couple of days if everyone with/working on a
PhD were encouraged to append their thesis titles after their usernames.

* though yes, for people I don't recognise who are not posting particularly interesting comments, it does not matter who posted them. Such as this comment I assume, anyone could write it.

~~~
amichail
Imagine someone commenting on Google but you don't take his/her comment
seriously and post a reply indicating that this person is mistaken.

You later find out from his/her profile that this person is a Google employee
and is in a position to know what he/she commented about. It might be too late
by then to take back what you wrote.

~~~
unalone
Too late for what? This is the Internet. You're allowed to make an ass out of
yourself sometimes.

I remember when I came on here and criticized Delicious and got in an argument
with joshu because I didn't know who he was. If anything, I'd like _more_
anonymity, because the people I _do_ know I sometimes tiptoe around.

------
jhawk28
Doubt it will be successful, no beards:
<http://www.youtube.com/watch?v=rKnDgT73v8s>

~~~
agl
Ken, iant and I have beards thank you :) Rob, gri, Russ and Kai are sadly
lacking.

~~~
nailer
Any chance you could please ditch the brace requirement?

You're already marking up the code for humans using indentation, don't repeat
yourself by having the compiler use a different parsing mechanism (and make
developers mark up seperately for their colleagues and the compiler).

~~~
jacquesm
Let's please not ditch the brace requirement.

~~~
nailer
Could you provide either some supporting arguments or a response to the parent
post?

~~~
jacquesm
Sure. The 'indentation is enough' argument ignores that braces offer
redundancy and are unambiguous.

They're like guard rails on the highway, they make totally explicit what is
going on.

The 'but you're writing for other humans to read' argument imho is not 100%
the truth, you're writing for both the computer and other humans to read.

Humans like the indentation, the braces make it explicit.

The computer doesn't care about the indentation, it _just_ looks at the
brackets.

Drop a bracket and you get an error, drop a couple of spaces and your program
will happily continue to work, only not in the way you intended.

it's funny how even in languages that don't use 'begin/end' markers (such as
python) there are extraneous characters, such as the () pair when calling a
function (surely there are ways to do without that ?), or when making a list
or a dictionary.

Some things come in pairs, and the beginnings and endings of blocks are such
things.

In Pascal it was BEGIN and END, which seemed overly verbose, in C it was { and
}, which seems about as minimal as you can go before you become invisible, and
when you get invisible you lose something.

Try cutting and pasting some python examples from online fora and see how well
it works without.

And try figuring out from a python program that has been created on a box with
alternate tab settings what it's intended function was (yes, I know there are
tools for that situation).

Begin and end block have meaning, they are 'there', and even if you don't
strictly speaking need them they cost next to nothing and make me feel a lot
more like things are spelled out to mean exactly what I'm reading.

I should probably start collecting python examples in the wild on the web
where the indentation is clearly messed up so the code no longer works the way
it is intended, this is a lot more common than you'd want. It is also very
frustrating when learning a language.

So, please keep those braces.

~~~
nailer
Redundancy is an argument _against_ braces, not in favor.

'They're like guard rails on the highway, they make totally explicit what is
going on.'

Using this logic, perhaps you should add some ASCII art to your source to
denote blocks a third time? This is also a common practice. Do you feel the
same about duck typing?

'The 'but you're writing for other humans to read' argument imho is not 100%
the truth, you're writing for both the computer and other humans to read.'

Yes, that's true the computer also parses the code. You still haven't provided
an argument why using seperate blocking formats is required.

'they cost next to nothing and make me feel a lot more like things are spelled
out to mean exactly what I'm reading.'

The cost is evident: there are many cases of indentation not matching braces
and vice versa, and the inconsistency between these causing confusion between
the language and the humans trying to debug issues.

Tell me you've never looked for an unmatched brace in code you can otherwise
parse?

~~~
pohl
_Redundancy is an argument against braces, not in favor._

I disagree. I know that the word "redundant" sometimes carries a negative
connotation, but the truth is that it is a mere property whose value depends
upon the context and associated tradeoffs.

Spacecraft have redundant systems, but those systems are far from superfluous.

Human languages have built in redundancies. Generally they are there for
ensuring communication still happens in a noisy environment.

My music CDs have redundancy in the encoding, and thankfully at that: after
years of accumulating scratches I could still rip them without loss of
quality. Redundancy was a positive here too.

Redundancy is a tradeoff, not an automatic downside.

~~~
nailer
Agreed about context, but let's be clear: spacecraft and music CDs have
redundancy to _prevent loss_.

What loss are you preventing by requiring blocks be delimited twice?

Have you considered that inconsistencies due to repetition are frequently
themselves cites as a cause of data loss?

Ever had code that looks good to you but doesn't parse because a machine is
expecting an extra bracket?

~~~
pohl
I'm no rocket scientist, but I'm pretty sure that not all redundancy in
spacecraft is aimed at preventing data loss. If you look closer you'll see
redundant gyros for attitude control, redundant sources of power (solar
panels, fuel cells) and probably numerous redundancies in environmental
subsystems on the ISS (air, water, waste), and even redundant explosive bolts
for stage separation.

I think jacquesm already mentioned the value of the redundancy above: you will
never have a situation where a change in indentation leaves you with a
runnable, but semantically-different program when you pasted code from a forum
or from a machine with different tab settings. Note how the missing-bracket
case in your last question is superior to this: a missing bracket offers fail-
fast detection of the problem. If you indent a line wrong your program may
still run, but differently: indent the last line of a block at the wrong level
and it may happen after a loop rather than inside a loop.

The indentation is for the person. The braces are for the compiler. I like
this, personally. I understand how some may prefer the python way (it has a
superficial elegance, after all). But I personally don't like the downsides
that jacquesm mentioned.

~~~
nailer
'you will never have a situation where a change in indentation leaves you with
a runnable, but semantically-different program when you pasted code from a
forum or from a machine with different tab settings.'

In that situation, with any computer language, you'll have an unreadable
program. In Python, you'll need to fix the readability before the program will
execute - which is a win to me.

~~~
pohl
I'll admit I don't know what magic the Python interpreter is capable of. I was
imagining cases where an indentation change does not break readability:

    
    
        for foo in bar:
            foo.fizzle()
        baz.wibble()
    
    

...versus...

    
    
        for foo in bar:
            foo.fizzle()
            baz.wibble()
    

...how would it know that I wanted to wibble the baz every time I fizzle a
foo, as opposed to wibbling the baz only after all foo have been fizzled?

~~~
nailer
Because you've told it to by making your data look correct.

Python executes your data the same way you yourself parse it: by how it
appears. Brace requiring languages execute your data using different rules
than you use to parse it.

Redundancy of logic is universally known to be a poor engineering practice.

~~~
pohl
_Tortoise:_ I'd like a bicycle helmet, please.

 _Achilles:_ Why do you want to wear a helmet?

 _Tortoise:_ So that I won't hurt my head if I bump it.

 _Achilles:_ You won't bump it.

 _Tortoise:_ Suppose I do.

 _Achilles:_ You won't bump your head.

 _Tortoise:_ But suppose, hypothetically, that I fall off my bike and bump my
head. What would protect it from injury?

 _Achilles:_ Your head is not injured, because you didn't bump it.

 _Tortoise:_ But that's the very basis of my hypothesis!

 _Achilles:_ Yeah, I'm going to just ignore you said that, and tell you again
that you won't bump your head.

 _Tortoise:_ How do you know?

 _Achilles:_ Because you made sure that it didn't come into contact with
anything.

 _Tortoise:_ Good night, dear Achilles. May you encounter others like you.

~~~
nailer
Sorry poor Tortoise, you're putting words into Achilles mouth.

Fortunately, Python gives you:

* A helmet. It won't parse unblocked code like any other language.

I'm not sure why you think blocking a second time with brackets would improve
things or avoid this risk. But hey, if you want to wear a second helmet,
that's cool. May you encounter others like you. :^)

* A mirror where things are as large as they appear (the blocking looks like it executes), unlike other languages where these can get out of sync and cause problems. If you enjoy this risk, that's awesome. High five.

* A handy warning light should you accidentally stray too far to the wall (Python will telling you that your readability is broken at the same time it tells you your blocking is - and you only need one fix). If you'd prefer not to be told about this, two places to fix things, and enjoy receiving badly written code, that's your prerogative and who am I to say anything other than that it's not mine.

Achilles: Nice bike and helmet.

Tortoise: No!

Achilles: Er, ok. Could you explain?

Tortoise: I need to get a helmet!

Achilles: You're already wearing one.

Tortoise: But what if I fall?

Achilles: You're wearing a helmet, which will protect you.

Tortoise: But I need to get a helmet.

Achilles: No you don't, you're wearing one. Oh and by the way, you need to be
visible at night. The helmet's reflective, so you probably don't want to cover
it with another ...

Tortoise: You're not listening to me!

Achilles: I am listening, but I'm also disagreeing. Are you listening to my
disagreement?

------
milkshakes
<http://golang.org/doc/go_faq.html#Concurrent_programming> "Do not communicate
by sharing memory. Instead, share memory by communicating."

------
byrneseyeview
Chrome. Closure. Go.

It says great things about Google that these all clearly started as projects
that they assumed _nobody would ever have to Google._ (Although
<http://www.google.com/chrome> is now #1 for [chrome]).

~~~
jkincaid
Is there a reason why so many languages are nearly impossible to search for?
(C, C++, Go, etc.) I mean, surely someone must have figured out that this is
not the best naming trend quite a while ago.

~~~
joeld42
Really? <http://tinyurl.com/y8zjorj>

~~~
igrekel
Hem... at one point you will need to search for more specific things.

"package management for go programming language" or "XML parser go programming
language" probably won't be so useful, and it is sure cumbersome to type.

------
antirez
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.

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.

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.

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.

~~~
blasdel
Neither C++ nor Java implement Hoare's CSP, or have any primitives fundamental
enough to implement them in terms of.

Go is _exactly_ what you're asking for in your third paragraph -- it seems you
were blinded by the curly braces...

~~~
antirez
Yes CSP is a good abstraction that Go implements, but programming languages
are not just a matter of features like call-cc, tail-calls, closures and so
on. This are _very_ important things, but it's not enough.

------
blasdel

      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.

------
nearestneighbor
AT FIRST GLANCE:

Annoyances: braces; variable declarations more verbose than in C

Flaws: no discriminated unions; no generics or parametric polymorphism

Doubts: no exceptions; no macros (as far as I can tell)

    
    
        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

~~~
jrockway
Yeah. Languages with no control flow other than "call" and "return" were ok
for the 80s... but we know better now. Just add continuations and you get
functions, coroutines, exceptions, loop exits ("last", "next", etc.), and so
on for free.

I am not sure why I'd use this language with no libraries when I could use a
better-designed language with no libraries instead.

~~~
btilly
There are other control flow options available. For example they offer the
following simple example of what they call _goroutines_ :

    
    
        ch := make(chan int);
        go sum(hugeArray, ch);
        // ... do something else for a while
        result := <-ch;  // wait for, and retrieve, result
    

You can actually set up any complex mess you want of functions talking to
other functions through channels. This gives you coroutines, threading, etc.
Looking through the spec, it looks like they have anonymous functions and
closures as well.

While I agree that they need to add exceptions, they do have some interesting
things in there already.

------
blasdel
"Go has its own model of process/threads/light-weight processes/coroutines, so
to avoid notational confusion we call concurrently executing computations in
Go _goroutines_."

I like this not just because it's CSP reborn -- new languages should be
introduced with their own delightful disambiguating nomenclature.

~~~
nailer
I like it because it rhymes.

------
mdemare
Garbage collection, type inference, built-in maps and arrays, immutable
strings, concurrency support. Very nice!

Best of all, no header files!

~~~
thaumaturgy
As a random aside: it's possible to build C++ projects without header files,
and get your source files to automatically work out their own dependencies and
all that good stuff.

I did it with a horrible C++ preprocessor hack. It was fun.

~~~
dchest
And for C, see makeheaders <http://www.hwaci.com/sw/mkhdr/>

------
Luyt
Ars Technica on Go

[http://arstechnica.com/open-source/news/2009/11/go-new-
open-...](http://arstechnica.com/open-source/news/2009/11/go-new-open-source-
programming-language-from-google.ars)

~~~
mdemare
Nice article, but calling Go not innovative because it has a C-like syntax is
a bit naive.

~~~
wendroid
Journalists journalist, coders code.

~~~
nailer
There's a shitload of coders who write well.

* Kathy Sierra

* JWZ

* ESR (okay he's a bad coder, but still)

* Zed

* _Why

* The MIT Introduction to Algorithms instructors who clearly spend time making their lectures entertaining as well as informative.

* And yeah, most of the staff at Ars:

DRY dictates not having seperate markup for the compiler and your colleagues -
so yes, in that respect, the unnecessary braces in Go are not innovative.

------
telemachos
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.)

Thanks for giving me something to do with all my free time for the next couple
of weeks.

------
jgrahamc
For my doctorate I did everything in CSP and Occam, so it's wonderful to see
the channel communication methods defined for this language.

<http://golang.org/doc/go_mem.html>

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.

------
tumult
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?

~~~
kaib
Most of Google infrastructure is soft realtime so GC delays have definitely
been a concern. The memory footprint for a simple hello.go on arm using 5g is
currently ~70k with the optimizer not yet enabled. I'm planning to do some
work on a AT91SAM7 with 256kb of flash and it should fit OK. You might be able
to squeeze it into a smaller space if you drop some of the runtime.

~~~
tumult
Assuming the OS threads/preemptive multitasking are playing nice (i.e. letting
me devour timeslices at my leisure), how well do you think the GC would work
when I need to land events in a 15 microsecond window at 40hz on a normal
desktop PC? I'd be crunching a decent amount of math and discarding/creating
objects between events, but total memory utilization would not be going up or
down.

Sorry if that's kind of specific, it's some of the limitations in one of the
current problems I'm working on :)

~~~
kaib
Given the realtime GC is not done nobody really knows. However, the design
goal is to have the GC interrupt time to be linear to the stack of your go-
routine (with small constants). Thus you should have at least some control
over event latencies through program structure.

Like I said earlier, there is significant interest inside Google to make it
possible to write really low latency services in Go. I personally think 15
usec is reasonable to ask for.

~~~
tumult
That's very very cool, thanks for the info

------
swaroop
I wonder if Go is what will "replace" Python internally at Google? ( w.r.t.
<http://news.ycombinator.com/item?id=933493> )

------
frankus
I can't find any sort of reference to a Google sponsorship. Am I missing
something?

~~~
agl
We (the Go team) all work at Google :) See also
<http://www.youtube.com/watch?v=rKnDgT73v8s>

~~~
messel
Thanks Adam.

------
makecheck
It's a very promising language, and the tutorial's not bad.

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.

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 _such_ a common task.

------
joeld42
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.

------
wheels
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?"

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.

<http://www.ddj.com/hpc-high-performance-computing/217801225>

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.

------
vicaya
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.

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.

I hope they can come up with a concurrent garbage collector that can work on >
16 GBs of RAM with sub ms max latency :)

~~~
blasdel
It is intended to be absolutely safe: dereferencing an invalid pointer doesn't
result in "undefined behavior" -- it results in your program halting every
time. You can't accidentally succeed or allow for buffer overflows, which is
all that's important (especially since Go doesn't have exceptions).

Hopefully they can rip off the design of GHC's amazing parallel garbage
collector (it runs in its own pthread), and ditch the current mark-and-sweep.

------
michaelneale
Looking good. I always thought something like this would be LLVM based, this
is surprising.

~~~
9oliYQjP
They said in the FAQ that they "felt" LLVM was "too large" and "too slow". I
would have liked to see this statement backed up with data.

~~~
nikils
link to Ken Thompson's previous c-compiler paper
<http://doc.cat-v.org/plan_9/4th_edition/papers/compiler> search for
'Performance'

------
mdemare
Looks interesting! I feel that an improved C is what's mostly lacking in the
programming language landscape nowadays.

So now Google's got its own OS (two actually), browser, and now its own
programming language. Anything missing yet? Their own editor / IDE?

~~~
SwellJoe
Bram Moolenaar (vim) is a Googler.

~~~
mbrubeck
...and has his own experimental C language replacement:
<http://www.zimbu.org/>

------
rsaarelm
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.

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'?

------
euroclydon
"However, in Go, any type which provides the methods named in the interface
may be treated as an implementation of the interface"

I've been wanting this in C# for a while now. Maybe one day...

~~~
AndrewDucker
Yeah, I'd kill for Duck Typing in C#.

~~~
euroclydon
I never knew what duck typing referred to. Thanks.

~~~
mbreese
(possibly redundant)

It's based upon the phrase: if it looks like a duck and quacks like a duck,
it's a duck.

In this case, if the object has the methods of the duck interface, treat it
like a duck object.

------
gchpaco
Some of the style reminds me of Alef from Plan 9; in particular the
communication channels, but also a fair chunk of the syntax.

~~~
wendroid
That will be because that's what it's based on.

------
dfarm
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.

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.

~~~
jacquesm
Have a look at some of the names behind it and see if you stick to your 'Not
Invented Here'.

~~~
dfarm
I don't think you understand what "Not invented here syndrome" means. See:
<http://en.wikipedia.org/wiki/Not_Invented_Here>

What I mean is that Google always has to do things the Google way whether
that's an improvement or not. Whether this turns out to be a valuable
contribution to the field will play out over the next few years. We'll see.
But a company that makes their own DB, their own phone, their own programming
languages, etc. is pretty much a prototypical "not invented here" company.

~~~
jacquesm
I was familiar with the term, but thank you for your attempt at educating me.

Google has some unique problems, they also have a unique position in that they
probably have pooled the largest number of IT talent world wide.

That gives them clout enough to do these things, just like Erlang came out of
a phone company (why, couldn't they have used some existing language ?) and
Apple made their own phone (I'm sure they could have afforded a Nokia or two)
google can and does have the budget to branch out in other fields.

That's not 'NIH', NIH is doing something even though better alternatives
exist, for instance, writing your own bookkeeping software when you're a mid-
sized company and you should be spending your time on serving your customers
instead of writing bookkeeping software.

Google even makes their own servers, at their levels of scale a lot of things
that do not make sense for smaller companies actually improve the bottom line.

Google suffers from many defects, bad customer support would be the top of my
list, but NIH isn't one of them, at least not in this case.

That's almost like accusing Xerox in their heyday of having NIH, and I'd hate
to think what the world of software would look like today if it hadn't been
for that.

------
vaksel
So how long before we start seeing craigslist ads that ask for 5 years of Go
experience?

~~~
jjs
2 weeks, tops.

------
johnmw
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?

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?

edit: not meaning to insult humans who like fast languages.

------
tptacek
I am not so interested in Go as an implementation platform, so much as I am in
the idea of a bridge for web programmers to real C.

~~~
mdemare
I like C, maybe it is Good Enough, but don't you think C has some real flaws
that could be fixed in a newer language?

~~~
tptacek
I think there's ~30 years of C code that isn't going away and that is going to
remain the bottom layer of most programming stacks, and it's good for devs to
be able to drop into it.

~~~
mdemare
There will always be a need for a bottom layer language, but 20 years from
now, will it still be C? I hope at some point the world will migrate to a
newer language.

~~~
jacquesm
Why would you hope that if the old language is doing just fine for the purpose
?

~~~
anigbrowl
'Just fine' is relative. The state of California still does all its financial
transactions on a mainframe running COBOL; the cost of maintenance rises every
year, but thanks to our budget deficit nobody wants to write the check for the
cost of replacement.

------
olaf
I would like to see Google "eat their own dogfood" before I invest in Go. Or
do they already use Go in production?

~~~
uriel
goglang.org runs Go.

~~~
olaf
I meant real business like GMail or similar.

~~~
ekiru
Do you want your email server to use a language that even the developers admit
isn't yet ready for production?

~~~
olaf
No, I did not write that, but since there is no serious Go-application inside
Google, their management could very easily "pull the plug" and no longer
support this experiment.

I would probably fear that, if I would invest time in learning Go.

I don't understand why the team did release Go to the public at this early
stage of development, what they expect from the developer community.

------
swolchok
Apparently, Go style is to use tabs (see go-mode.el). This is not Pythonic.

~~~
blasdel
There's also gofmt, which automatically applies the full house style using
tabs.

If anyone can bring about a tab reniassance, it's bwk, ken, rob, rsc, and gri.
These titans wrote your operating systems and your programming languages. They
all wrote their own editors (not sure about gri) -- hell, the Go tests use
_ed_!

Tabs have been lost in the wilderness for too long, it is about time they are
reborn!

------
prabodh
I am just wondering how same link got posted twice ...
<http://news.ycombinator.com/item?id=934140> ....Both point to
<http://golang.org> ..

------
nikils
might be influenced from this
<http://www.vitanuova.com/inferno/papers/limbo.html>

------
shabda
import "fmt"

what advantages this have over

import fmt

that a new language is choosing this sytax?

~~~
mncaudill
It keeps the grammar simple, for one.

~~~
shabda
IMO, Thats no reason to make me type two extra chars each time I import.

~~~
swolchok
You're a programmer, right? So you type 70-100 WPM, right? That's 5-8 chars
per second, so we're asking you for 0.4 to 0.25 seconds per imported module,
or maybe 5-10 seconds per program.

I do see the reason to design a language efficiently, but I emphatically
disagree with optimizing away small numbers of characters. Typing is a basic
skill for the job, and the overhead is dwarfed by the text of the program (not
to mention that we're making everyone type braces and semicolons).

~~~
shabda
If its a conscious tradeoff decision, doesn't it need to have a positive
however small, to counter that negative, however small? now That positive
might be "close to c++ syntax", but I am wondering if there is any other.

------
johnbender
The main selling point is compile time.

Sweet...

------
c00p3r
And finally C 2.0 sponsored by Google. Good move against Apple.

It (go + native client) might become a next major platform. Just think about
low-level (and easier to code than C[++]) Javascript alternative.

------
Krechet
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).

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..."

~~~
dchest
They already support your editor:
[http://code.google.com/p/go/source/browse/?r=release#hg/misc...](http://code.google.com/p/go/source/browse/?r=release#hg/misc/vim)
:-)

------
FreeRadical
Can someone give me some examples of where this might be used (and to do
what)?

------
Slashed
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.

------
Freebytes
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.

~~~
jacquesm
This is hacker news, learning new programming languages and learning about
them or thinking about them is part of what hacking is all about (at least for
me it is).

If you think that programming languages are a 'done deal' then try to ignore
the last 15 years or so and see what you're left with.

Sure, we're not much closer to the holy grail of programming in absolute
terms, but new languages (erlang, clojure, ruby, python to name a few) have
definitely incrementally changed the perspective we have of programming, and
have opened up more fruitful ways of building certain classes of applications.

~~~
Freebytes
When I stated "I am not interested in really learning another programming
language", I should have worded it more clearly. "I am not interested in
learning this particular programming language because it does not seem to be a
step above existing languages. It seems outdated before it has even been
released. Simply because something has big names behind it does not mean the
product is automatically superior to others. I intend to learn other
languages, of course, but I do not intend to waste my time.

