Go, Google's New Open Source Programming Language

Many readers are sending in the news about Go, the new programming language Google has released as open source under a BSD license. The official Go site characterizes the language as simple, fast, safe, concurrent, and fun. A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop. Ars Technica's writeup lays the stress on how C-like Go is in its roots, though it has plenty of modern ideas mixed in: "For example, there is a shorthand syntax for variable assignment that supports simple type inference. It also has anonymous function syntax that lets you use real closures. There are some Python-like features too, including array slices and a map type with constructor syntax that looks like Python's dictionary concept. ... One of the distinguishing characteristics of Go is its unusual type system. It eschews some typical object-oriented programming concepts such as inheritance. You can define struct types and then create methods for operating on them. You can also define interfaces, much like you can in Java. In Go, however, you don't manually specify which interface a class implements. ... Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently. ... The language provides a 'channel' mechanism that can be used to safely pass data in and out of goroutines."

Comments

Build-in function library

[sopssa]

One of the things I immediatly noticed is the lack of build-in libraries. The reason I've always preferred Delphi and C# over C/C++ and PHP over Perl is that they all come with a comprehensive build-in function library for wide area of things.

Programming now a days tend to be mostly high-level, so you would expect that new languages would provide that. I personally hate to find tons of different libraries for C++ projects just to do a basic thing. And lets be honest, theres no sense of everyone of us to code the basic functions again (and probably in worse code than the regularly checked build-in functions)

That is why I love PHP, and because it provides a great manual on its functions. That is also why I love Delphi and why I started using it as 10 year old, without internet too - the reference guide that came with it was comprehensive and the build-in libraries and components for different things allowed me to rapidly try out to code apps and games. Only time I needed to find some libraries/components was when I was looking for a more rapid and better graphics library to do the drawing in my games.

That is what would be "fun" in a programming language. It comes a lot before "fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection."

Re:Build-in function library

[Blakey Rat]

Perhaps it's designed to be embedded, like LUA or Javascript? In that case, comprehensive libraries aren't necessary or even desirable.

Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.

Re:Build-in function library

[Toonol]

If they could at least include a subset of OpenGL... or just an SDL wrapper, maybe with some high-level features for simple 2d-3d manipulation... this looks like it would be a great learning language. I see they have a DRAW library with a very limited number of features.

They also have a "spacewar" directory, currently empty...

Whenever Google announces something, you have to make the decision... jump on it immediately and get ahead of the curve, but risk wasting all that time if it doesn't take off? Or wait?

Re:Build-in function library

[Al Dimond]

PHP? Where they dump all their million built-in functions into one namespace? Lame. In Perl you have a lot more control over what libraries you pull in and how you use them -- you have to search CPAN for packages sometimes, but then you have a choice on what packages to use. And every Perl module I've pulled from CPAN has been well documented.

I can see wanting lots of libraries around in a default install back before the Internet was big. These days that stuff should be separate and the language's core should be its core.

Re:Build-in function library

[palegray.net]

Perl developers know about this thing called CPAN. PHP doesn't even come close in this regard, and you really can't get a better language reference than perldoc. Honestly, if you can't write an app using Perl's built-in functions and the thousands of modules from CPAN, you probably shouldn't be programming. While choice in languages can vary widely according to the individual coder's personal preferences and particular suitability for a given task, the weakness you've cited is imaginary.

Re:Build-in function library

[sabernet]

It's got garbage collection and limits as to what you can do with pointers for starters.

Re:Build-in function library

[palegray.net]

Didn't fail to read the parent. Perl has an immense amount of built-in functionality; I'd easily say it eclipses PHP in this regard (perusing the documentation site I linked bears that out). My points regarding CPAN is meant to point of the fact that it augments that built-in functionality in a very standardized manner, and even in cases where you might "use Foo;" a large number of those modules are distributed with Perl's core (in other words, they're installed by default).

I have to agree with a couple of your points, however. It's an unfortunate truth, but a heck of a lot of programmers do qualify as dicks. I've worked with my fair share of them over the years, and I have to say I've never met a truly gifted coder with a CS degree. I'm not saying they don't exist, but I'll be damned if I've found one yet. Oddly, out of the "real asshole" crowd, many of them had a CS degree in addition to sucking at their jobs. The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.

Re:Build-in function library

[AuMatar]

I view this as a defect, not a feature. Without competition, bad ideas and poorly implemented libraries (see large parts of Java's IO library with its 1 billion inheritances and its slow migration from old windowing toolkits) get used because its standard, where with competition they would die and better ones would quickly be written. I prefer the C/Perl system- preferably with a site like CPAN or boost that aggregates the good ones.

Re:Build-in function library

[Anonymous Coward]

I think the niche it's aiming at is the, "Look! We made a programming language, too!" niche.

Re:Build-in function library

[michaelmuffin]

They also have a "spacewar" directory, currently empty...

the documentation directory is empty, but the original pdp1 code is there as well as a pdp1 emulator to run it on: http://golang.org/src/pkg/exp/spacewar/

Re:Build-in function library

[DerekLyons]

Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.

They pretty much explicitly state that in TFA - the 'simple' and 'fun' stuff is done, now it's up to the [currently theoretical] community to dig in and do the hard stuff.
 
Of course, being Google branded and Open Source (two of the top 'auto orgasm' buttons among a huge swath of geeks) there will be, at least in the beginning, a fairly large community. I'll be very surprised if there isn't a Wiki by morning, and I'll be there's half a dozen or more Waves about it by now.

Re:Build-in function library

[MemoryDragon]

Easy, make it compile java bytecode and you probably have the biggest library around on the planet. Why a language nowadays should provide its own libraries is beyond me. That is so 90s...

Re:Build-in function library

[larry bagina]

I guess you've never used PHP.

Re:Build-in function library

[Anonymous Coward]

I've noticed a lot lately, especially here on Slashdot, that the most vocal opposition to degrees, education, certifications etc. come from people (not you in this case but it's relevant to this thread) who do not have this type of formal education in the first place.

I wonder if this says more about the US (since Slashdot is US centric) education system, the people being educated or the people not being educated. No offense, but if you've never met a competent CS graduate, you're either working in some very strange bottom-of-the-barrel outfits or with some very strange people. The CS graduates I've worked with have universally been careful, methodical and not dickish in the slightest.

Just about the only downside I've noticed is with fresh graduates who can be a little naive about business practices and real-world scenarios but they catch up far quicker than the "loner geek rebel" types whose best code at best qualify as clever but unstable and unscaleable hacks.

I'm sensing a bit of projection from the uneducated crowd, tbh.

Re:Build-in function library

[shaitand]

Well yes but not really. They built this for themselves and released it because they don't care. Google develops a lot of in-house server based internet stuff and they spend a lot of time waiting on compiles.

Re:Build-in function library

[arethuza]

Just like any other software project - not just open-source ones. Commercial software vendors end-of-life products all the time. At least with an open-source project you still have access to the source.

Re:Build-in function library

[WaywardGeek]

I think the niche it's aiming at is the, "Look! We made a programming language, too!" niche.

Agreed. I don't see a case where Go would be useful to me, given the Java, C++, Python, Perl, PHP, and C that I currently use.

My biggest rant about most of these new languages: garbage collection is useless! I still have to write destructors that clean up all the pointers to an object, and all garbage collection does is force me to call the destructor as a function, rather than a more clear 'delete' statement. Worse, it takes away my most powerful speed optimization tool: careful memory layout for best cache hit rates. I can write simple graph traversal code that is 10X faster in carefully designed C/C++ than in any garbage collected language for large graphs.

