Hacker Newsnew | past | comments | ask | show | jobs | submit | CamperBob's commentslogin

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

Wait, what?


    void func()
    {
    }
vs.

    void func() {
    }
Does Go really enforce the latter? That would be incredibly silly.


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.


One time we worked on some code, and one of the developers had the same habit: "It works, so why do I need to format it?"

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.



My apologies, yes. Don't know why I missed the 8 off there.


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

    def func(arg1,arg2):
        print "Indented"
        return
or full-on no spaces?

    def func(arg1,arg2):
    print "Not indented"
    return
I thought the latter was prohibited.


Sorry, we are talking about that:

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


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.

Not that I have any experience with that...


What about using two characters for assignment?

a := 1 vs a = 1


":=" is type-inferred variable declaration and assignment, while "=" is just assignment.


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.


You might appreciate jslint or closure-compiler - both have their quirks, but they can be tremendously helpful at finding certain errors.


"a := 1" means "var a int = 1" which is not the same as "a = 1"


Having both := and = goes back a long, long, long way. Go isn't even the 100th language to differentiate them.


:= and = don't do what you probably think they do, the meaning is not the same as in Pascal. If you need to compare two variables, you use ==

    if a == b {}
= is the usual assignment, := declares and initializes a variable inferring the type.

    var a int
    a = 42
vs.

    a := 42
That means you'll see explicit types in variable declarations rarely.



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


Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64.


Why on Earth would you want 64 bit ints by default, though? I'm not sure why they are thinking about changing it.


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.

"Fantastically dumb," indeed.


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.


You seem very ignorant

Yeah, that must be it.


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.

Is anyone in this thread over the age of 16?


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.


    void func() {

    }
Is my natural choice anyway, so I guess, this will not stand in my way. Let's go!


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.


Formatting is semantic in Go, newlines are significant, so a brace across a newline is quite reasonably different from a brace on the same line.


As their first business venture together, he and Jobs sold blue boxes.

So, the irony level that was reached when Jobs ordered the creation of a locked-down cell phone platform wrapped clear around 2^32-1 and back to zero.


My wife and I used to live in China, and we did traveling in both the high and the low places.

What was your impression of working conditions on the rural farms that are one of the most often-cited alternatives for many of the Foxconn workers?


My impression is that you should not just a dire or unfair condition based on the existence of an even more dire or unfair condition.

If there is a famine in an area, and people are dying, is it OK to offer them food and water in exchange for slave labour? No pay, just food and water, and everybody that doesn't like can go and die of hunger. How does this deal sound?

A forced choice is not much of a choice.

Also check how the once substinent farm economy is affected by industrialization, pollution and the state push for ever more production.


Hey batista. Good to see you here. Sorry I didn't read your comment before writing a very similar one somewhere else on this thread. Keep fighting the good fight!


If there is a famine in an area, and people are dying, is it OK to offer them food and water in exchange for slave labour? No pay, just food and water, and everybody that doesn't like can go and die of hunger. How does this deal sound?

My impression is that like most Westerners living today, you have no earthly idea what the term "slave labor" actually means, so we'll leave it at that. Peace.


> My impression is that like most Westerners living today, you have no earthly idea what the term "slave labor" actually means, so we'll leave it at that. Peace.

And my impression is that I very much have an accurate idea, plus I hardly consider myself a "westerner", and not only because I'm some 15,000 miles away from the nearest Walmart. It's not like we grew up with Fox News (or NPR at best) -- we have a penchant for history in these here parts plus we have been living it in the live, frequently (including now).

OTOH, you might be unaware that beside the basic determinant (i.e no choice on the matter), slave labour has had a great variety of working conditions in the past. Some were even better that Foxconn by a lot (say, a black lady cooking and/or taking care of the kids in a huge Southern estate would often be treated quite like family -- or in Ancient Greece slaves were even able to amass their own fortune and run businesses, while remaining legally slaves).


That said, the various security clearances you'd have to pick up would virtually guarantee serious compensation in the private sector, if/when you chose to leave. There are a lot of positions that can't possibly be outsourced or filled with H1-B workers.


If they weren't using all that power to spy on US citizens, it might be a bit more palatable. You can make a case for being nosy when it comes to people who aren't covered by our own Constitutional guarantees, but when it comes to US citizens, due process is something I consider awfully important. (And no, "national security letters" are not what I consider due process.)

Obviously not everything the NSA does is a problem from a Constitutional standpoint, but still... the odds of being ordered to do something I would find grossly unethical are too high for me to want to work there.

Worse still, I could see myself modifying my own ethics over time for the sake of staying in my employer's good graces. How many people can honestly say they would never fall prey to that temptation?

A shame, too, because I'll bet they still have some of the coolest toys around, even in the present age of commoditized supercomputing.


The NSA is relatively careful not to do blanket spying on US citizens, at least not directly, outside of specific legally approved programs (the NSLs, combatants, those engaged in communications with a foreign power, etc.). I agree the NSA and military/intelligence overreaches, but the people within NSA do make some effort to obey the law. The right place to change this is with the legislature (and judiciary) -- if there were stronger laws against domestic spying, the NSA would follow them.

