Things from Python I'd miss in Go • Hacker News Board

Re: Things from Python I'd miss in Go

#101

Post by adwn » Tue, Jun 10, 2014, 4:32 PM UTC

rdtsc wrote: post #89

adwn wrote: post #20

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…

C++ has been pushed into performance niches. Those are big niches though. Games, real-time programming, high performance networking. But it is not used _as_ much as in the past for core business logic. There are legacy system that will run for many years. A lot of web backends are not not in C++ when in the past they were. It was the language to rule them all, but now in some areas others have taken over.

I agree 100% with what you said. I would never advocate C++ for business logic. In fact, I wouldn't use it for anything which doesn't really need the most performance available (and even there I would try to restrict its usage to the actual performance bottleneck).

Re: Things from Python I'd miss in Go

#102

Post by dragonwriter » Tue, Jun 10, 2014, 4:35 PM UTC

rdtsc wrote: post #86

dragonwriter wrote: post #41

> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code…

> This is flat out false. So Go has panics and they are _just like exceptions_ in Python? Because to accuse the writer of being "flat out false" these have to be exactly the same and he as to be ignorant to not see the obvious. Let's say you have some step in your function and you might raise an exception. In Python you'd surround it with try...catch try: dosomething() catch SomeException: handle_exception() Can you…

> So Go has panics and they are _just like exceptions_ in Python? Because to accuse the writer of being "flat out false" these have to be exactly the same

No, they don't. Because the claim that I called flat out false was this

>> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way.

So, no, Go's exception mechanism doesn't have to be "just like Pythons" for this to be flat-out false. What it does need to be is anything that allows propagating errors up a call chain without an if at every function call along the way. Which panic/defer/recover is.

> And don't crate a new function that that is not what Python does.

Even if I did accept your "must work like Python" standard (which is, itself, wrong because its not necessary for the statement at issue to be flat-out false), what's the substantive difference between an immediately-called anonymous function and a block?

Sure, you could legitimately complain that the example would be more verbose in Go, but that's not the complaint OP made. (The most direct translation of your example would look something like this in Go -- though in practice you wouldn't really do this this way):

  func() { 
    defer func() { 
      r = recover()
      if e, ok := r.(SomeException); ok {
        handle_exception()
      } else {
        panic(e)
      }
    }
    dosomething() 
  }()

Re: Things from Python I'd miss in Go

#103

Post by rakoo » Tue, Jun 10, 2014, 4:40 PM UTC

_yosefk wrote: post #68

rakoo wrote: post #42

I think the author misses the point. The number one reason Go was created was to build maintainable softwares , the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. T…

Why do I miss the point if, like me , you think Go is the new Java? :-) I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)

I was referring to these:

> What does Go have that C++ lacks? Mandatory garbage collection, memory safety, reflection, faster build times, modest runtime overhead.

> If on the other hand most code in most websites matters a lot for performance, then maybe you want Go

Specifically, seeing only the features (performance) and not the intent in Go. I should have said "misses the point in why Go can be more interesting than other languages".

Now, as you said, if your requirements can't be fullfilled by Go (or any blub), then it's not worth switching.

> If it did Java might have been the new Java :-)

I don't think people avoid Java because of the lack of light concurrency (there are multiple production-ready libraries to do that). I think people avoid it because of Java-the-platform... so Java would have stayed the bloated Java :-)

Re: Things from Python I'd miss in Go

#104

Post by kyllo » Tue, Jun 10, 2014, 4:43 PM UTC

rogerdpack wrote: post #84

kyllo wrote: post #55

Earlier quoted context omitted.

Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) python -m compileall . :)

I was referring to typo'ing for instance assignment (perhaps you were as well?) a = 3 if true: a2 = 4 # lame I know--but beginners like me do it --Python lets discover your failure at runtime...[as a good dynamic typed language does--Go doesn't FWIW]. It was just from an experience I had with learning Python recently. Now it makes me wonder what his blog post would look like saying things he'd miss going from Go to P…

Well, your example is just not an error in Python. It might be a bug, it not be what you meant to do, but it is not an error in a dynamically typed language like Python. It is valid, legal code.

