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

[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

[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

[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

[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

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

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

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

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

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.

Re:"Systems" language?

[Toonol]

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

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

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.