Live data from Hacker News

Why I went from Python to Go (and not node.js)

orel.li

191–200 of 202 posts

Re: Why I went from Python to Go (and not node.js)

#191
post #140

Earlier quoted context omitted.

it depends on what your goal is. A language is just one tool in your toolset. I love using Go very much, but I would recommend learning on Python. There's much more literature out there, more people you know will know it, and if you are looking for work, there are effectively zero entry-level programming jobs in Go. The reason you keep hearing about Go is that it just very recently hit its 1.0 release, so it it a com…

> People you know will know it Actually, not without going out and meeting new people. I'm a physician, so meeting anyone who knows anything about IT is quite challenging. And the helpdesk folks at the hospital usually aren't in the mood to troubleshoot those kinds of errors!

ah, I initially met most of the programmers I know though hackathons and meetups. Startup Weekend was one of the first things I went to where I met a lot of people, and that happens basically everywhere.

Re: Why I went from Python to Go (and not node.js)

#192
post #65

Earlier quoted context omitted.

I recommend starting with http://tour.golang.org/#1 . Yes, the Go tool comes with package-management capabilities. "go get labix.org/v2/mgo" will download the very excellent MongoDB driver mgo, for example.

Neat, is there something like virtualenv or rvm so I can install it locally not systemwide?

Just change GOPATH and you're done.

Re: Why I went from Python to Go (and not node.js)

#193
post #189

Earlier quoted context omitted.

> you need real computer science. Reality and PHP would disagree for 90 to 99% values of "you".

Depends where in the world you work, in Europe most IT companies only hire developers with CS degrees.

Swap "CS" for "technical" and you'd be right.

Re: Why I went from Python to Go (and not node.js)

#194

Earlier quoted context omitted.

For what it's worth, I've used Python professionally and in several classes. I certainly don't have much experience in it, but it would be odd if I did--why would I use a language I don't particularly like too much? You only say there are no horrible gotchas with tuples because you've never spent hours hunting down a bug and finding that you forgot a trailing comma. More pertinently, changing something like ("foo", "…

I don't get your tuple example. If you don't use the tuple operator - the comma - why would you expect to get a tuple? People trot Python out as the gold standard of language design Who?

> I don't get your tuple example ...

The point is that it's a subtle syntactical difference but a dramatic semantic difference. I think most newcomers to Python hit this.

Re: Why I went from Python to Go (and not node.js)

#195
post #182

Earlier quoted context omitted.

For what it's worth, I've used Python professionally and in several classes. I certainly don't have much experience in it, but it would be odd if I did--why would I use a language I don't particularly like too much? You only say there are no horrible gotchas with tuples because you've never spent hours hunting down a bug and finding that you forgot a trailing comma. More pertinently, changing something like ("foo", "…

I'm so confused. You seem to be saying that > 4 * (3+2) should throw: > TypeError: unsupported operand type(s) for *: 'int' and 'tuple' ??? I beg to differ.

No, parent is saying that:

>>> isinstance(tuple, ("foo", "bar"))

True

>>> isinstance(tuple, ("foo"))

False

which is correct. In Python, a single-element tuple must end with a comma--otherwise it is just that element, e.g.:

"foo" == ("foo")

FWIW, OP is right--finding a bug related to this issue is almost a rite of passage for new Python devs.

Re: Why I went from Python to Go (and not node.js)

#196
post #90

"... as a Python programmer, I was the member of an elite cabal of superhuman ultranerds, smarter than those childish Rails/JavaScript/PHP/whatever developers that couldn’t write a bubble sort or comprehend even basic algorithmic complexity, but more in touch with reality than the grey-bearded wizards of Lisp/Haskell/whatever that sat in their caves/towers/whatever solving contrived, nonexistent problems for people t…

"Everyone less nerdy than me is stupid and everyone more nerdy than my is a no-life". I think it's pathetic, not funny.

There is apparently something wrong with your ability to detect when something is said in jest.

Re: Why I went from Python to Go (and not node.js)

#197
post #182

Earlier quoted context omitted.

