Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things from Python I'd miss in Go

yosefk.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Things from Python I'd miss in Go

#131

Post by seanmcdirmid »

dragonwriter wrote: post #116
seanmcdirmid wrote: post #111

Earlier quoted context omitted.

Defer is basically finally without block structure, triggered instead by the popping of the surrounding procedural call context. So instead of a block, you have to create a new function instead to unwind...how is the extra complexity of avoiding simple block structure worth it? And what is the equivalent of catch if we have an equivalent of finally? It seems to be recover, which allows a deferred execution to query w…

> Defer is basically finally without block structure, triggered instead by the popping of the surrounding procedural call context. So instead of a block, you have to create a new function instead to unwind...how is the extra complexity of avoiding simple block structure worth it? How is function structure any more complex than block structure?(I mean, visually , sure, there are potentially a few extra sigils, but str…

Thank you. I'd still like to know why this is better and not just different. Or is there some legacy design I'm missing, like in one of Rob Pike's previous languages?

Re: Things from Python I'd miss in Go

#132

Post by gbog »

smnrchrds wrote: post #87
gbog wrote: post #13

When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.

Can you please elaborate. I don't understand what could be wrong with keyword arguments. Also I can't see how an unused import can waste a life, unless there is some lethal side-effect to importing that package (I don't like import side-effects, but they are inconvenient whether the import is used or unused). Exceptions seem pretty useful as well.

Python's keyword arguments:

    def f(a, b=1, c=2):
        pass
Now, same call can be written `f(0, 1, 2)` and `f(0, b=2, a=1)`, which makes it much harder to refactor. For instance, suppose you want to add a non-keyword argument, you'll have to carefully grep for all calls.

I think functions should be either full keyword arguments and naming them in calls should be mandatory. Or no keyword arguments at all. The mixing of both is "convenient" for prototyping, but has a high long-term cost.

Unused imports:

In a module bar, you have `import foo`. How do you know if it is used or not? You'll have to scan all modules importing bar to check if they import foo. Granted, the problem is not that import foo is unused, but that it is imported in bar's namespace.

Exceptions make it hard to follow code paths and easy to hide important events. The hardest debugs I've endured are because of exceptions. An innocent looking `except AttributeError` can be hiding a deep issue in some remote library playing badly with getattr magic.

That said, I love Python, and still think it is the most elegant language. I will most certainly teach Python to my kid when he'll be old enough. I also believe it is best suited for a full serie of programming tasks. But, when code base grow in size and complexity, some of its "tolerance" become a burden.

Re: Things from Python I'd miss in Go

#133

Post by niemeyer »

sergiosgc wrote: post #129
niemeyer wrote: post #71

Earlier quoted context omitted.

You are assuming the use of exceptions is an evolution in the first place, but that's far from being a consensus. To some of us, exceptions are very convenient, but more easily lead to brittle software. I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about. http://blog.labix.org/2013/04/23/exception…

Exceptions are, when you boil it down to the core, a default behavior for error conditions. It states that, on error, execution jumps to the first point in the code path expecting the error. If no such point exists, execution halts. This is a stark contrast to the default behavior for error returning, which is to carry on as if nothing happened. How can "keep calm, carry on" be construed as better is beyond me. Now,…

It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the success case. In my experience with the medium sized projects I've been closely responsible for (in the hundreds of thousands of lines ballpark), we were interested in doing a really good job in both the exception and the error result cases, because the misbehavior scenario is a real issue, and followed all the good practices in the modern developer's backpack. In the end, exception-rich code just turned out obviously hard to get right, no matter how much we _wanted_ to get it right, because the program is allowed to jump out of arbitrary stack frames that the developer was conveniently taught to not handle errors on, because.. hey! the "default behavior"!

After getting involved in these experiments, I started paying more attention to how people can possibly be happy with exception-rich logic that behaves like that. My empiric observation is that the lack of proper error handling turns out to have a relatively low impact for lots of projects. Crashed or misbehaved? Whatever.. file a bug.

Re: Things from Python I'd miss in Go

#134

Post by niemeyer »

sergiosgc wrote: post #130
niemeyer wrote: post #71

Earlier quoted context omitted.

You are assuming the use of exceptions is an evolution in the first place, but that's far from being a consensus. To some of us, exceptions are very convenient, but more easily lead to brittle software. I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about. http://blog.labix.org/2013/04/23/exception…

Just read your post. It's the poor coder theme, a variant of the poor code theme. Sorry, I don't code poorly and I'm not about to shackle myself for fear of a nonexistent boogeyman.

Ah, I see, you're still in the upwards trend of thinking you have a superior mind. Been there.. eventually I learned that I too suck, and need all those tricks that encourage me and the teams I work with to up the stakes in terms of project quality.

Re: Things from Python I'd miss in Go

#135

Post by jobquestion123 »

voidlogic wrote: post #113
ironchef wrote: post #6

Earlier quoted context omitted.

"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me. I've been moving a lot of ETL into Go (as it's pretty well suited to this), but I still end up doing a lot of the analytics in Spark (for bigger work) or Pandas or R (for smaller bits of data). What are you guys planning on doing for the analytics? Or is it more of straight up time series work (so you can use influx + w…

"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me.... Go is great for this kind of stuff. Spark is great when you have a lot of custom queries, but if you have a few fixed queries writing a simple solution in Go have have huge gains. I worked to implement a web service + simple map reduce (with network transparency) + a time series DB (storage engine too, NOT using leve…

Did you use a framework to run mapreduce with go or did you roll your own?

Re: Things from Python I'd miss in Go

#136

Post by [deleted] »

nostrademons wrote: post #124
klibertp wrote: post #114

Earlier quoted context omitted.

> but the constant context switching caused a real and permanent performance hit Maybe context switches were too frequent? Or the opposite, too rare, which could lead to repeating the learning overhead each time? Personally I didn't notice any slowdown due to switching between languages and technologies - other then at the beginning, when I was learning them.

For me, it's the infrastructure & best practices that's the biggest cost. There are degrees of language learning. I went through a "everyone should be a polyglot programmer" phase when I had about 3-4 years of experience, because I was then proficient - not expert - at about a half dozen languages. At that point, I knew the syntax and semantics of all of them, the common standard library calls that I needed for every…

[deleted]

Re: Things from Python I'd miss in Go

#137

Post by klibertp »

nostrademons wrote: post #124
klibertp wrote: post #114

Earlier quoted context omitted.

> but the constant context switching caused a real and permanent performance hit Maybe context switches were too frequent? Or the opposite, too rare, which could lead to repeating the learning overhead each time? Personally I didn't notice any slowdown due to switching between languages and technologies - other then at the beginning, when I was learning them.

For me, it's the infrastructure & best practices that's the biggest cost. There are degrees of language learning. I went through a "everyone should be a polyglot programmer" phase when I had about 3-4 years of experience, because I was then proficient - not expert - at about a half dozen languages. At that point, I knew the syntax and semantics of all of them, the common standard library calls that I needed for every…

Thanks for a thoughtful comment. I am aware of the things you mention, I just quietly assumed that "knowing" a language means knowing it and its ecosystem inside out, with all the major tools and libraries, how the major implementations work and how they differ and so on.

I wouldn't advise going for polyglot programming without expert-level knowledge in at least most of the involved technologies. You're right that it's significantly harder to learn a language really well instead of just familiarizing yourself with basics and that it gets even harder when there are multiple languages involved, because the amount of quirks and peculiarities grows significantly with each of them.

Nevertheless, I believe it is possible and I consider myself one anecdata point :) Although it took me a decade or so to get here, and I see a very long way ahead of me still, I already had a pleasure of putting my fairly deep knowledge of different languages and environments (it was C, Erlang, Python and JavaScript in this case) to use, with quite a bit of success for the project.

So yes, it's hard and I understand why people don't like the idea, but I just can't agree with them, as in my experience most of the arguments against polyglot programming (on the programmers' side, management is another issue and their problems are much more real) just don't hold true.