My point was just that although Python is dynamically typed, it is still a compiled-to-bytecode language (much as Java is) and you don't have to discover your errors at runtime, that is optional. You have the ability to perform just the compile step without executing the bytecode. The 'compileall' command does that.

There are also great tools like pylint for static source code checking. And of course unit testing is always key.

But of course, if you are looking to catch typing and variable declaration bugs at compile time, you need to be using a statically typed language.

Re: Things from Python I'd miss in Go

#105

Post by adwn » Tue, Jun 10, 2014, 4:43 PM UTC

onalark wrote: post #70

adwn wrote: post #20

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…

If you want/need maximum performance, why are you programming in a "high-level language"? Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. The vast majority of scientific programmers don't need to write at this level. I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply av…

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

I don't think this is true, at least not for non-inline assembly. Sure, OpenBlAS contains a lot of assembly, but many scientific computing algorithms are more complex than the BLAS routines.

> I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to [...]

Where in my post did I give you the idea that I don't like code reuse and instead reinvent the wheel every time?

Re: Things from Python I'd miss in Go

#106

Post by mseepgood » Tue, Jun 10, 2014, 4:55 PM UTC

rdtsc wrote: post #77

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…

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

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

What? https://github.com/rocky/go-fish "Yet another Go REPL"

Re: Things from Python I'd miss in Go

#107

Post by howeman » Tue, Jun 10, 2014, 4:55 PM UTC

baldfat wrote: post #15

There is no one best language. Numpy is not something Go is going to do (Correct em if I am wrong). Julia would be the faster language to switch to, but personally I switched from Python to R due to the fact that I like languages that are made for what I am doing. Python always feels second best to whatever I am doing and I have branched away from Python. So R for statistics is great for me.

Besides operator overloading, why can't Go do Numpy?

Re: Things from Python I'd miss in Go

#108

Post by howeman » Tue, Jun 10, 2014, 4:58 PM UTC

As of at least a year ago, their are bindings for the BLAS library of your choice (github.com/gonum/blas), which are used in many parts of the matrix package (github.com/gonum/matrix/mat64). As of a week ago, there are bindings for the Lapack implementation of your choice (github.com/gonum/lapack). These have not yet been worked in with matrix, but will be eventually (PR welcome!).

Re: Things from Python I'd miss in Go

#109

Post by howeman » Tue, Jun 10, 2014, 5:01 PM UTC

howeman wrote: post #108

As of at least a year ago, their are bindings for the BLAS library of your choice (github.com/gonum/blas), which are used in many parts of the matrix package (github.com/gonum/matrix/mat64). As of a week ago, there are bindings for the Lapack implementation of your choice (github.com/gonum/lapack). These have not yet been worked in with matrix, but will be eventually (PR welcome!).

Not to mention there's 2/3rds of a go BLAS implementation (benchmarks https://groups.google.com/forum/#!msg/gonum-dev/Cqa41tbUUCw/...). Level 3 routines are much harder to make efficient (people are still researching efficient matrix multiply)

Re: Things from Python I'd miss in Go

#110

Post by onalark » Tue, Jun 10, 2014, 5:20 PM UTC

adwn wrote: post #105

onalark wrote: post #70

Earlier quoted context omitted.

If you want/need maximum performance, why are you programming in a "high-level language"? Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. The vast majority of scientific programmers don't need to write at this level. I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply av…

> 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 Python in exposing high-level scientific computing operations.

For performance, C++ does have some really nice high-performance libraries (Eigen comes to mind), but for the majority of use cases, you either need to write inline assembly to get the best possible speed, or you're already reusing a fast numerical kernel from another library, and you may be better off in a higher-level language.

This is a very subjective discussion, and there are many interesting, fast, C++ libraries that do important work for science. But your claim that C++ is the best language for such work would be highly contested by many high performance computing specialists. As it is, I believe there's a pretty rough split between C, C++, and Fortran supporters, with Python continuing to gain traction.

Here's another counter-argument. MPI is used in 99% of all scientific high performance computing codes. The latest version of MPI, MPI-3, drops explicit support for C++ bindings. If C++ was so dominant, why would explicit bindings be dropped?