Passing a closure on a channel is both idiomatic and relatively common in Go code.

This and other comments make me suspect the author could have benefited from spending more time looking at existing Go codebases (the source of the Go stdlib is excellent).

Edit: His (IMHO somewhat strange) complaint that "Channel reads violate the laws of time and space by changing their behavior based on how their return values get used." doesn't apply anymore, now to do async reads from a channel you use select with a default, not the comma-ok idiom.

Also a package including more 'clever' Unicode operations will also be part of Go 1.1, but I have personally never found the existing support lacking, and no, I don't live in an English speaking country.

He's a very smart guy (and the author of one of my all-time favorite Mac apps, Hexfiend) and I'm pretty sure he understands what is actually happening.

I'm not sure that spending a lot of time in Go is going to get him over the "Damnable Use Requirement". It is really, really annoying.

  func main() {
  	x := 4
  	f := func() { fmt.Println(x) }
  	ch := make(chan func(), 1)
  	ch <- f
  	f2 := <-ch
  	f2()
	x = 5
	f2()
  }

  test := make(chan func (int) int)

  go func() {
    f := <- test 
    fmt.Printf("%d\n", f(10))
  }()

  test <- func(v int) int {
    return v * v
  }

- I too dislike the lack of a ternary operator. Python has this problem too (you can create boolean expressions to sorta mimic it but it doesn't tend to be considered "Pythonic"). And brevity is my reason too. I'm sure it's easier to parse without it but it can't be that hard.

- On the "damnable use requirement", I see his point. If anything, it means that Go will be better used with IDEs than text editors that'll do this for you automatically;

- On the "thread safe set", yeah he's Doing It Wrong [tm] (which I think he knows). You use channels to share state in Go rather than creating shared state directly.

- Unbuffered channels seem to be idomatic. Race conditions and deadlocks seem to often be the result of using buffered channels;

- On his channel reads issue ("violating time and space") I disagree: it's good to have blocking and non-blocking channel reads.

I basically agree with his conclusions, particularly in Go feeling like a "modern C", something I desperately hope succeeds.

  value, ok := <- ch

Select statements allow you to check if a channel has had a value sent on it.

http://golang.org/ref/spec#Receive_operator

https://groups.google.com/d/msg/golang-nuts/Z63l4LDOlsI/54uT...

http://golang.org/ref/spec#Select_statements

  func f(ch chan int) {
  	select {
  	case v := <-ch:
  		fmt.Println("got", v)
  	default:
  		fmt.Println("did not block")
  	}
  }

When using channels, the choice between buffered and unbuffered depends on the situation. There are cases where a buffered channel is required to avoid deadlocks. For example, consider the case where you start N goroutines and use a channel to collect the results. If you return before collecting all results, the remaining goroutines will block forever trying to write to an unbuffered channel. Using a buffered channel with size N avoids this possibility.

Python has had conditional expressions since version 2.5. Dumb example:

    def count(xs, p):
        return sum(1 if p(x) else 0 for x in xs)

The pep for adding bools to python: http://www.python.org/dev/peps/pep-0285/

    4) Should we strive to eliminate non-Boolean operations on bools
       in the future, through suitable warnings, so that for example
       True+1 would eventually (in Python 3000) be illegal?

    => No.

       There's a small but vocal minority that would prefer to see
       "textbook" bools that don't support arithmetic operations at
       all, but most reviewers agree with me that bools should always
       allow arithmetic operations.

    6) Should bool inherit from int?

    => Yes.

       In an ideal world, bool might be better implemented as a
       separate integer type that knows how to perform mixed-mode
       arithmetic.  However, inheriting bool from int eases the
       implementation enormously (in part since all C code that calls
       PyInt_Check() will continue to work -- this returns true for
       subclasses of int).  Also, I believe this is right in terms of
       substitutability: code that requires an int can be fed a bool
       and it will behave the same as 0 or 1.  Code that requires a
       bool may not work when it is given an int; for example, 3 & 4
       is 0, but both 3 and 4 are true when considered as truth
       values.

    Because of backwards compatibility, the bool type lacks many
    properties that some would like to see.  For example, arithmetic
    operations with one or two bool arguments is allowed, treating
    False as 0 and True as 1.  Also, a bool may be used as a sequence
    index.

    I don't see this as a problem, and I don't want evolve the
    language in this direction either.  I don't believe that a
    stricter interpretation of "Booleanness" makes the language any
    clearer.