Re:Build-in function library

[dkf]

The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.

Replying to myself. Meh...

Of more concern is the fact that Go is a GCed language with a mostly implicit thread model. That means it is probably impossible to write libraries/modules in it that can be used from other languages (handling the integration of the threading and GC engines is... non-trivial). That means that the language designers probably think that they're going to be the most important and highest-level language in use in the application. Not very humble!

Re:Build-in function library

[ardor]

I still have to write destructors that clean up all the pointers to an object, and all garbage collection does is force me to call the destructor as a function, rather than a more clear 'delete' statement.

Um, no. The whole point of a GC is that you don't have to explicitely deallocate something. RAII is a problems with GCs, but you didn't mention that. As for the cache hit thing, it sounds quite suspicious to me, more details please. Also, to get that last bit of performance, you have to go low-level, that is true. Note however that explicit memory management is unnecessary in 90% of a typical application's code.

Now, since the ownership problem is passed over to the GC, things become possible that were previously hard to do. Try real closures for instance: C++0x is struggling with this, since they may extend the lifespan of a variable, which is bad if said variable was lying on the stack. Such problems simply go away with a GC. Note that C++0x rvalue references are in fact a solution to a problem caused by the explicit memory management in C++.

There is a reason many people want an opt-in GC in C++0x..

Re:Build-in function library

[danieltdp]

From Go's FAQ

There is a “foreign function interface” to allow safe calling of C-written libraries from Go code. We expect to use SWIG to extend this capability to C++ libraries. There is no safe way to call Go code from C or C++ yet.

Re:Build-in function library

[grumbel]

Kind of. The problem however is that nobody else has written a low level system language in a long while and all the low level languages out there kind of suck when it comes to concurrency programming and network stuff. So Go is really doing something that no other language out there is doing and it seems to be doing what it does quite well.

Re:Build-in function library

[Viol8]

Some of us prefer brevity and we don't or can't all use IDEs. If something like strcmp is too difficult for you to understand perhaps you should stick to VB.

Re:Build-in function library

[goose-incarnated]

I have to agree with a couple of your points, however. It's an unfortunate truth, but a heck of a lot of programmers do qualify as dicks. I've worked with my fair share of them over the years, and I have to say I've never met a truly gifted coder with a CS degree. I'm not saying they don't exist, but I'll be damned if I've found one yet. Oddly, out of the "real asshole" crowd, many of them had a CS degree in addition to sucking at their jobs. The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.

My experiences are totally at odds with that - I've not yet found a truly gifted coder who doesn't have some degree - the best that I've worked with were the physics/maths graduates, the worst were the ones who had nothing but industry certification.

Re:Build-in function library

[ewg]

Which is the approach Scala and Clojure have taken: tight integration with the Java Virtual Machine. By definition this is the "layering" mode of software engineering Pike cites in the tech talk as a reason for starting over. Layering is easier to sell to management, at least outside technology companies.

Re:Build-in function library

[WaywardGeek]

As for the cache hit thing, it sounds quite suspicious to me, more details please.

BTW, I agree that > 90% of code doesn't need to run fast or memory efficiently. I am a fan of Python, but when I'm slinging around gigabytes of data, I use C. Very few programmers ever need this kind of efficiency. Anyway, check out this table half-way down. The "DataDraw" benchmark is still in C, but it uses carefully designed memory layout. The speed improvements are 100% due to cache hit rate improvements - 15X better than when using malloc for each object. Most slow memory-intensive programs waste most of their CPU time in L2 cache misses.

You want all the fields that are accessed in inner loops to be together in memory in dense arrays, and the other stuff should be somewhere else. So, for binary tree traversal, you want left and right and maybe some key value in a small structure, and all the other bloat needs to be elsewhere. Ideally, you allocate these structures which are nearby in the tree also nearby in memory. That way, when you get an L2 cache miss, the extra data you load into the cache likely contains data that will soon be accessed in the inner loop.

Garbage collectors typically don't bother allocating objects of the same type together. Careful management of memory can be a PITA, which is one reason I use the DataDraw tool for memory-intensive applications. It allows me to "cache together" fields, and puts wrappers around data access to hide the ugliness.

Re:Build-in function library

[dkleinsc]

In fact, good accurate garbage collections could be considered the most important development in programming languages since OO (and some even think more important). For instance, without garbage collection, this will (eventually) destroy the universe (where Foo and Baz are some classes):
return Foo(somearg).bar(someotherarg);

Compare that to the non-GC'd version:
foo = Foo(somearg);
result = foo.bar(someotherarg);
delete foo;
return result;

The second version is 4 times as long, but with no added benefit other than saving a bit of memory until the next GC run.

Re:Build-in function library

[augustw]

I think the niche it's aiming at is the, "Look! We made a programming language, too!" niche.

Since one of the three designers of Go is Ken Thompson (designer of C), I would doubt that.

Re:Build-in function library

[Al Dimond]

Have you heard of TeX, the document formatting system? When you print onto 8.5x11 paper it leaves enormous margins by default. Do you know why? Because it's easier to read blocks of single-spaced text at around 60 characters per line than it is to read longer lines. The same applies to code.

Meanwhile the culture around many languages encourages programmers never to split lines. At a former workplace where we used VB, one of my co-workers worked with the IDE maximized across two screens! I always kept my lines at least under 100 characters, but when people checked in code near stuff I'd written they sometimes would go through and join my lines together.

At the same time, some of those really long lines are function calls where you don't always need to see all the arguments. Folding editors can collapse those into one line if you write them on multiple lines; it would be cool if there were anti-folding editors that could automatically break up long lines. It's similar for long formulas.

Re:Build-in function library

[cowdung]

My biggest rant about most of these new languages: garbage collection is useless! I still have to write destructors that clean up all the pointers to an object, and all garbage collection does is force me to call the destructor as a function, rather than a more clear 'delete' statement. Worse, it takes away my most powerful speed optimization tool: careful memory layout for best cache hit rates. I can write simple graph traversal code that is 10X faster in carefully designed C/C++ than in any garbage collected language for large graphs.

Wow! Your obsolete 80s mentality is mind-boggling.

GC is awesome.. it increases application throughput inmensely.. and removes the need for destructors (in most cases).

For most server based applications, GC increases the time you do actual work and reduces the amount of time doing book keeping.

But don't listen to me.. ignorance is bliss. Have a happy life in C++. The rest of the world has mostly evolved beyond that.

Re:Build-in function library

[shutdown -p now]

Easy, make it compile java bytecode and you probably have the biggest library around on the planet. Why a language nowadays should provide its own libraries is beyond me.

Compiling for JVM has its disadvantages, as it's a rather limiting VM with very tight sandbox. You don't get tail calls, for example, which throws a huge chunk of FP techniques out of the window right away. Or, say, re-invocable continuations (call/cc) - you can do that, but you have to effectively roll out your own heap-based locals/arguments stack for that, which hits performance hard. Etc.

CLR is much more powerful in that regard, because it has more features even inside the sandbox - tail calls, value types, stack-based typesafe varargs and byref argument passing - but also lets you ditch the sandbox entirely, and work with raw data and function pointers if need be. Its feature set is large enough to support a fully conformant ISO C++ implementation in it. But then, of course, you run into the problem with implementations - .NET is fast but non-portable, and Mono is portable but slow.

Sponsored by Inspector Gadget

[Yvan256]

Go Go Google Language!

I suppose this is Windows-only once again...

[Yvan256]

