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

71–80 of 142 posts

Re: Things from Python I'd miss in Go

#71

Post by niemeyer »

sergiosgc wrote: post #37
atilaneves wrote: post #12

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code an…

From what I understand, Go is an opinionated language, with a nice concurrency framework. It's not groundbreaking, it's not particularly expressive or adapted to any specific use case. It so happens that if your style fits Go's ideology (opinionated view), you become a fan. For me, the lack of exceptions kills the language. C-like error testing smells like a twenty year de-evolution. I also dislike the flat object mo…

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/exceptional-crashes

Re: Things from Python I'd miss in Go

#72

Post by micro_cam »

So I do a lot of scientific programing in go [1]. I am absolutely still using python + numpy/scipy/pyamg for linear algebra heavy stuff but this has more to do with the available and well documented packages then operator overloading.

I actually find that the interfaces used for math [2] encourage a more memory efficient coding style. Without operator overloading I'm less tempted to jam everything into a pretty one liner and more likely to set things up to work with out unintended reallocations.

Lack of efficient generics is a much bigger annoyance.

[1] See for example my random forest package https://github.com/ryanbressler/CloudForest [2] See package big for example http://golang.org/pkg/math/big/

Re: Things from Python I'd miss in Go

#73

Post by [deleted] »

dragonwriter wrote: post #69
[deleted] wrote: post #63

Earlier quoted context omitted.

[deleted]

I'm not objecting to you choosing not learn something in depth because you don't like how it looks on the surface (that's a rational approach to avoiding wasting time, which is a valuable resource), I'm objecting to you, in the linked article, commenting in depth (and inaccurately) on something its clear that you decided not to learn in depth because you didn't like how it looks on the surface. The statement that Go…

[deleted]

Re: Things from Python I'd miss in Go

#74

Post by drdaeman »

S4M wrote: post #46
jamra wrote: post #29

Earlier quoted context omitted.

It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost ne…

> I almost never used operator overloading in C# or Java. Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java): Matrix a = zeroMatrix(4,4); Matrix b = identityMatrix(4,4); Matrix c = a+b; You can't do that, so you would have to w…

Which leads us to that ugly a.equals(b) instead of sane a == b. When not abused, operator overloading is a bless.

Re: Things from Python I'd miss in Go

#75

Post by rogerdpack »

pjc50 wrote: post #36
rogerdpack wrote: post #16

Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case... Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time. Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt] Another t…

Java is faster to build than C++ almost all of the time. Header files (especially with templates) tend to turn C++ in to an O(n^2) run time, often running into hours.

OK, the only thing I can compare it against is my current "java" build times, and I can tell you that using maven is somewhat slow. So I guess you could say that if people went to java from c++ for the improved build times, they might still be interested in Go for the same improvement over java :)

Re: Things from Python I'd miss in Go

#76

Post by seanmcdirmid »

dragonwriter wrote: post #61
seanmcdirmid wrote: post #44

Earlier quoted context omitted.

Generic methods is one place where non-explicit error handling is essential. What if your map/select call fails? You have to make sure to thread error handling through everything that would ever take another function as an argument (since the error handling characteristics of the unknown function are open), which, in this day and age, is ridiculous. C# couldn't do LINQ at all in this case. Sometimes a bit of dynamic…

> Generic methods is one place where non-explicit error handling is essential. And, really, the error-handling part fits fairly well with Go (not only what the language supports -- which is, after all, full-featured exceptions with a different [IMO, improved] syntax -- but also with the conventions on their use across public API, though that requires some thought about the motivation for that rule and how it applies…

> OTOH, Go's type system, as opposed to its error-handling approach, is a real problem for generic functions. Though if you just mean non-generic higher-level functions, this is less of an issue.

Without generic types, I don't think generic programming is very common in Go and exceptions won't be missed much yet. However, if they ever get around to adding them, I expect dominoes to fall :)

> To fit with the Go convention on panics and public APIs, you should wrap any function that results from applying such a higher-level function to a function that an fail into another function that recovers from panics and provides error returns before passing the resulting function across a public API boundary.

So panic is basically an exception but in callback form rather than block form? Holy Hollywood principle! I'm not sure what you can hope to accomplish in a callback that would make the immediate calling context sane again.

Re: Things from Python I'd miss in Go

#77

Post by rdtsc »

jamra wrote: post #29
jgrahamc wrote: post #3

Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. A…

It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost ne…

> It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument.

But you also seem to be using a bit of a straw man here as well, aren't you?

You focus how he picked numpy and operator overloading.

Ok how about REPL, does go have one? No.

Does it support dynamic code loading?

Does it have exceptions?

He wants exceptions. That is his post. Remember, the title "Things I'd miss". Not things "jamra" should miss.

Let's continue.

Does Go have a lot of GUI bindings? No. Ok talk about that maybe as well.

> He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression.

So where is your blog post then?

Re: Things from Python I'd miss in Go

#78

Post by niemeyer »

atilaneves wrote: post #12

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code an…

To satisfy your curiosity, I have a long and public track record on Python, and switched to Go as the preferred language around mid-2010, for many reasons. These were both related to the properties of Go and to frustrations with Python itself. Initially that was a personal move, but several months later we also started to choose Go for projects where Python would have been the choice within Canonical as well.

Re: Things from Python I'd miss in Go

#79

Post by moreentropy »

pekk wrote: post #67
moreentropy wrote: post #17

Earlier quoted context omitted.

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something wh…

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.

Re: Things from Python I'd miss in Go

#80

Post by rogerdpack »

ant_sz wrote: post #10

As for the GUI problem mentioned in the article, we now have https://github.com/andlabs/ui I haven't yet tried this lib, It may not as good as something as Qt, but I think it is a good beginning.

Yeah he says "Go's Qt bindings are 'not recommended for any real use'" but he is only linking to a 3rd party library that's [apparently] not ready for real use--I guess he could "there are not yet good Go bindings for Qt", or "the GUI toolkits are less developed than Python's" or "Go has no built in GUI but python does (tkinter)" [does anybody use tkinger anyway?].

Another thing that confuses me here is that he's saying "here are things I think I'd miss if I moved from Python to Go" without ever having done it to see if he actually misses them...[once more familiar with Go, he may end up not missing them as much as he anticipated].

Curiously absent also is a mention of significant whitespace, perhaps he wouldn't miss it? :)

Post reply on HN