That one little simple change really makes type declarations less readable, for no apparent benefit. Using a colon makes the type clearly stand out, whereas without one, it sort of gets lost amid the variables.

Pascal-style (Ada, etc, etc):

  var foo, bar : int = 1, 2

  var foo, bar int = 1, 2

p.s. One saving grace: they could probably add colons back into the type-declaration syntax as an option, without affecting existing programs....

Ugh... (notes another Go uglypoint)

I dunno; maybe it's "ugly," but it's also explicit, and easy to see. Assigning meaning solely to subtle presentational differences can make code hard to read, and increase the likelihood of mistakes (as well as confusing beginners).

[It's a similar problem to Python's significant whitespace.]

Unfortunately it's all this sort of "cute idea" that makes Go seem rather half-baked. It's like they designed the language in a brainstorming session in a bar, mixing ideas from a bunch of people without strong editorial control, and then just released the result without actually understanding the repercussions of many of their decisions. [I'm not saying they're all bad, it just feels like there was a lot more brainstorming than vetting...]

This is as far from the truth as I can imagine.

Yes, "subtle presentational differences" can make code hard to read, but in this case it doesn't. When I reference another package I know that all exported variables begin with a capital letter. When I'm writing a package I know whether I'm calling a function that's "private" or "public" without having to look it up.

It's one of some of the Go Authors' favourite ideas in use in Go, and I wish people would stop armchairing about the effect some language feature has without trying it.

The likelihood of mistakes is not really increased, because they will be caught at compile time, or you'll end up with an exported function you didn't realise you wanted.

A confused beginner should be able to understand this concept within seconds. And it's prominently mentioned in the Go tutorials.

I typically disagree when people say, "Well you haven't tried Go yet, so maybe you should," but this is one of the few cases where I agree. The exported/unexported syntax is weird to look at, but once you start using it, you quickly realize it to be amazing.

One of the key things about using a capital letter to indicate export/unexport is that you know if a function or a method is exported at the call site. That is, the export information isn't just in the function declaration, but in the name itself.

And trust me, it is not hard to read. It's not that hard to imagine that your eyes are quickly trained to see the export information.

> [It's a similar problem to Python's significant whitespace.]

No, that's not a problem for anyone who knows how to not mix tabs and spaces.

> and then just released the result without actually understanding the repercussions of many of their decisions

What's ironic is that you're criticizing a feature that they kept because of how it worked in the real world.

http://news.ycombinator.com/item?id=4569456

The lack of partial/incremental/parallel compilation make this a lot less attractive. A lot of IDE technology (e.g., "intellisense," syntax errors, missing imports) are built off of rapid recompilation.

In fact, doing it any other way seems pretty stupid. If your compiler doesn't offer that information then the IDE has to re-implement those codepaths just to provide that information.

Nobody has bothered to add parallel compilation because building Go code is already so ridiculously fast.

x = (2 if y > 3 else 4)

That's not really his issue. His issue seems to be the overloading of the channel read to very different operations based on the number of return values.

I don't think he'd have minded if blocking and non-blocking channel reads were different operators, but it's the same operator returning either one or two values. It's harder to read.

import ( _ "fmt" )

Try it.

The unused variable thing (particularly with local variables) has caught many bugs quickly for me. If there's a package that I find myself always adding and removing, it's easy to write a function that freezes it. For instance, for the debugging print example:

    func printf(f string, args ...interface{}) {
        log.Printf(f, args...)
    }

On the few occasions that I've really felt I lacked a ternary operator, I've just coded one up for the occasion:

    func either(cond bool, a, b string) string {
        if cond {
           return a
        }
        return b
    }

But in any case, I've found I usually do better error handling in Go.

Seeing the "multiple-value ... in single-value context" compiler error message immediately tells me that the function I'm calling either doesn't do what I think, or (more usual) that I'm not handling an error return value.

When I fix the compile error I have to consciously decide how the error will be handled. Will I ignore it by assigning it to "_"? Will I pass it to a generic error handling function? Will I do special case handling?

On the other hand, in Python it's really easy to ignore the exceptions that can be thrown by a function. The interpreter doesn't help at all. If I leave out a try/except block then I don't find out about it until runtime, and only then if I get lucky (unlucky?).

See also Raymond Chen's posts about good vs bad exception handling (H/t Russ Cox on G+):

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/11816... http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

I agree, unused variables in any language are great for catching bugs. This isn't an argument for unused as errors instead of warnings.

I suppose you could cast it, also use a Function literals for delayed evaluation.

    map[bool]int{false: 3, true: 14}[foo != 0]

That way it will never complain that fmt is imported but not used.

Still, I never had need for this. Once you have written a bit of code the import list remains relatively stable.

I do have need for some solution, since I have packages that don't do anything with strings and therefore don't import fmt, but which still get bugs which I need to debug with the stdout.

One more robust approach would be to fit a complete configurable logging system permanently in place.

http://play.golang.org/p/vVnZWobca9

I don't mean to be rude but, please don't write about about things you've only used for two days. This is a massive problem for all new things. Initial impressions mean a lot, and you honestly can't grok a new language in 2 days to effectively blog about it. If everyone here tried to go out and criticize Haskell after two days of usage, I don't even think they'd understand enough to criticize it beyond "it's too complex".

Lots of the decisions made for the Go language aren't for the hobbyist. It's targeting building large, powerful, heavily code-reviewed systems because C++ with an enforced style guide is a nuisance. Let's look at an example decision: the "use requirement" is actually godsend for removing unused dependencies. Go compiles as fast as it does partially because of its powerful dependency resolution. Rob Pike has a story about an engineer accidentally compiling a library 80,000 times in the same C++ build without knowing for years. The author of this blog got mad because it was inconvenient to debug with print. Now if only he hadn't been using the language for two days, he'd know that the Go compilers don't have to, but implement a builtin called print and println specifically for debugging. You don't need to import fmt to debug with print/println.

Besides, it's ridiculous fish, his notes on two days of Haskell would probably be well worth reading too.

    sm <- commandData{action: length, result: reply} return (<-reply).(int)

And anyway, that's two lines masquerading as one. Semicolon insertion won't work and this won't compile.

  sm <- commandData{action: length, result: reply} 
  return (<-reply).(int)

If you're dead-set on implementing this with channels, those channels should be unexported and hidden:

http://play.golang.org/p/zRSco7MpMl

In reality, it's far more sane to just say `type SafeSet struct { d map[string]bool; mu sync.Mutex }`, again exposing all the functionality through methods, and just locking and unlocking the mutex as necessary. If using a mutex makes the implementation more clear and is semantically equivalent, then use a mutex. That's not typically the case, because typically the case involves more than just locking and unlocking. In this particular example, all you need to do is lock some resource, so it's ok to just use a lock.

And the claim that there's no data privacy isn't correct, it just assumes a data privacy model that Go doesn't have, namesly the "public" and "private" notions. Go instead opts for the notion of "exported" and "unexported" fields and methods; i.e., fields and methods that may be used only by code within the same package. It's a different mechanism for hiding data, but it does exist.

Anywho, if you want to see a completely absurd, lock-free (not strictly nonblocking), threadsafe queue in 51 lines of Go using higher order channels, just for kicks, see here: https://gist.github.com/3668150

  if expr {
      n = trueVal
  } else {
      n = falseVal
  }

  n = expr

!

"""

Something doesn't work right, so you add a call to fmt.Printf to help debug it. Compile error: "Undefined: fmt." You add an import "fmt" at the top. It works, and you debug the problem. Remove the now annoying log. Compile error: "imported and not used: fmt." Remove the "fmt" knowing full well you're just going to be adding it back again in a few minutes.

"""