I'm so confused. You seem to be saying that > 4 * (3+2) should throw: > TypeError: unsupported operand type(s) for *: 'int' and 'tuple' ??? I beg to differ.

No, parent is saying that: >>> isinstance(tuple, ("foo", "bar")) True >>> isinstance(tuple, ("foo")) False which is correct. In Python, a single-element tuple must end with a comma--otherwise it is just that element, e.g.: "foo" == ("foo") FWIW, OP is right--finding a bug related to this issue is almost a rite of passage for new Python devs.

I'm not clear on what in my comment you're saying "no" to. isinstance(tuple, ("foo")) being True is not a "rough edge" (or if it is anything people are ever confused by is a rough edge). If it were True, that would also mean you couldn't use parentheses to set the order of operations, since items inside parentheses would be tuples. That would be nuts.

IMO this is just an educational issue where people aren't taught that the comma is the tuple operator (e.g. `x = 3,4` is perfectly legal) and parentheses just come along for the ride to disambiguate other uses of commas. If I were king tuples wouldn't have the same syntax as argument lists (`f((3,2))` is pretty ugly), but both Python tuples and Python argument lists conform to a lot of people's expectations of how both those things should look.

The fact that duck typing makes tuples and literals (temporarily) indistinguishable to the interpreter is more of a rough edge of duck typing itself. Duck typing can result in tricky bugs in many scenarios well beyond singleton tuples.

Re: Why I went from Python to Go (and not node.js)

#198
post #197

Earlier quoted context omitted.

No, parent is saying that: >>> isinstance(tuple, ("foo", "bar")) True >>> isinstance(tuple, ("foo")) False which is correct. In Python, a single-element tuple must end with a comma--otherwise it is just that element, e.g.: "foo" == ("foo") FWIW, OP is right--finding a bug related to this issue is almost a rite of passage for new Python devs.

I'm not clear on what in my comment you're saying "no" to. isinstance(tuple, ("foo")) being True is not a "rough edge" (or if it is anything people are ever confused by is a rough edge). If it were True, that would also mean you couldn't use parentheses to set the order of operations, since items inside parentheses would be tuples. That would be nuts. IMO this is just an educational issue where people aren't taught t…

I responded to this point (which was phrased as a question):

You seem to be saying that 4 (3+2) should throw: TypeError: unsupported operand type(s) for : 'int' and 'tuple'???

Parent wasn't saying that at all, and I was clarifying.

Re: Why I went from Python to Go (and not node.js)

#199
post #197

Earlier quoted context omitted.

I'm not clear on what in my comment you're saying "no" to. isinstance(tuple, ("foo")) being True is not a "rough edge" (or if it is anything people are ever confused by is a rough edge). If it were True, that would also mean you couldn't use parentheses to set the order of operations, since items inside parentheses would be tuples. That would be nuts. IMO this is just an educational issue where people aren't taught t…

I responded to this point (which was phrased as a question): You seem to be saying that 4 (3+2) should throw: TypeError: unsupported operand type(s) for : 'int' and 'tuple'??? Parent wasn't saying that at all, and I was clarifying.

Sorry to belabor the point, but this is exactly what parent was saying.

> changing something like > ("foo", > "bar", > "baz") > to > ("foo") > actually breaks the code.

Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.

Re: Why I went from Python to Go (and not node.js)

#200
post #199

Earlier quoted context omitted.

I responded to this point (which was phrased as a question): You seem to be saying that 4 (3+2) should throw: TypeError: unsupported operand type(s) for : 'int' and 'tuple'??? Parent wasn't saying that at all, and I was clarifying.

Sorry to belabor the point, but this is exactly what parent was saying. > changing something like > ("foo", > "bar", > "baz") > to > ("foo") > actually breaks the code. Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.

No, he's saying that the operation you perform to truncate the former to the latter is the operation you would logically expect to perform (i.e. removing the trailing comma), which makes the thing a string.

He's not actually proposing that a string be a tuple. He's just saying that a single element enclosed in parentheses doesn't work the way you'd expect it.

Post reply on HN