Go compilers support two operating systems (Linux, Mac OS X) and three instruction sets.

Can somebody call hell to see if they can host the next Winter Olympics?

Re:I suppose this is Windows-only once again...

[TejWC]

I think it supports Linux and MacOS X only because the three main developers (Ken Thompson, Rob Pike, Robert Griesemer) seem to only have those two OSs between the three of them. I know Rob Pike is a Mac user and Ken Thompson loves Unix; I am guessing Robert Griesemer likes Unix as well.
Its hard to support an OS when its not your primary computing platform.

Re:I suppose this is Windows-only once again...

[abdulla]

That's not true. You have a choice as to what OS you want to run on your desk, and what machine you want to run it on. Mac OS X, Linux and Windows are officially supported - I haven't seen anything else.

Re:I suppose this is Windows-only once again...

[cheesecake23]

It almost certainly will be frozen over, so weather won't be a problem. But with a population of 352, I suppose lack of infrastructure could be a problem for having Winter Olympics in Hell.

Re:I suppose this is Windows-only once again...

[Temporal]

Ken Thompson loves Unix

Loves Unix? Ken Thompson invented Unix. Along with Dennis Ritchie. In 1969.

So yeah. It would be kind of silly if he created something Windows-only...

Re:I suppose this is Windows-only once again...

[ioshhdflwuegfh]

or created something non-C like...

Re:I suppose this is Windows-only once again...

[u38cg]

Fan-boys, creating stuff just because it doesn't exist...

Re:I suppose this is Windows-only once again...

[iris-n]

No, no, you're getting it wrong. Ken discovered UNIX. It was there since the begining of the universe.

Re:I suppose this is Windows-only once again...

[Raffaello]

Actually, Snow Leopard is certified as well. You need to click on the link for the company, Apple, and it will show all their certified products. Here's the link

Anyone still using 10.4 (i.e., Tiger) who wants certified Unix (for whatever reason) can upgrade to either of the two leopards. Tiger is two OS revs and 4 years old at this point. Having said this, Mac OS X has been Unix compatible from the very start, with a bsd subsystem available from the very first developer previews.

Attempting to install it...

[cptnapalm]

Not having much luck. It can't find /etc/passwd, /etc/group or /etc/hosts. All of which do exist. I'm inserting fmt.Fprintf statements to attempt to figure out why it is having problems.

A novel idea: make people learn Go by requiring them to modify it in order to install it.

Re:Attempting to install it...

[dbcad7]

Permissions problem maybe ?

Google search "Go"

[sshore]

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

Re:Google search "Go"

[TejWC]

Perhaps we should abbreviate the "Go Programming Language" to "GPL"? That way, we can google for "GPL" and find Go code all over the place.

Re:Google search "Go"

[cheesecake23]

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

Yeah, why couldn't they use unambiguous names like all other programming languages, like C, Java, Python and Ruby?

Sarcasm aside, I agree that the naming is unfortunate (although I love the Go Ogle debugger pun). The parent was probably referring to the common verb, but this will also make it much harder for Go players like myself to find books and stuff for the board game. This guy isn't happy either.

Re:Google search "Go"

[Animats]

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

One could do worse. There was a language called "C+@" developed at Bell Labs. It's derived from C, with classes, dynamism, and safety, much like Java. It predates Java by a few years. Try to find it.

Re:Google search "Go"

[michaelmuffin]

the go authors have a decades-old practice of deliberately choosing annoying names "in the Bell Labs tradition of selecting names that make marketeers wince."

http://plan9.bell-labs.com/wiki/plan9/FAQ/index.html

Re:Google search "Go"

[thePowerOfGrayskull]

No, no - "Go Open Source Programming e-Language" ... GOSPeL. That would not only make it easier to find in searches, but the occasional unrelated search result would most assuredly a topic loved by programmers everywhere!

Re:Google search "Go"

[Sponge Bath]

"Og", so easy a caveman can use it.

fmt

[Duradin]

Vowels aren't nearly as expensive as they used to be back in the day.

It'd be a nice touch if they'd add vowel support in package names.

Re:fmt

[rrohbeck]

I definitely prefer programming languages with concise syntax and function names. We don't need another Java.
Maybe someone can write a preprocessor for the folks that want to bang out source by the megabyte.

Re:fmt

[Jonboy X]

People will read a piece of code more times than they will write it, so it makes sense to optimize for readability. Besides, I end up autocompleting most type/method names in the IDE anyway.

compiled in under 10 sec?

[martin-boundary]

I don't think so. I have an old Thinkpad 701C laptop which ain't compilin' this in under 10 seconds, if at all.

Not actually safe

[jfjfjdk]

From a brief review of the language and implementation, this doesn't appear to use what we've learned about correctness over the last thirty years. Buffer overflows are just one bug class among dozens, and if you're going to create a language from scratch, why let integers overflow without making people explicitly request that behavior? Why ignore what we've learned about verification and formal languages? Microsoft has actually been far more responsible about this recently, thanks to the Java people they hired (Rustan etc); see Spec# for details.

Re:Not actually safe

[thePowerOfGrayskull]

You're pretty bold giving MS any credit here. This is the home of the Google fanboi, for reasons I don't understand other than some people hope Google will take down Microsoft.

I'm an AC because of companies like google.

The most common five reasons for AC posting:

• Too lazy to register
• You have an account and overestimate how many people care about what you post;
• You have an account and overestimate the importance of your slashdot karma score as pertains to real life.
• You're a spy
• You're cowboyneal

Re:Not actually safe

[miro f]

Integer operations such as additions are incredibly quick, however you're going to be slowing your code down dramatically if you check for integer overflows with every single integer operation (unless you implement the check in hardware)

Re:Not actually safe

[home-electro.com]

Checking for CARRY flag is one instruction. Not exactly a dramatic slowing.

Re:Not actually safe

[Waffle Iron]

Checking for CARRY flag is one instruction. Not exactly a dramatic slowing.

Moreover, at least on X86, easily predictable conditional jumps (like overflow checks) are often almost free. They execute in different hardware units than ALU instructions, and often don't add to the overall clock count or latency at all.

Named after the most difficult-to-master game ever

[Culture20]

This bodes well.

"Systems" language?

[TopSpin]

They're billing Go as a "systems language." If by "system" they mean "application server in a Google data center" then I suppose that's correct. Previously the term "systems language" referred to languages suitable for operation system implementation, including device drivers, virtual memory management and other persnickety low-level software. Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions to that thinking.)

There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention. Not that trying is bad; by all means keep at it. Can't afford the mental bandwidth to jump on more new bandwagons, however.

Re:"Systems" language?

[michaelmuffin]

Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions to that thinking.)

inferno is another exception to your definition of systems language. much of it is written in limbo, a direct ancestor of go. it too has automatic memory management and no pointer arithmatic and it works just fine

http://en.wikipedia.org/wiki/Inferno_(operating_system)
http://en.wikipedia.org/wiki/Limbo_(programming_language)

Re:"Systems" language?

[Animats]

Actually, you don't need pointer arithmetic for a "systems language". Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath. You need the ability to explicitly place arrays in memory as a form of privileged hardware access, but it's not something that's used in most code.

Garbage collection, though, implies there's a layer of software underneath your code. Garbage collectors either freeze the whole program, or need some help from the MMU to track pages altered while the collector is running. Hard real time and reference counts do not play well together. Reference counted systems don't inherently have that problem, and if the compiler optimizes out reference count updates they can be efficient. But most reference counted systems are slow and dumb.