See Rob Pike's essay on this very topic and the design of Go:

http://commandcenter.blogspot.nl/2012/06/less-is-exponential...

I appreciate "small" languages, which can do a lot with a little core and abstraction mechanisms (Scheme,Smalltalk,...). However, for maximum performance, you need a good compiler, which understands and optimizes your abstractions. In the case of Lisp, whoever writes the macros is also responsible for optimizing them. Unfortunately, this requires application programmers to be also good in writing compilers.

C++ certainly has deficiencies, which cannot be fixed without completely breaking backwards compatibility. Rob Pike probably has them all included in the list you linked to. E.g. irregular syntax and header files.

In my opinion D has mostly fixed those conceptual issues. Unfortunately, D is not mature [0] and development is slow. While D is certainly not the final word in language design, I consider it the only serious competitor to C++.

[0] http://3d.benjamin-thaut.de/?p=20

This is a knee jerk cliche reaction.

D is much better designed than C++.

I feel that people who jumped ship from dynamic language such as Ruby or Python to Go have no idea what they are giving up. Maybe they never practiced TDD to begin with.

Heck, even Java is more friendly with TDD by using Powermock or JMockit library.

Well, you'll be happy to learn that Go doesn't have constructors or static methods, then. :)

What Go does have is a standard unit testing framework which is quite nice: http://golang.org/pkg/testing/

"Mocks" in general are a cumbersome and somewhat lame attempt to deal with the many limitations of inheritance-based designs in languages such as Java. In Go, there's no need to create a Mock, because you can easily create a wrapper object for whatever object you want to test using Go's anonymous member syntax. Then you simply override whatever methods you want to on the wrapper object, and let the others get passed through.

This really stood out for me and seems to make a mockery of Go compile times for larger programs and perhaps more real-world situations.

Having 700 files in one package is an abuse of api.

Agreements:

All of the thumbs-up opinions I share, with the emphasis on that Go fills a niche that is otherwise a relative vacuum as-is.

The Damnable Use requirement, for precisely the reason he states. Add having to constantly frob a binding from "anySymbol" to "_" while doing some instrumentation or whatever. This kind of trivia should be fixable by a program, and otherwise let it remain a warning. I think the occassional positioning of this inconvenience as a feature is unconvincing.

Annoyance at the lack of assertions. I think the concern given by the Go FAQ can be met even without making everyone roll their own assertion construct, but now we have either fewer assertions or a less idiomatic way of identifying them. I think an assertion is quite distinct from an error in that it should indicate a logically impossible condition rather than an unusual one, and I often see this guideline applied in the world at large. As such, I feel the FAQ seems flimsy in its justification, and now I have panics littered about that have a convention indicating their special nature.

Assertions are also one of the very few pieces of software engineering practice that have even a smidgen of empirical evidence in their support as well: http://research.microsoft.com/apps/pubs/default.aspx?id=7029...

Leakiness of semicolon insertion. The abstractions are leaky, but I like not having to type my semicolons and it's not a common mistake I make. Minor.

Lack of clarity with regard to unicode. Yes, the language supports it quite well (as he mentions, unsurprising given its pedigree), but I'd say the type system and operators available only seem so-so, and it seems like more so than with Java or Python3 leaky abstractions between bytes and encoded text are present. Among my favorites:

http://golang.org/src/pkg/text/scanner/scanner.go#L521

Wherein the "rune" returned by the "text/scanner" "Scan()" is used to identify the type of token rather than its value. Sometimes. I was mystified by the type signature for a while (why is this returning a rune, and not a lexeme or lex type?) and had to read the package to convince myself that was the intent. Plus side: this kind of abstraction leakage (or at least free-wheeling coercion) can probably yield much faster code.

Disagreements:

"Violation space in time", whereby the semantics of a statement can be varied by the arity of the binding. I think this is good, and not bad. It's only a little weird that it's only available (afaik) as a special service to channel binding rather than any operator defined by a user.

