I prefer the node.js example given over the Go example.
Sure, the go example is shorter, but the JavaScript version reads much nicer (at least to me).
Why I went from Python to Go (and not node.js)
151–160 of 202 posts
Re: Why I went from Python to Go (and not node.js)
#152Earlier quoted context omitted.
There is no 'horrible gotcha' with tuples of one element. Have you even tried generator expressions? Do you have any specific performance problem, or do you just suppose that you couldn't write sufficiently performant code in Python? Overall, from your post, I don't believe you have used Python seriously. I don't care what color Python would be, nor would I care what ice cream flavor it would be. Nor do I care whethe…
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", "…
Doing that makes it not a tuple but just a string that's in brackets.
Anybody that's done Python for more than a day will instantly know that you'd do ("foo",), and to be honest you'd more likely write it as
(
"foo",
"bar",
"baz",
)
Re: Why I went from Python to Go (and not node.js)
#153Earlier quoted context omitted.
> one major problem is that Go can't construct new types at runtime. The current implementations can't. I don't see any reason why one couldn't. In any case, I don't think that's such a big deal. One just goes from completely seamless interactive coding to mostly seamless interactive coding. > Unless one builds a full Go interpreter That is precisely what I was proposing. (Are you implying some sort of hard VM/interp…
Go's compiler is said to be fast. Could you fake interpretation by continually recompiling everything?
Compiling is the easy part, transplanting state is the hard part.
Re: Why I went from Python to Go (and not node.js)
#154"... 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.
Just a joke from the author, why so serious, everybody?
Re: Why I went from Python to Go (and not node.js)
#155Earlier quoted context omitted.
There is no 'horrible gotcha' with tuples of one element. Have you even tried generator expressions? Do you have any specific performance problem, or do you just suppose that you couldn't write sufficiently performant code in Python? Overall, from your post, I don't believe you have used Python seriously. I don't care what color Python would be, nor would I care what ice cream flavor it would be. Nor do I care whethe…
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", "…
People who like programming languages are not the intended users. People who like programming are, and in my experience there is rather less overlap between these two groups than you might think.
Re: Why I went from Python to Go (and not node.js)
#156Wait a few weeks, for his followup article entitled "Why I came back to Python....two words...mature libraries"
I have found at least the Go stdlib much more uniform and reliable than the Python stdlib, perhaps not as complete, but it also has things that are missing from the Python stdlib, and unlike with the Python stdlib I don't find myself reaching from alternatives, the Go stdlib has great template system, image manipulation, etc.
Third party libs still are more uneven, but that is not much different from Python.
Re: Why I went from Python to Go (and not node.js)
#157According to Google Dart is better for web apps than Go.
Is it too early to switch from Python/Ruby to Go? Maybe it would be better to wait for Dart.
I known that Mozilla and MS won't support Dart however they also don't support Go.
Re: Why I went from Python to Go (and not node.js)
#158Why would anyone go to Node.js? Serious question.
Re: Why I went from Python to Go (and not node.js)
#159Earlier quoted context omitted.
It's actually kind of bizarre that so many Pythonistas actually have the kind of attitude that the article mocks, since Python is a thoroughly mediocre language. I can only attribute their patronizing disposition to a lack of genuine awareness of the broader programming world.
How many Pythonistas? I would like you to substantiate this claim. I would assume that you actually don't have that much contact with the Python community because otherwise it is pretty unaccountable how I have never encountered that attitude all these years. and I am a grumpy person, and not without my own axes to grind about the Python community.
I can relate to what he said, like the grandparent here it made me laugh.
I wouldn't say i espouse the view presented (have too much respect for what's been achieved in the other camps such as Ruby and even PHP), but internally yeah i think i do view the world that way.
I don't think it's any different from the common "anyone driving slower than you is a doddler, anyone faster is a maniac" - a patently absurd view to hold.
The enlightening part for me is that other pythonistas think this way, because as you said, i have also never experienced this view expressed publicly by the python community.
Re: Why I went from Python to Go (and not node.js)
#160Earlier quoted context omitted.
This is a very good example of the type of thing I'm talking about. Nobody prompted you to do so, but you gracefully handled the case of a DNS failure in your code, because the control path was obvious throughout. Go makes this type of error handling a topic very early on in the literature. I find this type of clarity when structuring concurrent code to be very helpful in minimizing subtle concurrency bugs.
On error handling in Go vs. Python: Lack of exceptions means the deeper the call stack the higher the proportion of error handling code relative to a normal (non-exceptional) code path. For example, if you decide to refactor some code from a bigger function into its own smaller function then all error handling code have to be repeated twice (first in the child function then in the parent that calls it). It introduces…
Coming from Python, I was of the same opinion at first. A significant amount of error handling lines is what I noticed first when looking at Go code[0], too.
However, I was interested to learn that Google style guide for C++ recommends not using exceptions. I don't know C++ (shame), but at least some of their reasoning is applicable to Python as well:
For example, when you start raising an exception in a Python function, you have to check its callers, whether they (or their callers) handle it. And vice-versa—when a Go function has “expected” error in its signature as return value, it's very obvious what you need to handle when you're the caller.
“Expected” error as return value also encourages single responsibility principle, I suppose. E.g., for a function that decodes JSON, bad syntax is “expected” error, the rest is a reason to panic().
I'm not sure if I get your example with refactoring, but it may be a case when you use panic() in inner function, recover() in outer, and return an error as usual.
That said, I've never actually used Go yet, so it's just theorizing.
[0] But then my Python code that (to me) looks more or less “solid” appears to contain a comparable amount of error handling lines, so not sure if it's a good metric.