+Sameer Ajmani, of the Go team, recently gave this introductory tech talk about Go.

You can view the slides (and play with the example programs!) here:

Shaun Russell's profile photoGlen Hassell's profile photoMike Boby's profile photoKangyuan Niu's profile photo
Its hard to understand then java....:(
Interesting but get rid of these { } and I'll be much more excited about it.
These comments are youtube worthy.
Seriously, everyone stop crying about the syntax.

This language is not designed to be pretty or fun. It is is a low level language meant to be a replacement for C that natively supports concurrence and parallelism.

Google is already using it to power MUCH of what you are using (particularly their data distribution over their networks).

Anyone comparing this to PHP or Java needs to do some more reading before they make a public opinion.

I find Go syntax quite reasonable and pleasant to work with, I just wish the library docs had more function calling examples.
+Shaun Russell But... It IS pretty, and it IS fun! ... I suspect most people criticising it haven't really even tried the language or the build tools ... Something I would highly recommend.
+Amr Malik I agree with you, but I feel like some people are expecting a Ruby or Python type syntax for modern languages, otherwise its 'scary'.

There is a somewhat active Go-lang community on reddit, where you will find a lot of resources.

@Shaun Russell: your name rocks, as does your taste in PL
The comments on Java are ironic... if you like Java, try JGo :-)
I am learning Go and am a novice programmer. I've dabbled in other langs and I find Go is indeed fun as some have said, and I think it is simple. I'm looking forward to getting my book Programming in Go: Creating Applications for the 21st Century by Mark Summerfield.
+Shaun Russell Go is unable to replace C, because Go manages threads and memory for you, which imposes a significant run time overhead. It's impossible to write an operating system kernel in Go.

Also, Go's type system and error handling facilities are extremely lacking, considering the decade we're in. C is low-level and old. What's Go's excuse?
It also does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic and for a good reason. Lazy patterns lead to poor excuses and complex solutions.

It is designed to be efficient with massively parallel systems and data sets spanning petabytes, exabytes and zettabytes, perhaps before comparing Go to system languages, one should understand parallel programming via MapReduce first.


Languages with concurrency primitives are the future! The concepts are as old I am ;-)
+Kangyuan Niu Who told you Go is "trying to replace C" ? I didn't get this impression from Rob Pike and other talks on Go.
+Glen Hassell is on the money.

I'm glad there is now some real discussion in this thread! Thank you for contributing.

I didn't mean it is meant to completely replace it, nor that it is trying to... but it is should be compared with lower level languages like C, not with PHP/Java/etc like other posts were (most of which have been deleted?).

Obviously there will be some use cases which C is better suited (embedded systems with limited resources) - but it is a low level language - ideal for writing things like distributed systems, web servers, load balancers, logging tools, network analysis tools. These are things Google is already using it for.

As far as memory overhead - GO may have garbage collection, but it still gives you control over memory layout and resource use... like C, Go allows unsigned types and allows you to store data structures as continuos blocks of memory (unlike java). Goroutines and channels have been shown to be an efficient way to work with threads when used properly (see +Glen Hassell's comment about not encouraging lazy patterns).
+Glen Hassell +Shaun Russell , generics is hardly a "lazy pattern", since it actually makes code safer. And it's not like Go's creators don't recognize this: Go's built-in data structures have generics. The problem is that only the built-in data structures have generics. When Go's users want type safety for their own code, they're shit out of luck.
people coming from Haskell, Scheme as their first language don't seem to share the view that type safety offers any advantage, other than being lazy.

It is nice and very convenient, writing code without worrying about the order things occur. I call it intelligent laziness.

Creating a performance trade off in kilobytes matters little, megabytes a little more, gigabytes and terrabytes, trade performance with time and the larger the data, the more time exponentially.

Data is in the volume of petabyte, exabyte and zettabyte's, means the difference between the data being ready today or next week. I know what my code does and don't need some lazy compiler to cover my tracks.
+Glen Hassell Haskell and Scheme have two entirely different type systems; Haskell has an extremely strong type system, while Scheme barely has one at all.

You have a point about scheme programmers not exactly caring too much about type safety, but I have no idea how you figure that Haskell programmers don't care about type safety when so many of the language's features rely on its strong, static type system. Of course, they don't write types out very much because Haskell has pretty good type inference, but that doesn't mean they don't care about them at all.

Also sometimes writing code without worrying about the order things occur is not only nice, it's actually necessary, particularly in concurrent systems, since concurrency and parallelism is the exact opposite of sequential programming and you want to do everything possible to avoid caring about specific ordering of events.
+Glen Hassell Your post indicates that you have an alarming lack of knowledge regarding type systems. The "order [in which] things occur" and the size of your data have nothing to do with the type system of a language.

> I know what my code does and don't need some lazy compiler to cover my tracks.

Really? You know, untyped languages do exist, but there's a reason nobody uses them. You're certainly using a "lazy compiler to cover [your] tracks", since Go is a statically typed language.
Add a comment...