Buffered Channels and Deadlocks: non-deterministic deadlocks are a pain, and I don't think Go provides any real treatment (or exacerbation) of this problem, however, it probably could make that possible by adding some operators to enable writing a run-time deadlock detector, which can be useful for some programs.

Notable omissions, speaking in the postive:

I think go fmt is great. I don't like everything about the formatting, but I like the slavery-is-freedom approach there.

The gdb support is surprisingly good and neatly integrated into most new gdbs one gets off the shelf. Massive thanks to Ian Lance Taylor.

In 10 years in the industry, building distributed systems and server-side software, I've never seen assertions work out well. In two of the jobs I was at, we ended up making the assertions always-on, even in production, simply because people were too scared to run with them off. At another job, we simply never used assertions.

I've come to the conclusion that if you think you need more assertions, what you really need is more unit tests. There are other benefits that come from designing for unit tests, like modularity. Assertions are just a crutch, and they're often a sign that you're not thinking things through clearly (if a is always false when b is true, why do I need two booleans? etc.)

More unit tests are always nice, but practically, by having a cheaper and lower-overhead way to check invariant buried deep in the code enables more invariants overall. I see unit tests as a nice way to check invariants when it's possible to decouple assertions from the program, but they are generally more expensive to write and that means there will be less of them. Inverting a program to expose private state that has as many easy-to-express detailed invariants as one can think of often not practical.

The two approaches can be combined as well, by simply running with assertions on while also using unit tests.

I think assertions are most useful when evolving complex software to do new things or fix bugs. They're an also good, functional form of a comment. Practically they are much like an error (some performance sensitive systems can turn them off while in-production), so the Go approach to when-in-doubt-leave-it-out is reasonable, but I personally miss them because I still write assertions, they are now just my own idiom and otherwise look much too similar to actual error conditions.

One community I haven't visited in a while has been Java. Is it possible that assertions are more frequently abused there?

It seems like your experiences confirm my own. People toy with the idea of turning off sanity checks in production, but eventually reality sets in and they realize that this is a bad idea. Then they keep calling the sanity checks "assertions," because nobody wants to submit a search-and-replace patch for a big code base, and a few die-hards still cling to the dream of running without error checking.

This leads to a lot of confusion whenever I talk about assertions (oh, assertions? You mean those things that are always on?) And so the cycle continues.

No. They don't. Practically nobody runs Postgres or the product we shipped with assertions on (it would be too expensive, and requires recompiling besides), and the only reason people run with assertions on in Python is because it's the easiest way to do things (the default), whereas in most C programs the default is to not have the assertions. However, I note that people don't seem to use assertions as crutch in Python in spite of them being on, because I very seldom see an assertion error crop up in production. When they do, I know the program has gone completely haywire and is no longer internally consistent rather than merely encountering an error it couldn't handle, and report the bug as such. This is very rare; practically, they could be turned off.

However, I get reasonable number of assertion violations when trying to change software while in development or while reading the source, and that's where I find them very useful.

I do reserve a special annoyance for slick assertions that are inadequately explained via comment.

How does this not prove my point? Turning off error checking is stupid. Your software will never be bug-free. Start dealing with reality and rename your assertions to sanity checks, which is what they are and always have been.