It's also quite reasonable (and I'd say honorable) to not work for them, if you think either they're doing something immoral, or it would negatively affect you. I support a lot of the NSA's mission (cyber defense for the US and USG, specific international activity against enemies of the US), but certainly would like to see greater privacy protections in the US, and to protect private citizens (vs. governments) globally.


The problem, Ryan, is that when you have a huge super-secretive military government organization whose people "make some effort to obey the law", there's absolutely nothing stopping them from, one day, with no fanfare, choosing to start ignoring the law when and where convenient.

There are no checks or balances on their power and the potential abuse thereof. They operate in a legal vacuum, with carte blanche to do whatever they decide is necessary. Even THEIR BUDGET is classified information. We're not even allowed to know how many tax dollars they're spending to do illegal shit they're not telling us about.

You can support their mission 100% (I do), and still think that they should be entirely disbanded for this reason alone.

Only criminals would operate in this sort of LEGAL environment.


You've obviously never worked for a government agency if you think anything could 'just happen' one day. It's hard enough to get things done that you ARE legally allowed to do, let alone anything remotely questionable.


I think you're confusing government agencies that have oversight of some kind with those that operate unchecked, like the military intelligence services (NSA, CIA, etc).

They have decades-long histories of doing illegal shit.

http://en.wikipedia.org/wiki/NSA_warrantless_surveillance_co...


At no point did I say they weren't doing anything illegal. Just that it doesn't 'suddenly happen'. They're huge, and very, very slow moving.


Tell that to a country that has had a military coup, or similar. One day the military obeys civilian orders, the next day they don't. Same could happen with NSA. One day they obey the law, the next day they don't.

Wouldn't have to be the whole agency, just some small, but connected, group. They could sell information to foreign countries or, maybe more likely, companies or do all sorts of other socially destructive but personally profitable things.

Of course it doesn't literally happen overnight. But would we know about it if NSA/CIA and similar started going rogue? Seems to me that the government would cover up any extra-legal activities that were discovered so we'd never know until it was too late.


  You've obviously never worked for a government agency if 
  you think anything could 'just happen' one day. It's hard 
  enough to get things done that you ARE legally allowed to 
  do, let alone anything remotely questionable.
That's pure BS. I know of a couple of companies which had done work for gov't agencies which were screwed by powerful individuals in said agencies doing blatantly illegal things. In both cases, the companies involved refused to go along, and paid the price. 7 years down the road, they were "cleared", but the companies' owners had suffered great financial and personal devastation. Nothing happened to the gov't individuals save promotions.


There was a scandal when the NSA's high-volume tap at AT&T came to light. Such a tap at a core router counts as blanket spying. The reaction to it, increased powers and retroactive immunity, speaks volumes.

The very idea that something like “retroactive immunity” can protect someone from the consequences of breaking the law is a bit mind-bending. Whoever comes up with this stuff, it is to protect a culture of unaccountability and disregard for the law.


Out of interest - why do you consider it more unethical to spy on people from one arbitrary geographical area as opposed to people from another? What if they agree not to spy on anyone from Utah and only spy on those suspicious people from other states?

Aren't we all people?


Domestic spying might allow the agency to co-opt its own supervision.


So you might not allow spying of NSA personnel above a particular sensitive grade or something.

And if you're worried about families of NSA personnel being spied on, they might not come from your arbitrary geological area and so are currently fair game.


As oposed to working for Goldman Sachs? Google probably is a bigger threat to an indvidulals privacy than the NSA

So you would be quite happy that All American Terrroists are safer than forign Actors?


> So you would be quite happy that All American Terrroists are safer than forign Actors?

Maybe it goes without saying, but yes, yes, a thousand times yes.

The U.S. Constitution guarantees the rights of everyone in the United States, whether citizen, immigrant, or undocumented, whether law-abiding or terrorist. It specifically guarantees a right to trial, and forbids government searches without a warrant based on probable cause.

The founders knew that government can eat away at vague promises of freedom, and so they guaranteed not only "due process of law" and security from "unreasonable searches and seizures," but also specific mechanisms for protecting those rights from the government. They guaranteed those rights to everyone on our shores.

Personally I hope for a day when everyone in the world is entitled to the same rights. But until that happens -- yes. The law demands that all human beings will be safe on our soil, unless and until they are punished by due process of law. May we find the courage to live up to that demand.


have yet to see any of the loud-mouths spouting off about patents offer to do something like put together a fund to be used in pursuing changes to the laws. An, of course, none of them will write a check for a few million to fund it.

Jeff Bezos was talking a good game there for a while, but nothing ever came of it.


Except someone else is likely to patent the same thing.

Not if the invention is published or otherwise disclosed in any other form. You don't have to claim ownership of an idea to keep someone else from patenting it.


Corporations are like nations: they don't have friends, they have interests.


With treble damages, that could turn into an expensive hobby.


Things worth being made would be prefunded

Prefunding isn't going to get us flying cars, just faster horses.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: