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

121–130 of 142 posts

Re: Things from Python I'd miss in Go

#121

Post by nostrademons »

niemeyer wrote: post #112
_yosefk wrote: post #60

Earlier quoted context omitted.

Erm... so: * I didn't "find" my use cases - they found me. All are real things I do with Python. * I'd switch to something faster than Python, and finding more errors statically, if it wasn't for the bunch of things I'd miss. * I like C better than C++ though the former lacks operator overloading; it's not "the essence of a good language", just one thing I use in Python. * Further evidence that "I'm not here to bitch…

You've been saying that it's just about your own use cases, but your statements in that post are much more general. For example: > What does Go have that Python lacks? Performance, static typing. That's a very simplistic view. Being a long term Python developer that switched to Go as the preferred language years ago, here are some of the things I appreciate on the other side of that fence: - Performance, indeed. - St…

I'm curious - why did you go with Python over Java in the first place? Many of your bulletpoints are also things that Java gives you, except for the duck-typed interfaces, goroutines, and control over memory layout.

Re: Things from Python I'd miss in Go

#123

Post by srean »

onalark wrote: post #110
adwn wrote: post #105

Earlier quoted context omitted.

> If you want/need maximum performance, why are you programming in a "high-level language"? Because going to assembly offers so little benefit (if at all), that it doesn't justify the huge increase in effort and susceptibility to bugs in most cases (and even then, inline assembly is usually sufficient). > Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly ins…

edit: Jack Poulson's Elemental, and Andreas Waechter's IPOPT are also written in C++, and are both very important libraries within scientific computing and optimization, to add a few more examples of the usefulness of C++. I'm trying to make the point that C++ occupies a weird place in the abstraction-vs-performance tradeoff. For high abstraction and friendliness, C++ doesn't do nearly as nice of a job as MATLAB or P…

>For high abstraction and friendliness, C++ doesn't do nearly as nice of a job as MATLAB or Python in exposing high-level scientific computing operations.

I think you responded to it yourself in the next paragraph.

While not quite the same as using MATLAB or Numpy; with Eigen, Blitz++ and Armadillo you can come really close syntactically. You do have to suffer through the compilation process but it comes with computational benefits. Numpy and its ilk are adversely affected by the limitation of their vectorization paradigm, some more, some less. This style creates needless copies, unnecessary and overly pessimistic loops. These cost performance. Eigen/Blitz++/Armadillo style libraries do not suffer from this problem. A common Pythonic way to recover from these deficiencies of Numpy is to use Cython (and numexpr although it has a very narrow scope). However, to see speedups in these tight numerical loops with Cython one really has to do manual indexing, write at a low level, not so for Eigen/Armadillo/Blitz++.

This, although very limited in scope, is a concrete example that shows that you can write at a higher level in C++ without incurring performance hits.

Re: Things from Python I'd miss in Go

#124

Post by nostrademons »

klibertp wrote: post #114
gejjaxxita wrote: post #90

Earlier quoted context omitted.

The drop in performance isn't just while learning. I worked somewhere where I had to regularly use TCL, Java, PHP, C++ and Python - each was the most suitable tool for the job (at the time the tool was written anyway) but the constant context switching caused a real and permanent performance hit.

> 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 everyday programming, and most importantly, I could mentally map between constructs in my head. So I'd be like "This is a 'for x in collection' loop in Python, a 'for (String x : collection)' in Java 5, a 'for (var x, i = 0; x = collection[i++];)' in Javascript', a 'map (\x -> ...) collection' in Haskell".

I'm coming up on 10 years of experience now, and I try to limit the number of programming languages I work with pretty dramatically now. What's changed is that I now think of a language as an ecosystem and a culture, rather than a set of things I type into a computer. The typing is automatic; instead I'm thinking of the level of "Well, if I use Mockito and JUnit for my unit testing, here's how I have to set up my Dagger modules, and I can use Providers there to give me a dependency graph of ListenableFutures that will let me kick off a whole cascade of RPCs when a request comes in, all without having to manually manage the sequence of events." And all of those libraries have gotchas and best practices that I've internalized, which I think need to page out if I start working with another ecosystem. (This was perhaps a bad example because I'm actually much more fluent with Python and Javascript than Java now - but then, maybe that makes it a good example, because it shows how much tacit knowledge is important even for a simple forum comment, let alone a working system.)