No. I gave two examples, one where assertions are run in production (mostly because it's easier) and I'm trying to communicate with you that I don't see people leaning on assertions to find bugs in production code very frequently at all, and this is the fear of the Go FAQ. I gave another example were assertions are invariably not compiled into the program when running in production. Am I not being clear about this?

> (it may be "seldom," but then all errors are seldom, hopefully.)

False. Errors (like "no permission to file", "out of disk", "out of memory") are distinct from 'an internal consistency check has failed.'

These happen all the time for completely legitimate reasons.

> Turning off error checking is stupid. Your software will never be bug-free. Start dealing with reality and rename your assertions to sanity checks, which is what they are and always have been.

Strong words. Okay, here's what I think is stupid:

* Software too slow for the purpose.

* Avoiding writing expensive invariants because it would make the software too slow.

* The notational similarity of a broken invariant that intended to never occur vs. an error condition.

My solution has been to accept the last-most option and to stop writing expensive invariants, even though I wish I could succinctly and idiomatically communicate to all maintainers that the invariant is considered impossible rather than merely an error condition and run with the expensive invariants while in development (a global variable and praying to the branch prediction gods can be close enough).

The notational similarity of a broken invariant that intended to never occur vs. an error condition.

Go has a notation for problems that are never supposed to happen: panic. For other errors, there are return codes.

What's your definition of need? I want a lot of invariants if because I have found it reduces the chance of error. This is also the finding in that Microsoft case study I linked to. The more invariants, the better, and that means making them cheap to write.

> In C++, I've even seen people assert that an unsigned integer was >= 0. You can just feel the quality.

Entirely reasonable in some cases; it's telling me: "this software is not defined for negative numbers". There does exist code that can accept an unsigned number (because it is what callers found most convenient at the time, and casting is wordy) but is defined on negative inputs, and it would not be valid to put that assertion there. Those assertions are to assist future collaborators of your software, and shorter to write than:

    // This algorithm is only defined on positive integers

> Go has a notation for problems that are never supposed to happen: panic. For other errors, there are return codes.

Unfortunately I do see panic used -- even in the standard library -- as a flow control mechanism also. But yes, I do use panic for this reason, and tend to eschew using recover for convenience in most situations. It is the lack of an idiom to obtain complete clarity as to the nature of the panic that I find mildly irritating.

I think we're done here.

In one software project I know of, assertions are used to ensure that situations that should never happen never do.

This could be as something as harmless as incorrect (but harmless) usage of a device driver interface, or slightly more terrifying cases that could cause data loss if they occurred.

Before you claim that it should have more unit testing, it actually has mountains of it; again, the assertions are a safety net that prevents even worse things from happening without significantly impacting the performance of a production system.

D, Rust, modern C++, ...

D is but one language (which does not, in and of itself does not fill a vacuum), and I have serious doubts about the social situation regarding its compilers. However, I think it meets most of the other criteria. It also has a lot of features (but not so ridiculously many as C++), however, I'd say it's closer to C++ than C in terms of language size.

Rust is brand new, pre 1.0, and I'm following it with great interest. I do not intend to use it until the low-level error handling has been fleshed out: https://mail.mozilla.org/pipermail/rust-dev/2012-March/00145...

Qualitatively, C++ feels closer to C than Go in many ways in terms of debugging and system aspects, and many C++ programs are written in the "just enough C++" style, which is very nearly C -- and of all possible evils, that is probably the least-evil one in my eyes.

Notably, C++ and D both have have try/catch/finally-style exceptions and inheritance, and while these features can be handy in specific situations, I think both are not desirable. These also apply to Python, a language I also basically like, but I prefer to not have them.

On the contrary, the ternary operator makes the specific operation (setting ONE variable) more explicit, and ensures you only set one var. Consider:

if a == 1: foo = "PASS" else: foo = "FAIL"

and

foo = (A == 1) ? "PASS" : "FAIL"

Why repeat the foo (and risk an error by mistyping it the second time, especially in a dynamic language or with type inference)?

And they add the same amount of cyclomatic complexity (not that you implied otherwise, just sayin').

The closures capturing references thing is a big design bug. If a programmer wants a to share a reference, he has the & operator.

So, you would be able to do:

  l = [];
  for i = 1 .. 10 {
    f = () -> { i += 1; }
    g = () -> { return i; }
    l.append({adder: f, getter: g});
  }

As far as closures capturing references-- if closures captured by value rather than by reference, how would maps and slices be handled? Anywhere the closure used one of those items, it would have to be deep-copied-- a potentially slow operation. Even deep-copying structures could get expensive. The worst part would be that this cost would be hidden to the programmer, who would wonder why his code got so slow all the sudden. I think having them capture references is the only reasonable design given the other design choices.

http://golang.org/pkg/unicode/ lists a bug at the bottom: "There is no mechanism for full case folding, that is, for characters that involve multiple runes in the input or output." So basically, they are aware of the bug / lack of feature and are working on it.