Where do I find out more about the Windows port?

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.

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.

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

Wait, what?

    void func()
    {
    }

    void func() {
    }

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.

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.

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.

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.

We decided to make our build system run PEP over the code, resulting in a failure if PEP didn't pass.

It annoyed the hell out of him, but we quickly got the formatting up to a better standard.

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

    def func(arg1,arg2):
        print "Indented"
        return

    def func(arg1,arg2):
    print "Not indented"
    return

    def func(arg1,arg2):
        i=other_stuff(1,2,3,4,56,43,234+4*3)
        return i

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.

Not that I have any experience with that...

In the long run I'd say multiple assignment probably saves you more time writing declarations than an extra key-stroke would cost you.

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.

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.

    if a == b {}

    var a int
    a = 42

    a := 42

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)
  }

You seem very ignorant, please learn and stop the FUD.

Yeah, that must be it.

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)

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.

Is anyone in this thread over the age of 16?

If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.

    void func() {

    }