So I can't really judge your level of expertise over the Internet. But I'll caution you that views on this can flip-flop as you gain more experience. It's important to really learn one language well before judging that everybody should be able to use multiple languages with equal proficiency. "Learning them" is a continuous process, and there're tips and tricks that are very specific to each language that you continue learning even decades in.

[1] http://www.reddit.com/r/haskell/comments/cguuj/a_haskell_web...

Re: Things from Python I'd miss in Go

#125

Post by rmrfrmrf »

drdaeman wrote: post #74
S4M wrote: post #46

Earlier quoted context omitted.

> 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.

Except that a == b and a.equals(b) are two different things.

Re: Things from Python I'd miss in Go

#126

Post by kyrra »

srean wrote: post #118
niemeyer wrote: post #112

Earlier quoted context omitted.

You've been saying that it's just about your own use cases, but your statements in that post are much more general. For example: > What does Go have that Python lacks? Performance, static typing. That's a very simplistic view. Being a long term Python developer that switched to Go as the preferred language years ago, here are some of the things I appreciate on the other side of that fence: - Performance, indeed. - St…

> - Performance, indeed. I have been really disappointed and underwhelmed by Go's performance (I have not tried the gccgo yet). For such a simple, statically typed language I was expecting really an order of magnitude better performance. So, in light of Cython and Pypy the performance story is quite murky, the other points do stand.

Performance is always a hard topic to talk about. For almost any language you can optimize hotspots in the code to make it go super-fast. You can make any code run slow in any language if you are not familiar with how the language behaves.

Go has pprof which allows for profiling of your code to help find the hotspots. Without a specific case it's hard to say that Go is fast or slow compared to other languages.

Re: Things from Python I'd miss in Go

#127

Post by moreentropy »

TheLoneWolfling wrote: post #99
moreentropy wrote: post #79

Earlier quoted context omitted.

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.

Assuming you're talking about unchecked exceptions, correct.

Python doesn't have checked exceptions.

Re: Things from Python I'd miss in Go

#128

Post by niemeyer »

kyrra wrote: post #126
srean wrote: post #118

Earlier quoted context omitted.

> - Performance, indeed. I have been really disappointed and underwhelmed by Go's performance (I have not tried the gccgo yet). For such a simple, statically typed language I was expecting really an order of magnitude better performance. So, in light of Cython and Pypy the performance story is quite murky, the other points do stand.

Performance is always a hard topic to talk about. For almost any language you can optimize hotspots in the code to make it go super-fast. You can make any code run slow in any language if you are not familiar with how the language behaves. Go has pprof which allows for profiling of your code to help find the hotspots. Without a specific case it's hard to say that Go is fast or slow compared to other languages.

That's not about how much the code might be optimized. I could always step out of Python and do a C module if I needed speed.

Instead, what's valuable in terms of the perceived performance delta is the speed of standard code as one would write intuitively and conventionally. With a reasonable understanding of how CPython compiles and interprets code, and a reasonable understanding of how the standard Go compiler suite generates binary code, one can make ballpark-style statements of performance for such code without lying too much.

Sure, there's PyPy, and there's gccgo, but that's not what most of the respective communities are using today, and it's not what we use in the projects I'm part of either.

Re: Things from Python I'd miss in Go

#129

Post by sergiosgc »

niemeyer wrote: post #71
sergiosgc wrote: post #37

Earlier quoted context omitted.

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/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, I know the arguments against exceptions are supported on all kinds of horror code using exceptions out there. Let me preempt that by stating that assessing a tool for its wrong uses is not a good evaluation of the tool. A hammer is not a good screwdriver, there are no news there.

Re: Things from Python I'd miss in Go

#130

Post by sergiosgc »

niemeyer wrote: post #71
sergiosgc wrote: post #37

Earlier quoted context omitted.

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/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.
Post reply on HN