As someone who is 38, and has programmed in everything from 6510/68k/MIPS/ARM assembler to C/C++ to ActionScript/haxe/JavaScript to D to Python, et al, I also think Go is pretty great.
In addition to the cool things in the language, I really love what they are doing with the build system. The Go programming I've been doing has been on Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and cross-compiling Go code requires simply setting a couple of environmental variables. Sooo much nicer than having to set up a full-on GNU-style cross-compiling setup and using different toolchains for all your different targets.
eg:
set GOOS=windows
set GOARCH=386
go build
Just built my project for Windows x86.
---
set GOOS=windows
set GOARCH=amd64
go build
Just built my project for Windows x64
---
set GOOS=linux
set GOARCH=ARM
set GOARM=5
go build
Just built my project for the Chumby device.
---
I highly recommend checking Go out and looking past any of the superficial allergies you have to it (I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me) and giving it at least a few weeks to sink in. If it still isn't your cup of tea after that, then that's fine, but it is well worth a look, IMO.
Windows port details? I start at golang.org, link to http://golang.org/doc/install.html. Says "A port to Microsoft Windows is in progress but incomplete." That in turn links to the world's least helpful wiki page: Page "WindowsPort" Not Found.
We've been working on Go 1 for about six months now, but have resisted pushing people toward the weekly (unstable) snapshots until the most recent one, as the documentation story was incomplete and we didn't want to leave newbies out in the cold. We're nearly ready on all fronts now, and hope to pull the pin on Go 1 before the end of the month.
As a coder who use mainly weekly (and now use godoc locally each time I need the package documentation), I still find it strange not to have links between release, weekly and tip on top of the documentation pages. Coders have to keep in mind the three links. I see a lot of questions on sites like stackoverflow that would probably not have been asked if the different documentations (and their existence) had been more visible.
And I suppose this small problem won't stop with Go1 as I hope we'll see new progress in weekly as we're used to.
You won't see progress with weekly as you're use to that's the point of Go 1. We are hoping to spend some time actually using Go, rather than building it.
Nice. How is the arm compiler holding up? I wrote the original 5g and ken did a large bug fix and optimizer sweep at some point so I'm interested in hearing how it has been going?
I haven't been inspecting the code of the arm compiler itself, but it has yet to fail me on my project, so kudos for the original implementation.
Having previously worked for chumby industries (makers of those bean bag alarm clock internet device thigies) I've got a nice collection of ARMv5 class devices laying around waiting to become useful and it is nice to have a modern language that is relatively low level support development on them. Quite a few other projects out there with arm support only care about v7+.
It does, but for a good reason. Its so the parser can find the line endings without needing complicated rules and look-ahead.
Go style is enforced mechanically with gofmt (http://weekly.golang.org/cmd/gofmt/), anyway, so one typically drops the pretension of these kinds of style quibbles. It is more important to have one consistent style than to make everyone happy. The gofmt style forced me to change several of my own habits, but it was definitely worth it for my code to look like everyone else's. I've never encountered a Go programmer who hasn't become grateful for gofmt, in the end.
Thanks for answering! I have no idea why someone downvoted your reply. People: downvoting is for mean and/or stupid comments, not things you disagree with.
Anyway, in that case I imagine we'll see a Go preprocessor that takes all the line-initial braces and moves them up a break before sending code to the compiler. People get pretty worked up about this stuff.
I work in a place where people don't use spaces and don't use empty lines to separate logical groups of lines. It's a real pain for me who is a code format junkie as our code ends up being an ugly pack of unrelated crap that's really hard to read.
It's Python code and I find it uglier than some fairly large C++ project I used to work on.
Anyway, I wish there was a gofmt in Python because at least, I'd drop all hopes of forging my own rules (silly junkies) and some basic clarity would be forced into our codebase.
I know there are beautifiers but when such things are enforced and not negotiable, it's just so much simpler and people just stop caring as well.
It's Python code and I find it uglier than some fairly large C++ project I used to work on.
I've always argued that if your team can't bother to even indent code properly than you have much bigger problems than any language formatting rules can solve.
I completely support enforced style -- it's part of what I love about Python and F#'s light mode -- but it has to be the right style.
I strongly believe that code should look like a screenplay, not a novel. More white space, in other words, is rarely a bad thing. Inline braces decrease white space and make unfamiliar code harder to scan, so to me they're Not Good.
Also wow, I didn't know it was even possible to write Python without spaces. Are we talking no spaces in arguments, like
Don't want to make this a big meta discussion, but I noticed that often the best comments are downvoted first, and eventually end up on the the top of the page. Don't worry this type of thing corrects itself.
Nothing in go is silly. There are multiple reasons why it's required.
The answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently.
Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding.
I was also a brace on its own line kinda guy, but between javascript and go, I've gotten over it.
Perhaps this will be Go's version of Python's whitespace issue. People will balk at the seemingly arbitrary nature of the syntax and avoid trying the language. However, after time, the rest of the language's advantages will lead people to get over their syntax aversion and try the language. Then after 6 months they'll look back and wonder what the big fuss was before.
It is a bit annoying having to press 3 keys using two hands instead of just one.
With '=' I can "hyperthread" my typing. While I'm finishing the LHS and pressing space I can move my right hand to press '=', while keeping my left hand thumb in place to press the space bar for the right side.
With ':=' I have to stop everything to press shift with my left hand, then press ':', then release shift and press '='. It's very inefficient for something that happens often.
I've never really had a big issue with this. I have no issue keeping my thumb on the spacebar while holding left shift, and in addition I've grown to rather like the syntax.
In the long run I'd say multiple assignment probably saves you more time writing declarations than an extra key-stroke would cost you.
Just think about how much more you'd have to type if you were programming C, and you'll be ok :)
My main gripe with := vs = is that as I change my code, an existing := may suddenly become invalid, meaning I have to go back and change it when compilation fails, or vice versa.
Yes, but thankfully compilation fails rather than succeed and then fail in some mysterious way at runtime.
As someone who has been stuck writing JavaScript for Yahoo Widgets (Vizio Connected TV) over the past month, my appreciation for the compiler errors you get in static languages has grown tremendously. Previously I had taken them too much for granted.
From that page: "At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. However, we expect that int will be increased to 64 bits on 64-bit architectures in a future release of Go."
So, in other words, it's Amateur Hour. All righty, then.
/backs toward door, reaches for doorknob, still smiling and nodding
ints are used in the definition of some of the core interfaces. This has implications on how many entries a collection (that implements these interfaces) can contain.
For example, sort.Interface:
package sort
// A type, typically a collection, that satisfies sort.Interface can be
// sorted by the routines in this package. The methods require that the
// elements of the collection be enumerated by an integer index.
type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less returns whether the element with index i should sort
// before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}
It would have implications on array indices as well, since they are also int.
Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.
ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform.
C is that language, among so many others, sizeof(int) is implementation specific, and indeed it does vary, though (S)?ILP64 is rare. On the other hand sizeof(long) varies all the time.
You seem very ignorant, please learn and stop the FUD.
C doesn't even define them, other setting a minimum. There have been C implementations where char was 64 bits.
As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1)
It also allows sign-magnitude integers (complement 1) in addition to complement 2 (C99 spec, section 6.2.6.2)
It also doesn't define the number of bits in a byte (C99 spec, section 3.6 p2)
Holy @#$@, people. Did I wake up in a naïveté vortex?
No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously.
GCC has options to change the size of int without even modifying the compiler. The size of integer types isn't even fixed within one implementation, in other words.
If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.
I see the line of reasoning behind this as explained by various comments here. But why can't this just be an user/editor preference while the file saved may use whatever convention?
You don't read only your code, but also code from other people. Go make it really easy, in my opinion, to fast decipher foreign code, due to shortness, clarity, and conventions. Convention help you recognize in that case the structure of the function without having to make your mind around the habit of the other coder.
I do not care who wrote the code -- It should be shown to me using my formatting preferences, just as I can use my own visual theme in the editor. Those themes do not affect the code as it is saved into the file, and those formatting preferences should not either.
You have to build the standard libraries and cross compilers first. I've seen this pair of zsh functions around. It will build the necessary bits and will also build for win/mac/linux/freebsd in simple projects and zip up the results for distribution (You can link to the raw zips then on github). For others looking to do this with go: https://github.com/colemickens/scripts/blob/master/dotfiles/... (Minor editting is needed due to some assumed values $ARCH, $OS, etc)
I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time.
But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly because it's very commonly used.
There are undoubtedly lots of great reasons to use Go, but your article did not enunciate them in a way that would win people over.
"why, say, they apply to Go but not to Python 3.0"
That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to replace them have so far failed to stick (D comes to mind).
If you're unhappy with Python as a baseline comparison, pick anything else you're happy with that other people understand and compare to that.
It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.
A tip: if you have say 4 cores, then using 4000 threads will most likely be slow due to lots of context switches. I say most likely because it depends on the details, but it's a safe guess.
That is part of the problem; if you have 4 cores, your program should be using 4 OS-threads. Your programming language's runtime should take care of distributing your 4000 lightweight/green threads to the 4 actual threads.
This is what e.g. Haskell does, and Go as well, I think.
> This is what e.g. Haskell does, and Go as well, I think.
This is what Erlang does by default, GHC >= 6.12 will do it when using `+RTS -N -RTS` and Go requires explicitly setting GOMAXPROCS, the runtime defaults to single-threaded (as far as I know, GOMAXPROCS still hasn't been retired) and there is no way to have it auto-detect the core count.
Are you processing data using 4000 threads? Do you have access to a cluster? Otherwise it seems counter-productive. BTW, Python has great facilities (IPython.parallel) for doing parallel and distributed computing. It is also pretty good at number crunching using Numpy.
Goroutines are multiplexed onto a set of threads defined by the Go program. They're not each a full thread; it's more like Stackless Python's version of threads.
http://www.stackless.com/
I don't generally wait for GHC more than a few seconds at a time, except when I'm bootstrapping a new installation. Then I wait some minutes for "cabal install".
Compilation times are not bad enough to be a problem.
It's hard to expect a really detailed analysis from someone still in high school. On the other hand, it is good to see how the various languages look like from a fresh perspective of someone with relatively little preconceptions from years of using C/C++/Python/whatever. After all, if he has lots of problems with writing something in C++, but much less when writing it in Go, it probably means lots of us had at some point to internalize lots of knowledge that's not directly relevant to the problem being solved, but to the intricacies of C++ or whatever. If the next generation of programmers can avoid this, that's a huge step ahead in what problems we will be able to solve.
Please, ignore people's age, it makes people in high school much happier. From someone in highschool (or the UK equivalent), the age anonymity of the internet is one of it's greatest strengths.
I think he'll still have to learn a fair few tricks to get around some features of Go. Things like type assertions, float32 vs float64, get ready for it lack of generics, and no distinction between stack and heap aren't common in other similar languages, and just getting to know the standard library is a huge part of being productive in a language. C could be seen as better in that respect; the core language is _very_ simple, which can't really be said for Go, though the advantages of Go probably out weigh the advantages of C for many people.
Wow, I had no idea that the OP was in high school. Kudos to him! His blog entry is close enough to other software dev blogs in quality that I think we can leave his age, identity and personality aside, and talk about what it takes to win people over to a new language.
Wow.
1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that.
2. He doesn't want to handle C/C++. I would say that most people who write application code are with him.
3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go.
The author needs no age defense. He makes a ton of valid points for why you should try out Go.
PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example).
Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.
PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time.
Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.
You don't say exactly what you're referring to, but I assume it's the GIL. The GIL exists because Python threads share a single global namespace, and synchronizing atomically on hash tables for module lookup would be way too slow. If you create isolated contexts (like goroutines, but without shared state), the GIL won't bite you (edit: the degenerate cases that folks like David Beazley has described notwithstanding, but those aren't part of the language semantics and have more to do with unfortunate edge cases arising from the way Python's runtime interacts with the OS scheduler).
The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.
Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.
Not to downplay these criticisms or to imply that Python isn't a great choice for many of these requirements, but the things you've mentioned of Go's compiler and garbage collectors are (as I understand the intent of the language designers) simply the current stating of being and I believe are both known (and planned) targets for future improvement.
So, a developer likes that list of things and it fits their project. Your comment offers nothing as a counter to choosing Go in such a situation. Your comment literally brings nothing to the discussion except a tl;dr for anyone who chose to not read it (if you didn't, go read it)
I mean, if I want to write a cross platform websocket server signaling server for PeerConnection, what would you recommend that will let me write a statically typed server in 80 lines of code that's all standard libraries? (edit: Websockets was moved to a `go install`able package recently)
I really like most things about Go, and was even going to use it for a bytecode interpreter project I was working on. A problem that I ran into, however, was that in interpreting a dynamic language with a stack machine, we needed a way to be able to store arbitrary data in stack values, which in C/C++ would be done using a struct with a type flag and then a union of various types.
Go doesn't have unions, though, and so this means that we would have ended up using a struct and using about 3x the memory on average, per stack value. You can see this limitation exposed as well in goyacc, the port of Yacc to Go (as the name suggests). Where Bison uses a union for yylval, Go is forced to use a struct.
I think this has been discussed on the golang-nuts mailing list a couple times and dismissed, for reasons of which I'm not fully aware.
C people: think of interface {} as roughly the same as void*, except that values pointed to preserve information about their type which can be extracted and used later.
Unions is a problem for garbage collectors. It is difficult to know if it contains a reference or a value.
Though Go should have a solution for your use case. The only one I see is polymorphism. Thus a stack of references to different instances of the same class.
Discriminated (type-safe) unions like ML and Haskell have are no problem for garbage collectors: you simply assign one ID to each variant of the union, and prefix the data with the ID corresponding to the variant in use.
You can simulate ML-style unions in Go with interfaces and downcasts, or the reflect package (basically like case classes in Scala, but without the exhaustiveness checking). Unfortunately, downcasts in Go (and interfaces generally) are slow.
The complaint I see here seem to be about c/c++ libraries.
TL;DR; c is too level and boost sucks (ie, is too complexified).
Go sounds like one fine answer to this. I would claim that c++ with QT is another answer to this. Write parsers for DSLs quickly and easily with QT - its container classes work without nightmarish overtemplating, its string class is like an ordinary class, etc.
That's funny. On my resumé, I always word it as "C++/Qt" because C++ with Qt is no more complicated than Python for most things (well at least it was so a couple of years ago).
Yup, the standard library was all I ever needed. People from other languages are familiar with frameworks and seek them in Go, but I'd say they are seldom required. The rich standard library and the language makes everything easy.
unlike other languages, a framework isn't as much of a requirement in Go since the Go standard library includes an http server, json serialization/deserialization, html templating, email, logging, basically everything you need in a web app. The url routing is pretty crappy, but that's my only real gripe. ngmoco's Falcore is worth looking at: https://github.com/ngmoco/falcore
Gorilla's mux adds much more capable and advanced routing. It's really nice to use it with subroutes, etc. Again, dead simple partly because it's designed well and partly because Go makes it easy to build.
It uses only the packages which ship with Go, with the exception of a Markdown parser. Unfortunately, it's written for an ~6 month old release of Go on Plan 9, but you can get the general idea of building Go web stuff. The code's a bit ugly too, but it does work.
It's really nice. You can build your Go program, deploy it as a single binary and it just runs. No need to hide it behind nginx or some other dedicated web server. The Go http package is DoS hardened and very fast. It's refreshing how little mechanism there is.
Go has the advantage of being developed by Rob Pike and Ken Thompson. It also potentially has the marketing muscle of Google behind it, although the most I've seen so far is free stuffed Gophers at OSCON.
Type safety, easy concurrency, static checking, C-like syntax, fast compilation time, concise syntax, etc. Java is ripe for replacing as the default language for (new) large systems. The replacement could be another language on the JVM, but I think Go has a good shot.
Depends what you mean by type safety. If by type safety you mean free from segfaults, Go is very much type-unsafe (send a map over a channel, access it concurrently, and it will segfault).
> send a map over a channel, access it concurrently, and it will segfault
Not exactly. Go's maps may safely be read from multiple threads simultaneously, but writing at the same time as reading or writing will yield undefined behavior.
Go programs don't segfault like C programs. They typically panic, providing a descriptive stack trace of where the problem arose.
As I mentioned in my other thread, what you're describing are "thread safe data structures," which Go doesn't provide by default. We provide the fast and non-thread-safe data structures and let the programmer build the concurrency mechanisms around them (easily done with a lock or using goroutines/channels).
What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java.
Or do I miss something in your comment ?
EDIT : In my opinion, a program that doesn't crash and goes on running with inconsistent data structures is mainly hiding a failure which will appear in a worse way later (for example when those data will be used). To fail fast is often more secure. But my opinion may be based on the fact that I see too many java programs which seem to work but that nobody can touch because they're just in the lucky state where bugs don't surface too much.
Mutating a hash map in Java while another thread reads it won't cause bad things like:
(a) memory you don't have access to to be read;
(b) other threads to crash;
(c) the VM state to be corrupted;
(d) the GC to crash;
and so on. The Java world is still in a consistent state. In a security-oriented world, this is important.
To the reply: It's a bit pedantic for me to say this, I know, but that's still "a consistent state". Basically, a Java program can't do anything it wouldn't otherwise be able to do by modifying a hashmap concurrently. Java programs can go into infinite loops. They can't access uninitialized memory.
There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.
That is a very unusual definition of "type safety." What you're describing is more commonly known as "thread safety," in my experience.
By your definition, is Java type safe? You still need to guard against concurrent mutation of shared data in Java and in most other languages that support shared mutable state.
We typically describe Go as "memory safe," in that you can't address uninitialized memory (unless you import package "unsafe", which clearly demonstrates your intent).
Java is type safe, because the language defines clear semantics for what happens when you mutate two memory locations simultaneously (you get one result or the other). Under no circumstances does the program have truly undefined behavior. Java HashMaps aren't thread-safe, but they will just do the wrong thing when you try to access them concurrently. Under no circumstances will the program be able to read or write undefined memory.
By contrast, your Go program's behavior becomes undefined when you mutate and read a hashmap concurrently among multiple threads. Anything can happen.
Edit (addressing the reply below): That's fascinating, thanks. It really speaks to the wisdom of writing hash maps in the library, on top of the language, rather than unsafely in the runtime as Go does. (This would unfortunately require generics, so it's not an option for Go.)
It's very difficult to predict all that can go wrong with unsynchronized access to data structures that aren't designed to be thread safe. The beauty of Java here is that the core primitives can never lead to accessing undefined memory, and therefore hash tables, however badly they mess up, will never lead to that core principle being violated. This is critical for security, for example.
I agree with everything you've said in this thread, except this: "type safety" should mean that the system has some belief about the type of values that cannot be compromised.
(sometimes type safety can be proven absolutely by static checking, but you have otherwise only run-time type checking, e.g. dynamic JVM languages, introspection).
Unlimited memory corruption does seem to imply that run-time type guarantees are gone, but it's still better to use the most appropriate terms.
Unfortunately Go still lacks generics, something that will hinder it from being widely accepted from the Java/C# crowd, for good reason. There are some good arguments to be made for why Go's error handling is subpar as well that I think could disqualify it for a lot of people.
5 minutes isn't fair. I took a look at http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... first. OK so Go is about on par with Mono's C# performance and uses up to a 1/3 of the memory with code that is more concise. That's cool because it means I'm not sacrificing anything over the platform I specialize in (C#; although the last time I looked at the Alioth C# code I thought I saw some obvious improvements). I see there is a Go STOMP client for Apache Apollo, which means I can supplement the existing code in my current project without having to rewrite everything.
Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.
I decided to research a bit to see if anybody else with a C# background had looked into Go. I found this, which confirmed my feelings that Go is for people who probably haven't given C# or Java a fair chance: http://www.jondavis.net/techblog/?tag=/c%23+vs+go . That's when I also discovered searching for 'Go' on Google is impossible because of the poor choice of name and decided I wasn't going to spend any more time on it, already being aware that aside from what looks like a total philosophy change (without it being clear whether it'll be worth it), I'm going to lose out on my awesome set of development tools (Visual Studio), years of C# experience and the HUGE .NET ecosystem, in exchange for what? Relatively unimportant performance advantages?
At the end of the day, if performance/memory are issues I can just add more EC2 nodes to my architecture. At some point I'll hopefully make enough money to pay other people to worry about the technology. That being said I realize that as a developer who wants to be a manager/owner I'm probably in the minority of readers here.
It seems you deleted your comment asking why you were downvoted. Here's why you were downvoted:
> Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.
If you didn't get past the fact that Go isn't object oriented, then you clearly didn't get very far into the language. And your resistance to "some new philosophy" shows you aren't interested in a new language with real ideas, but at most a different way to express what you already know and do while programming.
It was no longer relevant and seemed to attract more downvotes. I have spent years with x86 + MIPS assembly language, C, C++, C#, Visual Basic and Q[uick]BASIC; months with Java, Scheme, Python, PHP; days/weeks with AS3, HaXE, Erlang, Scala, E, Objective-C, Ruby, Delphi, Pascal, Concurrent Clean, Prolog, ADA. I've probably missed a few.
My point is (a) I'm not a lazy developer that doesn't enjoy learning new things or experimenting with new languages and (b) I have found a great ecosystem in .NET and C# and I've been around the block; at first sight I simply cannot see a compelling reason to invest more of my increasingly limited time into learning Go.
If Go has great new vision or compelling difference from other languages then why isn't it there on the homepage at golang.org jumping out at me? All I see are technical details and a huge guide. While I applaud clear, detailed documentation, I'm not going to read through that documentation unless I have some idea of the payoff. I just spent half of my weekend researching and investigating a ton of message brokers for my current project because there's value in the outcome. Researching a new programming language needs to have a huge payoff, or I need to have lots of free time (which unfortunately I don't).
There is absolutely nothing to sell me on the language on the homepage, or in the OP's blog post, and nothing to distinguish it from the 10s of other new languages out there. The FAQ touches on the fact that e.g. it's not object-oriented but not WHY. It just mentions "interfaces" and says "we believe". So I'll have to go and play with it and build something substantial to find out what they might be talking about. The goals mentioned in the FAQ are really not interesting (have you read it?) - perhaps the ideas around concurrency are convenient but they are limited in scope and don't directly address the more complex concurrency issues better than my current platform that I'm facing while I build a web crawler.
To be clear once again: It may be that Go is absolutely amazing and awesome... but if I had to spent days looking into every new language that pops up on the Internet I would never get anything done, and this is the point I was trying to convey in response to the parent's post. It's still on my list to look into but I just don't have a week to commit to what looks like quite a lot to manually digest.
Given all the languages you already programmed with, and given that the Go specification is relatively short (approximately the same as Scheme), maybe you overestimate the efforts it would require to learn it. But you don't need to, that's all fine.
Heh I think you inadvertently proved my point. I spent 6 months with Scheme, working through half of the SICP for personal growth. Just because the specification is simple it doesn't mean the patterns and lessons are straightforward, and I'm a pretty slow learner. If you read the Go FAQ you will note that about 1/3 of it is along the lines of "Why doesn't Go...". When I see that sort of language it's clear that between the lines there's a lot to learn, and the only way for me to learn a language is to write code.
But after all of this I think I'm going to have to write one of my site-specific crawlers in Go for fun; since Go has a STOMP binding it should be easy to integrate into my existing architecture. Where things will get interesting is finding a compatible serialization library (and so we start getting into the real world problems of using a new language to solve interesting problems... hopefully one of the .NET protocol buffer implementations will work correctly with the one I imagine exists for Go).
you have nailed wisdom to these younger 16 years old crowd. But nowadays younger crowd needs fashion,pizzaz,Prestige etc.
in my experience learning about Message Brokers is very important than learning new language.
Why do you feel that? From the Go FAQ, which now I feel obliged to at least read in its entirety because of how much heat this post has stirred:
"Why does Go not have generic types?
Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in [functionality] mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue."
Clearly the designers of Go consider generics a topic worthy of debate.
But apparently you consider "no generics" a deal-breaker without seeing why generics haven't been added yet, and why it isn't an issue for the many developers writing real-world production Go code.
I'm confused. I never called it a deal-breaker, just a surprise. The language designers, in their FAQ, acknowledge it as an opinionated gap where their own opinion hasn't been fixed, so I'm not imagining it as a gap either.
Your comment about "real-world" code is even more puzzling, as if all "real-world" code is somehow equivalent in abstraction needs. There are guys who've written serious code running in billions of cellphones where generics would be unimportant. Same thing for scientific or massive data crunching applications, e.g. Google's infrastructure.
In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
To be fair, I happen to be building a little search engine of my own and Go may turn out to be great for building the crawler components (the processing is site-specific), and I may end up using it for that purpose if I have the time to explore it or see value in it (if I find memory pressure to be an issue then saving 1/3 RAM on my EC2 instances over C# is a definite win, but since most of the work is I/O constrained I may never run into an issue at all).
> In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
Luckily for you, Go already solves these problems incredibly naturally! Unfortunately, you haven't looked into how Go solves those problems, primarily through its interfaces and type embedding, plus its slices and so on are already generic.
It's true they aren't sure if they need it or not, but you clearly haven't looked into many feel they are unnecessary and that the present language is more than sufficient for solving many needs. In fact, Go is almost explicitly designed to handle the production cases you tackle. But it seems you've said in other threads that learning new approaches isn't really worth it for you, in which case, it's unsurprising that new languages aren't offering you much.
I'm not sure interfaces are really the "incredibly natural" solution. Why, for example, should a container care about what interface its contained element implements? A list is really agnostic of such things and forcing an interface on the item is silly, just to contain it.
>Already feeling a sense of dread having been through this game 10s of times before with other languages.
What? I'm a student still learning new languages and it took me no time to look up and quickly grok duck typing. If that prevents you from learning a language...
Seriously... it's an hour to skim and read through. Hour or two to put together a decent non-trivial server demonstrating channels. I really don't know what your big long rant is about. It's not hard to find reasons Go was designed the way it was, find what it's goal is and read enough intro docs to get up and coding with it easily.
Your points #2 and #3 are in conflict. Not all languages are equally equipped for the same tasks, which is what really matters. I wouldn't write a web application in bash any more than I'd write a batch file renamer in assembly and pretending that the programmer not being "decent" enough to make those things true is disingenuous
Support for Unicode as a groundbreaking language feature? Closures (and first-class functions) as a major achievement?
I don't want to sound smug, so I won't mention any languages I'm comparing to — but seriously, unless you've been living in Python-land, those things are nothing to write home about. I'm surprised this is getting so many upvotes.
If I were to praise Go, I would concentrate on something innovative — concurrency primitives are interesting, for instance. I would not consider them sufficient for all applications, but they are intriguing and worth discussing.
Closures and first-class functions aren't an achievement. Closures and first-class functions in a language low enough and fast enough level for systems programming? That's an achievement. Same for unicode. These aren't just features. These are features done fast.
Well, the link to the shootout statistics is probably not the best demonstration for Lisp speed/memory consumption/SLOC count relation. If you look into the Lisp sources there you will see that there are lot of things precompiled for the sake of reducing the execution time. Here's where the extensive memory usage and source size come from.
I intended to say that Lisp's and Go's both performance and succinctness in the wild are probably on par. But Lisp is already there for a long time.
This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.
And I don't understand the comment about things being "precompiled". So what? Compilation is a natural step. Note that with most lisps "compilation" is not something you wait for while your server farm keeps crunching .c files, it's a natural step, sometimes happening behind the scenes.
> This discussion is increasingly weird and non-technical, mostly because there is no such thing as "Lisp". There are implementations of Common Lisp, implementations of Scheme, there is Clojure on the JVM, all of those are in the "Lisp" family. So comparing a particular language to "Lisp" makes no sense.
Since I've posted a link to Shootout comparison of Go and Common Lisp I thought I made it clear which Lisp I was talking about.
> And I don't understand the comment about things being "precompiled". So what?
It means that a descent part of the computation was done in the compile (macroexpansion) time and this time was not measured and included into the total result. This may be great for cheating Shootout benchmarks but does not fairly demonstrate the performance of the language.
Yeah, my main complaint about Go is the way its adherents go on like its type inference is some incredible new invention. I guess in makes sense when you're selling it to Java people, but it rubs me the wrong way.
"And, the worst problem I faced was of sockets. Non-blocking, multi-plexed and cross-platform socket support with C is basically non-existent (unless I wanted to use libev or libevent,"
What are you talking about? Most every single evented io library out there just boils down to a single system call in the underlying language - C: epoll(or select, poll, or kqueue) on socket/file descriptors. You do know that socket() returns a socket, which is actually just a file descriptor, right? You don't need libev and libevent because you can just write your own in two seconds with epoll! And if you're really attached to having the library handle the work for you you can always use one of the many cross-platform event libraries, like Glib which, last I checked, works on Win32, Mac, and Linux.
I couldn't sacrifice performance (lots of number crunching was involved with costs tight), so, I couldn't pick Python.
PyPy, Cython or Shed Skin might have been answers to those number crunching problems. I'd love to learn whether they would be sufficient for OP's performance requirements. Some benchmarks look promising, for instance this one published in late 2010: http://geetduggal.wordpress.com/2010/11/25/speed-up-your-pyt...
to be honest, I've used both gevent and Go and concurrency is far more natural in Go. Sure, you can do most of what you want with gevent, and if you're using stackless or pypy you can even have channels, but implementing concurrency at the library level is a mistake. It feels bolted on. It's like how some programming languages weren't object oriented from the start, but then they bolted an object system on top of it in a later release; it feels kludgy and you notice that it's bolted on. Concurrency in Python reminds me of that. Yes, it works, but it's awkward and feels like a second-class citizen.
I've done concurrent programming in both Python and Go, and to be fair to Python, its standard library queue class (http://docs.python.org/library/queue.html) is very close to Go's channels so it does CSP style concurrency quite nicely.
However, Go's goroutines are IMHO superior to Python threads since they're much more lightweight and can run in parallel on multi-core CPUs and you can have a lot more of them.
Go gets it right by putting goroutines and channels into the core language to encourage CSP style concurrency, but putting other more traditional, but harder-to-use, concurrency primitives like mutexes into the standard library.
I have'nt managed enough time yet to familiarize myself with Go, but the little that I have glanced at, it seems a nice enough language for scientific computation. The syntax and semantics of arrays are nice and binding to C is purportedly simple. Ease of binding with Fortran would have been nice too. So I find it a bit strange that I never hear of Go in the context of array based computation, that is the stuff people use Numpy, MATLAB, J, K for.
Is there any particular reason for that or is it just that not many have got around to doing it.
A type-inferred language with first class functions, with strong support for parallelism, and good support for arrays and slicing seems a really sweet deal. Throw in SIMD and it is already very compelling. Is anything wrong with the picture that I am missing. Performance issues ?
In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days).
I predict that Go is going to have to put a lot of effort into making the GC fast in order to compete with C++ and Java. They're going to need a concurrent, generational garbage collector much like Java's, probably with a server mode and a client mode. It'll have to be heavily tuned and will require man-years of work.
Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain.
Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have better control over allocations you don't need to lean so hard on the garbage collector. (Some of this is touched on here http://loadcode.blogspot.com.au/2009/12/go-vs-java.html)
You seem to have a lot of strong opinions (and predictions!) about Go, when you clearly don't have much experience with it.
Go gives you slightly better control over allocation than Java (in that you have a choice to allocate on the stack and inside other data structures -- but keep in mind that escape analysis can give you this too, see the optimizations in the Jikes RVM). However, in Go, you still have no choice but to allocate on the heap in many instances (for example, when returning a data structure from a function, or when using maps, etc.) You're taking a big bet that programs will be able to use the stack and manually use free lists or whatever (which you can still do in Java!), and that the slow performance of the GC won't be a problem. I wouldn't take that bet.
Besides, once you have a stop-the-world multithreaded GC, it has to trace all the roots in the program for correctness. There's no way around that. At that point having all the data on the stack doesn't help you (except for cache locality, but Java's GC already does that via the nursery and copying during major collections). You must still trace every pointer in the object graph, while keeping all threads suspended. You can run the GC less often, but that's not much of a help when interactive performance is at stake. iOS feels so great because the UI is always running at 60 frames per second. Stop-the-world GC can't do that.
We don't bet, we experiment, measure and analyse. So far, I have found memory allocation in Go to be extremely predictable and controllable, and the GC behaviour likewise predictable.
I don't know why you claim that "having all the data on the stack doesn't help you". That makes no sense. If data is on the stack, any references starting there disappear as soon as that stack frame is popped, so there's no lingering work for the GC to do; the GC arena is unchanged.
Your comments strongly imply that you have no practical experience with Go's GC. I suggest you stop claiming that it has certain performance characteristics or behaviours when you have not experienced it yourself.
"If data is on the stack, any references starting there disappear as soon as that stack frame is popped, so there's no lingering work for the GC to do"
You're only considering the sweep phase. Sweep is the easy part of tracing GC - you can always chuck sweep into a background thread. The mark phase is the problem. Marking always has to trace roots, including stack roots - that's how GC works. Tracing GC never traces dead objects.
You can reduce allocation pressure by using the stack, which will make the GC run less often, but my point is that when it does run you're no better off than Java, and quite a bit worse since Java's GC can run in parallel with the mutator and Go's can't.
"Your comments strongly imply that you have no practical experience with Go's GC. I suggest you stop claiming that it has certain performance characteristics or behaviours when you have not experienced it yourself."
I have experience with GC generally. There's nothing particularly special about Go's GC: it's a standard stop-the-world mark-and-sweep collector for a language that supports a limited form of stack allocation but generally uses heap allocation. The performance characteristics that this form of GC must have are well-known.
It's mostly a test of GC. Java's GC runs more often (thus the memory use is lower) and yet it's still 4x faster. This is because Java has a generational, concurrent-incremental collector.
The gc compiler does perform some optimizations, including inlining across package boundaries. There is also the gccgo compiler which takes full advantage of gcc's many optimizations. Both compilers will be equally supported in Go 1.
I'm referring to the Plan 9-based compilers, which do not perform the optimizations necessary to make it competitive with modern C and C++ compilers. Here I'm referring to stuff like SSA-based global value numbering, scalar replacement of aggregates, loop-invariant code motion, etc., as well as lower-level stuff like instruction scheduling. gccgo is better here, of course. Unfortunately, the Plan 9-based compilers are the ones most people use...
It doesn't matter what "most people use". Both compilers are equally accessible with the new go command (http://weekly.golang.org/cmd/go/). People who find their programs faster with gccgo will use gccgo, and vice versa.
Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. http://blog.golang.org/2011/06/profiling-go-programs.html
"There are few real world programs that are improved by code generation micro-optimizations"
I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte-by-byte makes an enormous difference. Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding.
To name just one example: Modern x86 processors have an optimization that allows the fetch-and-decode step to be skipped for the second and subsequent iterations of small loops. By "small" I mean "really really small" -- something like 16 bytes is the number I've heard. By shaving a byte or two off the instruction encoding to fit a loop from 18 bytes into 16 bytes, the loop performance can double or triple. When that loop is the loop that drives alpha blending on your touch-sensitive mobile app, that can be the difference between an app that feels solid and fluid and an app that feels slow and pokey.
People use systems languages for performance. Folks for whom performance is irrelevant are all on dynamic languages, and that's not changing. Systems programmers need a compiler that knows about these micro-optimizations.
> Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding.
Like http://x264dev.multimedia.cx/archives/486? "Now that I’ve written a thousand or two lines of assembly code..." etc. Programmers who know and care about these processor-level micro-optimizations use assembly code, for which by definition you do not need a compiler.
Then again if you really care about graphics performance, you're using a GPU in which case there is no compiler since the driver is just an opaque binary blob.
C compilers can and do generate SSE. Programs do rely on this code generation for performance. They fall back on assembly when codegen fails. That doesn't mean that they aren't relying on the optimizations in other places.
And a huge amount of graphics processing is always done on the CPU. Unless you're using Direct2D or something, rasterization is always done there (and even if you're using Direct2D, a lot of rasterization is still done there).
Most of the code in any program is not performance critical. Yet the reason that this is the case is that most of the time of any program is spent in tight loops. Those tight loops are what must be optimized. And that is why performance-minded systems programmers use top-notch optimizing compilers.
The popular dynamic languages have gotten away with being relatively slow because programs written in them are either not CPU bound or spend most of their CPU time in C libraries. This works great for them -- dynamic languages are awesome! But the calculus changes when you're programming in a language that defines the entire stack. When there's no C-compiled code to fall back on, micro-optimizations start to matter.
Thus far you barely hear of anyone using Go in any context, though that is changing.
I think the primary reason for the lack of users has been language stability. The Go team are currently working on the first actual "release" of the language ("Go 1") to address this. But prior to the move towards Go 1, the language was very much in flux, more so than you'd want for a language (that you'll actively be maintaining code in) to be. (And gofix, while nice, isn't really a substitute for language and standard library stability).
> And gofix, while nice, isn't really a substitute for language and standard library stability
I agree with you in principle but practically, gofix (+ gofmt) it is pretty darn close. I revisited a Go project that I wrote back when it first came out (in other words, an ancient one :). Biggest pita was dealing with the 'error' changes that gofix couldn't fix (and some minor pain due to time and Duration), but everything else was taken care of by the tool.
In any event, my understanding is that the Go authors will strategically depend on gofix to deal with language evolution (beyond "Go 1").
I've been coding since '82 and have had my share of PLs. Go is a serious contender and I highly recommend it to anyone looking for a "modern" C.
I concur about arrays. Each time I make computations in java and I have to either pass offsets and lengths or make arraycopy I regret not to code in Go.
I looked at its serializing documentation and I was surprized to see that every floating point value is serialized to a double precision value. There are now four types of foating point values and this simplification is downgrading the capabilities of data tranfer. Extended is needed in some scientific computations. Appart from this, the base type encoding is great.
The other weird choice is the structure encoding with field numbers and omitting null value fields. My impression is that this is less efficient than coding the null fields. Is this choice based on measurements ?
If you are going to create a headline that ends with ", period." the content of the article had better contain a cohesive and very strong argument that supports the emphasized statement. You could have easily posted - "Go is amazing." That is a statement of opinion -- which pretty well describes the article and the author's place as an expert. "Go is amazing, period." claims something much deeper, which the article completely fails to deliver.
My background is in garbage-collected languages, including .NET and PHP. Because of my lack of background in manual memory management, I've always been nervous to try to learn C, even when it may be a better approach.
Go sounds like a great language for someone with my background to be able to work with a closer to the metal language but by handling some of the more difficult aspects of working with C like memory management and pointer arithmetic.
So he recommends Go but has never actually used it? The only reason he looked at it again was the potential to use it for a small project he never finished or did I miss something?
Go has utility called CGo that allows you to create interfaces to C libraries in Go. I've heard you can use some magic to get Go to talk to C++ by exporting functions back to C somehow (disclaimer: I'm not a C/C++ person).
Is the Author is 13 years old. When did he really start programming.? just wondering After 16 years of programming experience still not able to decide which language is best.
At last Settled for C and Common Lisp. But still have Doubts.
As per Personal Experience Both Language is more than enough for me.
Maybe I'm missing something, but "they got rid of the parentheses" sounds like either Go used to require parentheses for this or he thought Python did. If it was the former, then I misread (I don't know very much about Go).
Not only excellent library support, but also a large array of productivity tools ranging from superb IDE, static code analysis, build+dependency tools, great Continuous Integration, etc.
You should look at the work on pypy; specifically the RPython subset of python. It uses type hinting for static type analysis for the JIT compiler. It's not as hardcore as a fully statically typed language like ML or C but it will catch mistakes in mixing types.
Not to push the issue, but Go's standard libraries are fairly decent for being minimal and are dead simple to use. The docs have a good mix of examples and quickly parseable information.
I'm extremely happy with nsf's gocode [1] adding auto-complete support to Sublime Text and Vim. It's quite nice. Go, itself (from `hg`), has syntax support for vim and (I think) an emacs plugin. There's also a Goclipse modified Eclipse install which I don't know much of anything about.
There are others, [2]
I mean, there certainly isn't a complete equivalence of Eclipse for Go (yet?).
I like go. As a guy who really doesn't like javascript I like the structure of GO. I like really structured languages. For anyone who like the mobile/desktop type of programming this seems like a refreshing change.
I think what your parent is referring to is that, compared to JavaScript, Go provides a fairly rigid structure in which to write programs. You write packages that consist of type, function, and variable declarations, and link them together with import statements. Its rich standard library supports a range of useful, omnipresent interfaces, which make it easy to do things in an obviously correct, interoperable way.
By comparison, JavaScript lets you structure your code in however you like, and there is a very tiny standard library and no real uniformity across implementations, frameworks, and so on. This can be a strength, but I think on balance it is a real weakness in JS. node.js has done a lot to improve this, though the language itself still lets you define anything, anywhere, at any time, and change that state from anywhere else.
"By comparison, JavaScript lets you structure your code in however you like, and there is a very tiny standard library and no real uniformity across implementations, frameworks, and so on. This can be a strength, but I think on balance it is a real weakness in JS. node.js has done a lot to improve this, though the language itself still lets you define anything, anywhere, at any time, and change that state from anywhere else."
Not true with ES6 modules.
Besides, Python and Ruby have open modules, and that hasn't hurt their usefulness in the real world. Quite the opposite, actually; one of the great pragmatic strengths of Rails was that it monkey patched Ruby's standard libraries. It's hurt optimization, but that's a different story.
Many programmers educated in the OOP days don't know the term "structured programming". I once interviewed someone who called a Pascal-like language "functional". We hired him anyway.
i truly believe go contributes negative work to society. it's basically C/C++/Java/C# with syntactic sugar except it's different enough to get bored programmers to waste their precious time reporting all their code.
if you want to learn a new language, actually learn a new language. learn a language that's actually breaking the mold in terms of how we communicate with computers. think at a higher abstraction level than dynamic dispatch and composable objects and subroutines, that stuff is already more than 40 years old.
I agree with your goal. But the parent is correct in that learning a really different language will help you become a better developer and thus build better systems.
people who program actually have a lot to learn from the fashion industry. trends are fine as long as trends are iterated on quickly. in comparison, it's taken programmers 15 years to make the half-assed-jump from java to go. and even then, the conceptual differences between java and go are minimal, superficial at best.
the fact is that go touts itself as a C++/java alternative but i see no significant/non-superficial reason to actually change languages. thinking in go is 99% the same thing as thinking in C++. consequently, 99% of the time doing stuff in go takes me roughly the same amount of time as doing the same thing in C++. programmers remain stunted.
we all know how efficient we can be writing code like in the von neumann style (not to mention 90% of programmers haven't yet even mastered that). to advance what people can do with computers it's time to start thinking beyond sequences of instructions and memory accesses, we need a language that encourages higher-order thinking. otherwise it's like building the empire state building with legos.
Two things. 1) Have you used Go? Your comments indicate to me that you have little Go experience - thinking in Go is quite different from thinking in C.
2) One line counter-example to disprove your negative-work argument: goroutines. Also known as: CSP-style concurrency in a procedural language.
I urge you to read up on goroutines. There are quite a few examples on the golang site of how you can use this feature to good effect, examples that would require you to think very differently than if you were in C.
Also, I'd like to point out that the Go project got started because Rob Pike and Ken Thompson grew tired of long build times while working with C++ while at Google. One of Go's objectives is fast compilation times. They are willing to stick to this goal at the expense of complex type systems. This is, if it is anything, not negative work.
Threads are different from goroutines. A Go program can create 100'000 goroutines, if it makes sense for the algorithm. Try doing this with threads... Super-cheap threads open many possibilities, it's a significant change in how you think and design programs.
Among your examples, those that are comparable to goroutines are all for functional languages. There's nothing wrong with functional languages, but it's far from "all mainstream languages".
So they are a bit different, in the spirit of Go: they make for a simple and general solution to both parallelism and concurrency. They combine naturally with channels to give the functionality of OS threads, user threads and fibers.
As an aside: watching Pike's talk on lexing and parsing in Go really hits this point home. It shows how language support for cheap threads (goroutines) and channels really change the way you come up with an algorithm.
threading (or CSP) is nothing new conceptually. yes, i agree, the go language has popularized a cheap threading implementation but the same design concepts we've applied to unix processes and posix threads apply to goroutines.
btw, blocks in ruby and generators in python have existed for many years prior to go.
Agreed. I've looked at Go quite a bit and I can't figure out what new problems it solves, or how it solves existing problems better than previous procedural/OOP languages. How is better than 'D' for example. How is it better than Java?
If you want a fresh look at systems programming then leaning Ocaml or Haskell would be a much better option because you will learn to solve problems in a new way, not just with slightly different syntax.
Also, someone on this thread doesn't understand how downvoting works. If you disagree with something then make a response, save downvotes for deliberately trollish or off-topic comments.
So because it's not revolutionary, it is actually harmful? Sorry, I don't follow at all. Even if it's "better" than C/C++/Java/C# [1], then it's a positive contribution.
[1] I think it's silly to imply that languages are "better" than one another. Some are more apt for certain projects and some have different feature sets that appeal to certain people. Certainly it seems unrealistic to absolutely call a language useless, especially given the points in this articl.
In addition to the cool things in the language, I really love what they are doing with the build system. The Go programming I've been doing has been on Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and cross-compiling Go code requires simply setting a couple of environmental variables. Sooo much nicer than having to set up a full-on GNU-style cross-compiling setup and using different toolchains for all your different targets.
eg:
set GOOS=windows
set GOARCH=386
go build
Just built my project for Windows x86.
---
set GOOS=windows
set GOARCH=amd64
go build
Just built my project for Windows x64
---
set GOOS=linux
set GOARCH=ARM
set GOARM=5
go build
Just built my project for the Chumby device.
---
I highly recommend checking Go out and looking past any of the superficial allergies you have to it (I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me) and giving it at least a few weeks to sink in. If it still isn't your cup of tea after that, then that's fine, but it is well worth a look, IMO.