Things from Python I'd miss in Go

Also, if you are interested in a job...

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 levelDB like influx) all in Go and the result was it is many times faster than an order of magnitude larger hadoop cluster, BigQuery, etc for the limited operations it supports.

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;

    Matrix c= a.add(b);

* 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 about Go for the sake of it": I didn't mention generics or similar, for instance - because they don't matter in the cases where I use Python, at least I don't recall that they do. I'm not looking for things to complain about.

* Deployment, etc. - it probably won't make someone switch to Go though it might be nice if you start in Go, and also - it's an argument in itself. I like how in Python you can change a file and all code using it "sees" the change, or how in languages with dynamic libraries/runtimes/whatever you change the library and all code "sees" it. Basically there are deployment trade-offs and in my environment - a controlled LAN - Go is simply worse. On a DreamHost box with ancient everything it'd be a godsend.

Overall - I don't think "Python is better than Go", but the ones who "beat their chest about how your language is a superior language because it is superior in a very specific niche" are people arguing about Go the way you do :-) That niche in Go's case being servers.

Speaking of servers... I know the difference between servers and web servers, I just said/implied that if Go is great for web apps, then it might take off as a really big thing, if it's just for high-performance infrastructure it's a language for Google, CloudFlare and a small number of others...

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?

http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/

"We’ll start at the end: Quasar and Pulsar are two new open-source libraries in Java and Clojure respectively that add Erlang-like actor-model (and Go-like coroutine/channel) programs to the JVM."

In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one.

Sorry, I should have been clearer on that.

[1] If you're not convinced, I can give you a lot more examples.

I agree with you. But as with most prices, sometimes they are worth it. There are a lot of practical cases where you really want the performance (even outside scientific computing, which in itself is a pretty widely applied field).

> I'm sure there are some fields of academia where this is a reasonable tradeoff

I'm not sure where you got "academia" from; scientific computing is in no way restricted to research. Weather predictions, genome processing, and oil reserves exploration are just three of many examples for the commercial application of scientific computing.

> (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...)

DSP applications are ubiquitous today; you'll find them, e.g., in your phone, or in your car.

> but your generic number crunching job rarely calls for it.

You're very wrong. Number crunching is the example for which you want lots of performance.

> As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me.

I didn't say they are. I said that no other language offers them to the degree that C++ does.

> so maybe it's just a name for C++'s tradeoffs?

No. It means abstractions which do not cause runtime overheads because the compiler can optimize them away.

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?

There is a big difference between optimization in the small and optimization in the large. It is precisely because you need maximum performance and correctness that you need high-level languages. Quite ironically your comment itself illustrates the point well. One could have written high-perf apps entirely in the style of OpenBlas. Sensible people dont and for a reason.

I am going to copy a previous comment of mine on this topic.

--

I will not be surprised if it beats C by generating C code itself, but C code that no human would write by hand. It has been done before in programming history (not just C, fortran has been beaten as well http://dl.acm.org/citation.cfm?id=200989 http://link.springer.com/chapter/10.1007/978-3-642-19014-8_1.... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.150.... although the prior art focuses on Lisp I think Haskell and ML like languages are better equipped for this). Imperative code is a lot harder to reason about, and low level code is a lot harder to write if one cares about correctness and performance simultaneously. Specialized functional languages has a history of beating C implementations. It could be faster still if one removes the constraint that one has to generate C code, for example coroutines and proper tail calls become easier to implement. The bottomline is that correctness is easier to achieve with functional, and performance with imperative. So we would need both and they meet in a compiler.

Take the example of Stalin and StalinGrad, they are Lisps. Their compile times are epic, but once done they have a history of generating faster code than C for specific applications (a specific example where it will excel is multidimensional numeric integration where the function to be integrated is passed as an input). The main reason why they would be able to generate faster code is that they are smarter about inlining. The reason they are smarter about inlining is that programmers intent is better preserved when encoded in a higher level language.

Can a programmer not write the same correct code in C by hand ? Perhaps they can, but it will take longer and would be more error prone and likely to be costlier to produce, unless one takes the help of these higher level abstractions primitives, but then you aren't really writing in C anymore. Can the C compiler not be equally smart ? possibly, but it will be a lot harder to make a C compiler smart than a functional language compiler smart. Functional languages leave a lot of room for the compiler to do its thing, C while not as bad as Java still over-specifies how exactly something needs to be computed (my way or the highway). Add the fact that when code is written in a higher level, but optimization friendly language one can enjoy the benefits of compiler techniques yet to come. It future-proofs the code to an extent and amortizes the effort that went into writing the compiler.

Thanks for the article with your first impressions of Go anyway - I read another post on your blog while visiting (about leaving C++ for a simpler OO C), and it actually echoes a lot of the motivations of Rob Pike and others at Google in creating Go - frustration at C++ compile times and baroque grammar was a primary factor in the creation of Go, so it feels to me like they went back to C as a basis and built something new...

> 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 :-)

    if err != nil {
        return (whatever null type), err
    }

For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.

    if config, err := readConfig(ioReader); err != nil {
      switch err.(type) {
      case io.ErrClosedPipe:
        // do one thing
      case ParseError:
        // do something else
      case ...
      }
    }

They are very serious.

> At least, to my limited knowledge of Go, there are no guidelines on using them properly, so everyone panics with whatever they fancy, and this lack of conventions is a bit problematic, like `raise "Failed to open file"` in Python.

The convention is that you don't let panics escape across the public API of your function -- which also makes most other cross-project conventions for panics unnecessary. Its probably useful to have internal conventions within a project for internal consistency, but since none of your panics should ever escape across a public API boundary, a broader convention would have limited benefit.

Sometimes a bit of dynamic scoping can go a long way.

In the context of server code, that's really the fatal problem. And in general, "scream and die" isn't necessarily the optimal case either; not everything is a consumer web app where showing an error page is perfectly fine (I mean, not good, but generally fine). Knowing what can throw an error where is really useful.

I don't consider the error question settled yet. I think the failure of checked exceptions is instructive, because they clearly demonstrated that there's this "unioning" effect where a bit of code's error throwing capabilities is the union of all code it may call (in the absence of a programmer carefully restricting it), and seemingly minor bits of code may in fact result in "union"ing in a whole whackload of other errors. I'm not convinced anything has fully managed to address this yet. Unchecked exceptions tend to just cover over the problem, but don't help you deal with it much. A closed sum type for errors is great when you can use it, but it composes poorly if you start trying to move that around the system, and in practice Haskell still has exceptions. Using arbitrary or nearly-arbitrary terms for errors like Go (error is an interface) and Erlang do means you can pass errors back up the stack easily without the type system complaining and it's not a "hidden goto", but it means there's no way to be really sure that you've actually handled all possible errors in the best way. There's still no way to point at a block of code and assert that you know all the errors it can generate.

I think part of my willingness to accept how Go does errors is that I lack the belief that it's a solved problem and "duh, just use $SOLUTION". There's only some solutions that do a good enough job of sweeping the issue under the rug that they've convinced you it's solved, but the issues are still waiting to pop out as soon as someone stomps their boot down in the right place. It still seems like there's more work to be done here.

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

    def f(a, b=1, c=2):
        pass

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.

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() 
  }()

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 Python, or "what I wouldn't miss from Python..."