It's sad to see yet another C++ alternative that can't actually replace C++. We need a C++ replacement. C++ has stagnated. C++ is the only major language to have hiding ("abstraction") without memory safety, a bad combination never tried again. Strostrup is in denial about this being a problem, and the C++ standards committee is of in template la-la land, fussing over features few care about and fewer will use correctly.

The previous poster is right, though. This is a language for writing applications to run on servers. Google needs something less painful than C++ and faster than Python. (Python is a reasonably good language held back by an archaic naive-interpreter implementation. Making Python fast is hard, though, because the compiler has to do type inference to figure out the variable type information the user isn't asked to provide. ShedSkin shows that can work, but that project only has one person on it.)

Re:"Systems" language?

[ClosedSource]

"Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath"

Or customers above either.

Re:"Systems" language?

[Toonol]

"Open Source" for the geeks, "Google Branded" for the techies, and "Apple" for the wanna bees?

Re:"Systems" language?

[Vintermann]

You can get pointer arithmetic in Ada, as long as you sign the proper disclaimer of warranty forms and send them to the DOD in triplicate.

Seriously, you can get pretty much anything in Ada, it's just that you need to be very, very verbose about the things you really shouldn't be asking for.

Re:"Systems" language?

[ardor]

You cannot shoehorn a GC into C++. Explicit memory management is so tightly coupled to C++ that most attempts at introducing something automatic automatically impose significant restrictions on what you can do. This is OK for specific scenarios, not OK for a core language component.

Also, generic programming and template metaprogramming are one distinct advantages of C++ over other languages. The ability to metaprogram and use structural typing there is priceless, and some forms of metaprogramming are quite common in languages like Javascript, Lua, Python, Ruby, Lisp, Haskell. Without such features, C++ becomes little more than a Java without GC. No wonder the C++ committee put their focus on them.

I do agree however that a replacement is needed. Compile times are awful, memory usage while compiling goes through the roof, compiling errors fill several pages, the syntax is an abomination (especially in metaprograms), and it does not even have an optional GC.

Re:"Systems" language?

[SharpFang]

I could see it as a 'system' language as in 'write applications in it'.

Not scripts, not embedded functionalities, not CGI, and no, not servers.
Just a typical "double click to start" applications that you install on your desktop computer, which serve a thousand various purposes. The kind of stuff you write in Delphi or Visual C++. Fast and easy to write, fast and easy to run. Not too far from the OS to require squeezing through 50 abstraction layers, not too raw to bother with kernel routine calls to do basic stuff. Not too abstract and high level to slow it down to a crawl like Ruby, not too low-level to be overly dangerous like C.

It's placed somewhere between C and C++ on the "level highness" scale, doing some things that were long overdue in C++ natively, but not compromising performance for stuff like advanced inheritance, exception handling and such.

Re:"Systems" language?

[Animats]

You cannot shoehorn a GC into C++.

Actually, you can. See Microsoft Managed C++. But it's not happy. Destructors and garbage collection do not play well together. Calling destructors from the garbage collector introduces a kind of concurrency which leads to difficulties if the destructor does something non-trivial, like close a window or a file.

Re:Wonder?

[michaelmuffin]

Does Go have goto statement ?

why wonder when you can look it up? http://golang.org/doc/go_spec.html

tl;dr yes, it has goto

Re:Named after the most difficult-to-master game e

[cheesecake23]

The game may well be the most difficult to master of all games in history, but it is simultaneously one of the easiest to learn and to enjoy. Which actually does bode well for the language. If Go (language) is to C as Go (game) is to chess, then they nailed it.

But, as I just posted in another thread here, there are other problems with the naming.

C++ incomplete. C# windoz. Java slow elephant.

[upuv]

I've been around for a long time.

C great language did exactly what it was designed to do. But carries a lot of burden.
C++ come on it didn't even have a string class. Thus pointer math hell.
C#, Ok it learned a lesson and found the joy of a string class. But really it's a windows only lang.
Java. Excuse me web apps that take 8Gig of ram spread across a farm of servers. This slow elephant remade the hardware business.

All of the above never really understood concurrent / multithread / parallel. ( Sorry Java devs still have issues with the concept. GC & log4j come to mind as things that forgot they were in a threaded env. )

So the "Go" lang it just might deserve a look. Clearly web centric. Clearly built for tons of concurrent comms. Recompiles in a blip thus useful for real time compiling alla jsp. I'm very performance centric. If I can replace my J2EE bloat ware with a trunk full of tiny Go apps I will.

I'm definitely watching this space for developments.

Fixes problems misguided people think C++ has.

[pslam]

Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?

Why was that so easy and quick to say? I really don't understand the repeated banging-head-against-wall that language inventors are doing. There's a good reason why C++ is still in wide and very popular use: precisely because it does have explicit memory management and pointer arithmetic. C++ is a static, explicit language. Go is not. It will not replace C++, and no language will until that is understood.

The problems C++ need fixing are elsewhere. The syntax needs cleaning up. The ABI needs rationalizing between architectures. Multiple inheritance needs some taming (ditch 'virtual' multiple inheritance - it's insane), but not removing. Interface-only classes need promoting to a full type rather than inferred from being 100% pure virtual (and even then there's usually a non-pure-virtual destructor for stupid foot-bullet-avoiding reasons). There needs to be saner syntactic sugar for repeated operations (like python's 'with' keyword). Templates syntax needs to be less verbose and more automatic (already being worked on for C++0x but at this rate will be C++1x, keyword 'auto').

Stop trying to replace C++ with a language that does not fulfill every aspect C++ covers. If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.

Re:Fixes problems misguided people think C++ has.

[TheTurtlesMoves]

If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.

Because if you can't do that then you can't do anything right?

Heres a novel idea. Use a language as a tool, and use the right tool for the job. If you are writing an OS perhaps you need *explicit* access to pointers, or if you are doing something with MMU you would need a asm{} section (thats not C++ either). But when i want to write a application server then that requirement is lame and garbage collection and better memory models frees the developer and compiler (escape analysis etc) to do a lot more of the relevant work.

We are not all writing an OS, so why the hell do we all need to be using a language that can write an OS? Just like all welders are not all welding Aluminum so they don't all need fancy TiG welders (just like we don't always need to use car analogies).

Re:Fixes problems misguided people think C++ has.

[gpuk]

Have you considered the D Programming language?

From http://www.digitalmars.com/d/ "D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++. "

Re:Fixes problems misguided people think C++ has.

[fnj]

The garbage collection haters and garbage collection lovers will never see eye to eye. Your parent is NOT wrong. He's probably just doing things you're not (and vice versa in all likelihood).

Smart pointers basically trivialize the so called "problem" of memory management and exception safety in C++. Simply put, it's NOT a problem. Before the boost library came into use it took SOME discipline, but nowadays it's just dead straightforward. A real time embedded programmer wants control over memory management. He can't tolerate garbage collection compromising his execution scheduling deadlines. It's a lot more than just Doom 8. It's your car. It's the airliner you ride in. It's process control.

Couldn't agree more with your last paragraph. These are the REAL places C++ falls flat on its head.

Re:Fixes problems misguided people think C++ has.

[bbn]

If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.

So there is zero assembler code in the Linux kernel because C can do it all? Not so.

You do not need explicit memory management or pointer arithmetic to do these things. To write a device driver you might need the ability to access memory directly, but that could easily be done by mapping the memory region to an array.

There are incremental garbage collectors that guarantee real time performance.

It would probably be a huge benefit if the OS was written in a better language than C. One that takes a whole host of bugs out of the equation by not allowing manual memory management and pointer arithmetic.

Re:Fixes problems misguided people think C++ has.

[rusty]

> Stop trying to replace C++ with a language that does not fulfill every aspect C++ covers.

Err, no (how did this get +5?) C++'s entire problem stems from the attempt to Be All Things. A far better approach is to design something that does one part of things well, and interoperates with C like everything else so you can glue stuff together.

They've subtracted, not added. This is the Right Thing to have done.

Rusty.

Re:Fixes problems misguided people think C++ has.

[AReilly]

What on earth do you need multiple inheritance, virtual functions and templates for if you're writing a memory management system or interrupt handler?

The problem with C++ is that it keeps C++ programmers from moving on to more productive languages with more support for real abstractions, by having them believe that they should use it to write the tiny amount of code that would be better written in C.

Get over it: you've got a perfectly useful set of interrupt handlers and memory management in your favourite OS and runtime. Write the useful code in something that will *leverage* that, rather than re-inventing it over and over again.

Maybe C really is "it" for now...

[cgenman]

Despite the large amount of enthusiasm for language design, modern mainstream programming languages don't fall far from the C tree.

Perhaps, like Qwerty, our C-based languages have evolved to be "good enough" for programming needs for the foreseeable future. Make objects, make functions, operate between the two.. sure DVORAK might provide 20% faster typing if you work at it for 3 years, but that's not really enough to warrant the switch. We're unlikely to see a jump again of the size from C to C++ before we hit a major structural change. I had thought the web might be that structural change, but that was well absorbed by extending existing ideas.

Personally, I just want to see programming languages that are more programmer fault-tolerant. I can type "pizza" into my phone and have Chuck-E-Cheese offer to bake one while I drive over, but if I accidentally type "plaeyrArray" instead of "playerArray," the whole world is clearly on fire and everyone is going to die. Why can't compilers be more intelligent about the types of errors they encounter in routine usage? For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

Re:Maybe C really is "it" for now...

[Toonol]

why are we still defining code chunks via brackets instead of the indentation that's already there?

Because enforcing strict rules about indenting and how it's interpreted is more oppressive and error-prone than using brackets? I agree with your FIRST paragraph...

Re:Maybe C really is "it" for now...

[Imagix]

For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

Are you insane? Have you ever written a parser? And being dependent on particular whitespace is really asking for trouble. Now, are those tabs or spaces? How many spaces? One of the earlier languages had position dependent coding (code had to start on column 3 or something like that. The name eludes me at the moment).

Re:Maybe C really is "it" for now...

[Anonymous Coward]

if I accidentally type "plaeyrArray" instead of "playerArray," the whole world is clearly on fire and everyone is going to die.

I know what you're saying, but I think the answer is broadly that you might have meant plaeyrArray. Every so often xkcd nails one, and there's one that says "You'll never find a programming language that frees you from the burden of clarifying your ideas." It's because computers will do anything that you ask them to that you have to be so specific. And I'm sure you know that, but it's worth pointing out. Language designed to be easy, like VB, end up being almost unusable for certain tasks because their treatment of basic stuff creates lots of little edge cases. Is this a zero or a null? I don't know...what does the language think it should be in this context?

PHP is pretty tolerant of little faults, but it's also a huge mess. I haven't used it a whole lot and just recently found out my program's been logging warnings like crazy because I didn't initialize a variable, but PHP only warns you over this. Not the end of the world, but I find it annoying. It's more important for a language to be consistent, I think...when you try to make it "intuitive" you end up with a subjectivity problem. Everyone has a different mind and they all want you to read them. Then the next guy (probably me) says "why in the hell would it work like THAT?". But consistency can be quantified.

Why can't compilers be more intelligent about the types of errors they encounter in routine usage? For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

I'm not being facetious when I suggest that you immediately play around with Python. It's not just the whitespace thing, but it happens to be indicative of why Python's such a joy. You're already delimiting spaces with an LF character, so aren't you just repeating yourself with a semi-colon? Of course you are. Taking it further: in Python you can still put two lines of code in one line of text, just like any other language, and you can also break one line onto two. But it's treated as the exception (which it is), rather than the rule, and for things not already enclosed in parentheses, you break them onto two lines by (wait for it...) escaping the LF! I dunno, there's something about that that just makes me smile. Python is full of neat little things like that.

Not to mention an extensive standard library with the documentation baked in, built-in debugging and profiling tools, and an interactive prompt for testing out one-liners and reading the docs. It doesn't seem like it at first but you end up missing the prompt dearly when you code in other languages.

Obviously language syntax isn't, or shouldn't be, a dealbreaker, and Python already gets too much press for being a language where whitespace matters when that's not a big deal, so please don't misunderstand my reason for bringing it up. I just find that it's representative of the whole picture: Python makes things simple that should be simple, but not by being inconsistent.

Re:Maybe C really is "it" for now...

[shaitand]

Not if you already know QWERTY... or use computers you don't own on a regular basis.

Re:Maybe C really is "it" for now...

[rfreedman]

For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

Like in Python?

The reason that I still like my curly-braces is that I don't want the meaning of my code to change just because somebody (me?) changed the whitespace.

Instant Language Build-O-Matic

[Tablizer]

Joy, yet another programming language :-) Programming languages are personal. We all have our favorite way to do things and most of the choices are subjective preferences. At c2.com we played around with the idea of a Build-To-Order form to generate a compiler/interpreter for a language with the combination of features you ask for. Below is a rough re-creation of the form:

-----INSTANT CUSTOM LANGUAGE FORM-----

(Features in each group are mutually-exclusive if they have round brackets, but not if square brackets. )

Compile Level

* (__) Compiled: product of language targeted to direct run by a machine (possibly a virtual machine) or operating system.
* (__) Interpreted: language is processed as data by a process called an interpreter, especially in some sort of ReadEvalPrintLoop. May support a hidden JustInTimeCompilation, but that should be considered an implementation detail rather than a language detail.
* (__) Both but select on Program: language allows programs to be written for scripting or written for compilation, but programs written for compilation might not work for interpretation (e.g. due to late-binding dependencies) and programs written for interpretation might not work for compilation (e.g. due to top-level commands). This provides a lot of flexibility. However, it also partitions the user community because sharing will be difficult.
* (__) Both for any Program: language ensures that every program is suitable for both compilation and interpretation. Supporting interpretation requires abandoning a model of external linking and requires ensuring the syntax is suitable for one-pass reading (i.e. preprocessors are a bad thing). Suitability for compilation implies abandoning (or at least distinguishing) imperative commands at the toplevel: those that are to be executed at compile-time vs. those that are to be executed at runtime.

Model for Linking and Modularity

* (__) No Linking: product is always fully declared from a single page or file. No linking occurs. There is no model for modularity. Many EsotericProgrammingLanguages have this model. Support for CompileTimeResolution may provide an interesting workaround.
* (__) Includes: product may 'include' other pages, which are linked in place. There might be a system to selectively avoid duplicate includes. All pages are effectively parsed with each compile or execution.
* (__) Single Page, Modular: language semantics allow 'importing' or 'loading' of other components. Allows useful optimizations such as compilation of components... or at least preprocessing and pre-parsing, of language components, because the semantics of the 'import' are held independent of the page into which it was imported.
* (__) External Linking: a linker can combine a product by pulling multiple components together, but does so from outside the language. This model is incompatible with interpretation, and offers no real benefits over the 'Single Page, Modular' model except that it can be hacked into a language that doesn't have a concept of modularity (as was done for CeeLanguage).