Re: Things from Python I'd miss in Go

#138

Post by moreentropy »

moreentropy wrote: post #79
pekk wrote: post #67

Earlier quoted context omitted.

You shouldn't be putting a try-except catchall around every single call in Python. Exceptions mean you don't have to do that.

For me the most important thing exceptions mean is that they might pop up at any time, with unpredictable types. So as long as I don't have a catch all exception handler wrapped around all code, it might crash at some point.

This one really deserved downvoting, great job whoever did that :/

Re: Things from Python I'd miss in Go

#139

Post by dragonwriter »

seanmcdirmid wrote: post #131
dragonwriter wrote: post #116

Earlier quoted context omitted.

> Defer is basically finally without block structure, triggered instead by the popping of the surrounding procedural call context. So instead of a block, you have to create a new function instead to unwind...how is the extra complexity of avoiding simple block structure worth it? How is function structure any more complex than block structure?(I mean, visually , sure, there are potentially a few extra sigils, but str…

Thank you. I'd still like to know why this is better and not just different. Or is there some legacy design I'm missing, like in one of Rob Pike's previous languages?

> I'd still like to know why this is better and not just different.

Its potentially more flexible, in that it doesn't restrict the "generic" cleanup code to run strictly after the exception handling code; this also probably makes things a bit more clear in the instances where you want to apply logic in the guaranteed-closeout that might affect return values but needs to consider errors in the event they occurred.

Re: Things from Python I'd miss in Go

#140

Post by voidlogic »

jobquestion123 wrote: post #135
voidlogic wrote: post #113

Earlier quoted context omitted.

"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me.... Go is great for this kind of stuff. Spark is great when you have a lot of custom queries, but if you have a few fixed queries writing a simple solution in Go have have huge gains. I worked to implement a web service + simple map reduce (with network transparency) + a time series DB (storage engine too, NOT using leve…

Did you use a framework to run mapreduce with go or did you roll your own?

We wrote our own, Go 1.0 had just come out.
Post reply on HN