Modularity and Linkage Features

* [__] Resolution of Circular Dependencies: the language or linker will correctly handle circular dependencies, ideally with minimal reliance on forward declarations.
* [__] Provisionals and Overrides: the language allows you to override global objects, values, or procedure that are declared in other modules in a manner such that those other modules use the overrides, too. Ideal form would be as though they had always used the override, but this ideal form is somewhat difficult to reconcile this feature with interpretation.
* [__] Inverted Constructs: one can automatically bui

Holy Shitbags Binaries Are Static And *Huge*

[FrankDrebin]

$ cat hello.go
package main

import "fmt"

func main() {
fmt.Printf("hello, world\n")
}
Size of resulting binary: 581054 bytes on x86 Linux.

Re:Holy Shitbags Binaries Are Static And *Huge*

[Cthefuture]

Uh, so they don't have a dynamic linker yet. Consider this:

$ cat hello.c
#include

int main(int argc, char* argv[])
{
      printf("Hello, world!");

      return 0;
}

$ gcc -O2 -static hello.c

a.out is 688272 bytes (x64_64 Linux)

Until they have a dynamic linking system, who knows.

more languages than programmers

[OrangeTide]

It's simple. It's a lot of fun to design and even implement your own programming language. It is not too hard, depending on how big of a problem you choose to bite off with your language. And then there are the oohs and ahhs you get from other developers when you have implemented a language, especially if it compiles to some real or virtual architecture.

Too bad learning to use a programming language effectively is a lot of work, and is usually pretty frustrating. It has been easy for me to find the time and energy to implement my compiler. But I totally don't have the time to learn C++, Haskell, Python, OCaml, Ruby, PHP, Perl, et cetera.

As a developer, and I realize this is a very silly and irrational, I tend to avoid using programs written in languages I don't understand. True, I almost never look at the source for the program. But take Gentoo emerge for example. The fact that it is written in Python instead of C, awk, shell script, Tcl, Lua, or Java is mainly why I don't run Gentoo.

Re:more languages than programmers

[shaitand]

"is mainly why I don't run Gentoo"

Fascinating. Personally I don't run Gentoo because compiling the entire system takes more extra time than the added performance saves me over the life of the install.

Re:more languages than programmers

[wdef]

Do we *really* need more languages? At university I learned Fortran, Pascal, Assembly, all of which stood me in good stead for later learning and have never really gone away. I had just got competence with Perl when I worked out that the many young developers use nothing but Python for things that I would use Perl for. I enjoy Perl. But if I want to go deeper into programming in certain areas, I will have to learn Python. I know Python has certain advantages and is probably easier to read but Perl is enormously powerful and fun. I taught myself C by doing various hobby projects sporadically over a year or two. You can see the bottom (or the end of the tunnel) with C since it's a simple language with few features but is difficult to use properly. Gradually you get more craft. Tried starting C++. What a mess. It's no wonder a guy I work with, one of the best C programmers in his field in the world, absolutely *hates* C++, as does Linus Torvalds. I mean, did they really make this mess on purpose? Apparently so. Learning a programming language properly is a real commitment. Some are easier than others. The case for this damn Google language needs to be pretty darn convincing before I'm going to even look sideways at it. Mere buzz words and fashion is not enough anymore. It just takes too long to take on YAS (Yet Another Syntax).

"Go" name already taken for programming languages

[qw0ntum]

This fellow has been working on his own programming language, also called "Go", for a decade. Even released a book about it. He filed an issue in the tracker for the Google language: http://code.google.com/p/go/issues/detail?id=9

Lightweight languages do not remain lightweight.

[reporter]

Ars Technica writes, "A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop."

If this language becomes as popular as Perl, then 120,000 lines will soon become 1,200,000 lines. That is exactly what happened to the Perl interpreter and compiler.

Also, just like Java, the new Go language (due to the immense respect for Google's scientific prowess) will likely receive accolades: "it is the best, final language that we will ever need". The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture. Upon the introduction of Java, company after company blindly adopted it.

Was Java the final language satisfying humankind's computing needs? No. Was adopting it worth the cost? Maybe.

Now, we have Go. Is it a massive improvement over C and Java, thus justifying spending milions of dollars to train programmers? Only the future will tell.

No Exceptions?!

[CarpetShark]

tl;dr yes, it has goto

But apparently not exceptions? It sounded good in theory. Lack of assertions was going to bug me. Lack of exceptions and try...finally blocks is most likely a deal-breaker. I'll read the thing in detail at some stage and see if they provide a decent alternative though.

Found it...

[CarpetShark]

Found confirmation of this in Go's "Language Design FAQ":

Why does Go not have exceptions?

Exceptions are a similar story. A number of designs for exceptions have been proposed but each adds significant complexity to the language and run-time. By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. There is also concern about the effect they would have on the libraries. They are, by definition, exceptional yet experience with other languages that support them show they have profound effect on library and interface specification. It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow that requires every programmer to compensate.

Like generics, exceptions remain an open issue.

So in other words, they left every single user of the language to do it, over and over again, because it seemed like a lot of work for the team to do well, once. Sorry, but that just doesn't cut it.

As for exceptions increasing control flow compensation... Java had this right; if a function's interface specifies what it throws, then you by definition save yourself a lot of control flow headaches, as you know exactly what calling a function can result in.

Re:Found it...

[azgard]

Actually, it would be much better if they add signals (like those in Common Lisp) instead of exceptions, as they are more general concept. But I can understand it's hard to see from Java land.

Re:Found it...

[moosesocks]

So in other words, they left every single user of the language to do it, over and over again, because it seemed like a lot of work for the team to do well, once. Sorry, but that just doesn't cut it.

Um. Did you read the text you just quoted? They didn't say anything of the sort!

To paraphrse: Go is still a work in progress. It is our opinion that exceptions are computationally inefficient, and interfere with concurrent programming. If we implement something similar, we want to do it right the first time around. We are currently considering various methods of accomplishing this, as well as the impact of not implementing it at all.

This, to me, sounds like an excellent way to design a programming language. Of course, there is going to be some backlash against any language that questions C's status as the "one true language," although most of the items in Go's feature list seem like they should have blindingly obvious in hindsight.

Also, consider that C++ doesn't implement strings, and leaves the programmer to do it himself. STRINGS!

(Go, by comparison acknowledges that a single, good string implementation will work for 99.99999% of programmers, while also doing nice things such as supporting UTF-8 out of the box)

Re:Wonder?

[Anonymous Coward]

It doesn't have comefrom though.

We'll have to wait for Google to independently rediscover it.

mod parent insightful

[heson]

Finally, a C++ user giving clues for a better C++, instead of the usual ones from non users.

Re:"Go" name already taken for programming languag

[malakai]

No, his is simply "Go!" with an exclamation. See: http://portal.acm.org/citation.cfm?id=998367

Google is screwed, they'll need to change their name for this language or buy this guy off. If they ignore this guy they'll look like a bully.

It's amazing no one at Google did a search go "Go Programming Language"

Skeptical thoughts

[jma05]

I watched the presentation. It was about time for Google to join the programming language space, but I was not impressed as much as I had been with other Google projects.

Go is fast: Sure. But compared to what? C and C++? They were never known to be fast compiling languages. Go is still a very simple language. So compilation speed is not impressive, relevant or novel *yet*. I recall from my Pascal (Delphi) days of how blazingly fast the compilations were when the language did not have a pre-processor or generics and had a more strict type system. Once Go gets generics and exceptions, we can see how well it compares to similar modern languages.

Go is safe: I somehow kept seeing OCaml in a C style syntax in all this despite Go not being functional (perhaps I am just sleepy :-) ). Better type system, garbage collection, optional typing, higher data types. Imperative Ocaml also only takes a minor performance hit compared to C despite providing a much safer language.

Concurrency: This could be something. The languages with built in support for this are somewhat obscure ATM (Erlang). Hopefully, Go will be more palatable to the mainstream.

Programming languages are finally more than grammars and compilers. Many excellent languages never make it to limelight. C and C++ continue to be first choice for system software despite the existence of several excellent "language" alternatives. Google brand may help Go with an early boost, but it will be the tools, libraries and the community that will have to deliver it; or we will just have another Java FXScript story in front of us.

FYI: Array slices

[UnderCoverPenguin]

Array slices and mapping types have been around for decades. Not even Perl was the first to provide tham, et alone Python.

Re:use Microsoft then...

[jrumney]

It's hard because in most cases you want strings to be efficient in terms of both memory and performance, so it is best if they are fixed size - easiest if they are immutable. So you have a separate class (StringBuilder in C#, StringBuffer in C++) which is a mutable string with all the inefficiencies of having to reallocate its storage as the string grows, and an efficient conversion into an immutable String object for when you've finished building it and want it to be efficient in terms of storage size and operations carried out on it.

Re:"Go" name already taken for programming languag

[CrashNBrn]

Because C# was screwed.
And C++ was screwed...
And JavaScript couldn't be called JavaScript because Java existed.

gofmt

[CharlyFoxtrot]

From Golanf.org : "With Go we take an unusual approach and let the machine take care of most formatting issues. A program, gofmt, reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments. [...] We use tabs for indentation and gofmt emits them by default. Use spaces only if you must."

Of course you realize ... this means war.

Do *not* optimize for readability (do a tradeoff)

[jonaskoelker]

People will read a piece of code more times than they will write it, so it makes sense to optimize for readability.

If you can make the code 1% more readable (pick your measure) at the cost of making it take twice as long to write, is that worth it?

If you can make the code 1% less readable and simultaneously make it twice as fast to write, is that worth it?

Also, it's a particular name we're talking about. Is python unreadable because it says "len" instead of "length"? Is it bad to say "IndexError" instead of "ArrayIndexOutOfBoundsException"? Is it bad to say "" instead of "System.out."?

Of all things, I think names (with vs. without vowels) have the smallest impact on readability. Descriptive names are important, but I think it's much more important to be able to write code that has an easily comprehensible structure.

Not Invented Here

[nut]

Google is developing a real, 'Not Invented Here' complex. Rather than get behind Firefox, they produce their own browser. Rather than integrate tightly with OpenOffice, they produce Google Apps. Now they've written their own programming language. Go figure. And of course there's always those rumours of the Google OS...

Re:Named after the most difficult-to-master game e

[mr_gorkajuice]

I wonder if the chinese name for the programming language will be Weiqi, just to screw us over.

Oh, I see.

[jotaeleemeese]

So the guys at Google, could not be bothered to, er, google for "go language" or "go programming language" out of politeness, so the other guy has to suck it up for being just him, a one man band.

What a wonderful concept of decency and fairness.

Re:"Go" name already taken for programming languag

[Tim C]

Actually JavaScript being called JavaScript was a hideous decision - even now I read comments from people who think it's something to do with Java.

Re:Do *not* optimize for readability (do a tradeof

[miro f]

I find that if you shorten long words arbitrarily, it actually increases the writing time.

I could write ConnectionManager pretty quickly just due to typing experience in English. The words just flow from my brain onto the keys without even thinking about the individual letters. But if you shortened to CnnctnMgr then you have to think about it every time you type it out, what letters have I taken out again?

It gets more difficult when you're working off someone else's code. If you shorten long words but not short words then later on when you're looking at new code it takes much longer to get used to variable names. If you stick to a convention and don't shorten any words, you sometimes don't even need to see the variable being used to know what it's called, and can use them without thought.

ArrayIndexOutOfBoundsException is clearly a poor joke, however. I always hated that one.

Works fine in python, Makefile

[jonaskoelker]

Are you insane? Have you ever written a parser?

I've written my share. And I've read (and, I think, understood) how python does it.

Really, it's not that bad. Simply look at each line and see if it's indented more than the previous; if so, add an OPEN_BRACE token; if less, a CLOSE_BRACE token (or call them OPEN/CLOSE, BEGIN/END, etc.). Then, once you've transformed the indentation structure into tokens, parse the rest.

You can probably do it faster if you do it on the fly (i.e. at the same time as "parse the rest") rather than in two passes, but the idea is more easily comprehensible this way.

Also, my practical experience with writing loads of python and more than my fair share of Makefiles suggests that it all Just Works (tm).

At least as long as you don't mix tabs and spaces. It's quite easy to write a shell script which tests for this and warns you. Also, any decent editor with an embedded lisp dialect can be made to highlight tab/space mixes (or just run your shell script in the background).

Why the big worry?

No templates, no party.

[master_p]

Templates is one of C++'s advantage over any other language (except D that implements them). Without templates, type safe containers and reusable algorithms cannot be implemented. For example, in Go, a List class would have to use void* types, throwing type safety out of the window.

The syntax is also not that good. That the type goes after the variable name, the missing parentheses in 'if' and 'for' statements are syntactic changes that offer no better readability over C.

Finally, the built-in channel mechanism is something that can be done in C++ in less than 100 lines of code.

Re:No templates, no party.

[daid303]

../test.cpp: In destructor ‘std::pair::~pair()’: /usr/include/c++/4.3/bits/stl_pair.h:73: instantiated from ‘void __gnu_cxx::new_allocator::destroy(_Tp*) [with _Tp = std::pair]’ /usr/include/c++/4.3/bits/stl_tree.h:390: instantiated from ‘void std::_Rb_tree::_M_destroy_node(std::_Rb_tree_node*) [with _Key = int, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare = std::less, _Alloc = std::allocator >]’ /usr/include/c++/4.3/bits/stl_tree.h:943: instantiated from ‘void std::_Rb_tree::_M_erase(std::_Rb_tree_node*) [with _Key = int, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare = std::less, _Alloc = std::allocator >]’ /usr/include/c++/4.3/bits/stl_tree.h:585: instantiated from ‘std::_Rb_tree::~_Rb_tree() [with _Key = int, _Val = std::pair, _KeyOfValue = std::_Select1st >, _Compare = std::less, _Alloc = std::allocator >]’ /usr/include/c++/4.3/bits/stl_map.h:92: instantiated from here ../test.cpp:11: error: ‘testObj::~testObj()’ is private /usr/include/c++/4.3/bits/stl_pair.h:73: error: within this context /usr/include/c++/4.3/ext/new_allocator.h: In member function ‘void __gnu_cxx::new_allocator::destroy(_Tp*) [with _Tp = std::pair]’: /usr/include/c++/4.3/ext/new_allocator.h:118: note: synthesized method ‘std::pair::~pair()’ first required here

Because templates are wonderful!

Er...?

[Kupfernigk]

Chrome is based on Webkit and optimised for Javascript, which is Google's delivery tool of choice. OOO was never going to be suitable for running as a cloud application. The Google OS seems to be tight integration of Linux and Chrome. Go seems to be basically the start of an improved version of C, rather than an improved version of C++.

You seem to be complaining because Google is working on technologies which are not your technology of choice. But far from an NIH, they seem to be giving serious traction to existing technology which best suits their needs.

Re:Named after the most difficult-to-master game e

[glwtta]

I think they just chose the name so they can use their page numbering convention for future versions:

version 2: Goo
version 3: Gooo
etc.

I will probably mature around the time Goooooo comes out - can't wait to use it!

No exceptions? Really?

[RzUpAnmsCwrds]

Go seems to suffer from the problem of not being done. Case in point: exceptions.

Google's C++ style guide forbids exceptions. This is because of historical reasons - Google's codebase is not exception-tolerant.

Because Go doesn't have exceptions, programmers won't write exception-safe code. Since Go is garbage-collected, this is less of an issue compared with C++, but there are still cases where things like file handles or external resources need to be cleaned up.

Two, three, or four years down the road, it's going to be hard to use exceptions in Go, because the existing code that's out there won't inter-operate properly with code that throws exceptions.

In my opinion, exceptions are absolutely, positively critical in a modern imparative programming language. Exceptional conditions happen. Parsers get data in the wrong format. Network requests time out. Hardware fails.

There are some exceptional conditions that should never happen, and if they do they should kill the system and print something that lets you track down the problem. Exceptions provide this behavior for free; simply don't catch them and you get at least a stack trace when they occur.

The alternative is to write a bunch of error handling code to print out debugging information and exit. Then you call it from everywhere that one of these critical errors occurs.

Except, what if you want to handle one of these critical errors? What if you're calling code that exits if it fails, but you want to report errors in a different way? What if the exceptional case is supposed to happen, like if you're writing unit tests?

The other type of error isn't critical. Maybe it's a network timeout or a parsing error, neither of which should probably crash the system (in most cases). Here, you want to handle the error and take some action, like re-sending the data or asking for input from the user again.

Error codes work here, except that they're cumbersome. Want to include information on exactly what kind of a parser error occurred? Now you're going to have to return both an error code and an error string. Maybe you'll even return an error object.

What if the error occurs in a private method (lowercase first letter in Go) that's called by the public method (uppercase first letter in Go)? With exceptions, you just throw in the private method. With error codes, you need to check for an error code in the public method when you call the private method, then pass the error along.

Re:No exceptions? Really?

[RAMMS EIN]

``Have a look at the Go Language FAQ. It states very clearly why exceptions were not added to Go.''

Yes, I've read that since. I hadn't bothered to read the whole thing before posting. :-)

It seems to me the reason Go doesn't have exceptions is that "we haven't figured out a good way to implement them yet".

``Have you ever considered, from an assembly language perspective, what exception processing looks like? How handling of multiple stack frames might take place?''

As a matter of fact, yes. I am the creator of the Voodoo programming language, a low-level language intended to be used as an intermediate step to native code generation. I am currently working on mapping the constructs of my Mana programming language (which, alas, is mostly documented on paper as of now) to Voodoo. That includes exceptions, restarts, continuations, closures, tail calls, garbage collection, the whole enchilada. Exceptions aren't exactly straightforward to implement (they break call-return control flow), but it's work you only have to do once and that will save users of your language a lot of headaches. "It's somewhat difficult to implement" has never been a good reason not to have a good idea in a programming language, especially if it _has_ been done before.

``If you want languages that provide safety then you must sacrifice speed.''

Is that so? Care to back up that assertion with some argumentation?

``I, personally, have never found myself enamoured by exception handling. It has its conveniences but you may well find many old school programmers find themselves content without it.''

Oh, I manage just fine in languages without exception handling, too. I'd also manage just fine if all I had was an assembler. In fact, I've done just that for years (back when there wasn't Internet access where I lived). But that doesn't mean I don't think high level languages or exceptions aren't a good idea.

Re:No exceptions? Really?

[SlashDotDotDot]

Go seems to suffer from the problem of not being done. Case in point: exceptions.

The authors at least partly agree with you. They describe the absence of exceptions here. They consider it to be an open issue.

On the other hand, they already provide an alternative to the "finally" block of an exception handler: the defer keyword. I like the looks of this, as it means you can handle all of your closing and locking kinds of issues in a direct pairing with the corresponding open or lock, regardless of whether the function terminates early due to error conditions.

Re:C++ incomplete. C# windoz. Java slow elephant.

[marco13185]

C# is not a windows only language at all. Mono is a pretty complete implementation of the .NET Framework on Linux (with some good progress on OS X). A lot of really cool apps, such as Beagle, Banshee, F-Spot, Tomboy, and Gnome-Do, are written for Mono.

std::string and std::basic_string

[tepples]

The STL (T stands for Template!) has nothing to do with the strings library.

The C++ standard library consists of the C standard library, the iostream library, and the STL. In the STL, std::string is a specialization of the template class std::basic_string.

You must have missed the Go specification...

[flithm]

C++'s templates offer a lot more than just generics (which is what you're talking about when you say "type safe containers and reusable algorithms"), however Go does, in fact, provide for this with its "interfaces." The Go interface affords for both data abstraction (akin to C++'s inheritance hierarchy), and generic programming. Go provides an "Any" container, which "may be used to implement generic programming similar to templates in C++".

It's worth noting though that this is a dynamically bound language feature, which means it is checked and enforced at runtime rather than compile time -- both a positive and a negative depending on how you look at it. It provides for some more interesting programs to be written that do fun things at runtime, but on the down side it means you lose a lot of the compile time type-checking that C++ provides and can save a lot of debugging time later on. It also means that you can't do any template metaprogramming with Go -- again which can be viewed as a positive or a negative.

I also challenge you to come up with a solution that equates to Go's built in Channel's in less than 100 lines of C++. What you're actually saying is you "can implement Go's Goroutine's AND Channels in less than 100 lines of code in portable, cross platform, C++". But, let's give you the benefit of the doubt and say that you've already go some mechanism for emulating a Goroutine (which by the way allows one to "mutiplex independently executing functions onto a set of threads"). I think _just_ the thread safe code that would implement all the necessary locks and barriers for a _single_ platform would probably be more than 100 lines, and would not be portable (ie, it would be pthreads, or win32 specific).

I am open to being wrong about that, but I really do believe that you haven't spent much time investigating Go, and are therefore spreading FUD. For example your assertion that "in Go, a List class would have to use void* types, throwing type safety out of the window" is just plain wrong.

I should also point out that I am in no way a Google Go fanboy. I see it as a pseudo-interesting low-ish level language that I haven't quite been able to envision the proper use for yet. I don't really buy Google's claim that it's a system level language (I can't see myself wanting to write an OS or device driver in it). To me it seems more like a great way to rapidly build efficient client / server type applications.

Re:Do *not* optimize for readability (do a tradeof

[iris-n]

Bad example. "len" was chosen to stop people typing "lenght", not to be shorter.

Re:"Go" name already taken for programming languag

[LaminatorX]

Two "Go"s considered harmful.

What has the world come to...

[jchandra]

Ken Thompson, who invented Unix, creates an experimental new language with Rob Pike et. al. and Slashdotters try to overdo each other in pissing all over it.

Nice.

Tell you what kids, try learning something for a change. And show some respect.

Re:What has the world come to...

[BitHive]

It's harder for people to show how smart they are by reflecting on things carefully and making posts that add to the discussion. Heck, they might even have to face the fact that they don't know enough to contribute anything meaningful. Shitposting is a good way to not face that reality, and go on about your smug day.

But the real question is...

[SarekOfVulcan]

Has anyone implemented Go in Go yet?