5 ms·

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.

by jamra 12y ago

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 never used operator overloading in C# or Java. Maybe that's just me, but it's certainly not a reason to avoid a language. The crux of his argument is that C++ users who switched to Java years ago are the types of programmers that Go wished to convert. 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. The examples you posted are exactly the kind of things that Go soars in. It's very convenient to leave them out while beating your chest about how your language is a superior language because it is superior in a very specific niche.

S4M 12y ago
> 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 write: Matrix c= a.add(b); Which makes your code verbose and makes Java (and Go) painful for doing numerical analysis.
- nordsieck 12y ago
  It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).
  - Someone 12y ago
    You should leave out the 'overloading': - Math (and it's very close relative logic) are the only domains that use operators, period. - other domains use overloading; homonyms are very common.
- philbarr 12y ago
  As it stands you can't in Java but you can in C#, although it's usually a really bad idea.
  - S4M 12y ago
    My comment only applies for Java - I don't know C#. As you say, it's usually a bad idea but it's quite reasonable to do for numerical analysis, as your sibling comment says.
- drdaeman 12y ago
  Which leads us to that ugly a.equals(b) instead of sane a == b. When not abused, operator overloading is a bless.
  - rmrfrmrf 12y ago
    Except that a == b and a.equals(b) are two different things.
- jamra 12y ago
  You are right. Can you tell which language I spent more time with?
_yosefk 12y ago
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 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...
- niemeyer 12y ago
  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. - Static typing, yes. - A simpler language specification (a big one for me, game changer for large code bases in large teams) - Interfaces based on structural typing ("static duck typing", as some say) - Much better control of memory layout (struct with 2 int64s takes 128 bits in memory, a list of those takes N*128bits) - Built-in micro-threads (goroutines) - A runtime that schedules (means, you can block, despite concurrency) - Buffered and unbuffered channels managed by the runtime (with select, etc) - Builds native static executables, fast (maybe you don't care, many people do) - A much better organized standard library - A very good http server _and_ client package in the standard library - Good crypto packages and APIs in the standard library - Error handling without exceptions (that's a pro for me and many, feel free to disagree) - A very elegant system to define access control (private/public) on vars/funcs/types/fields/consts/etc. - All names inside files that are part of a package ("directory") are part of the same namespace (allows better organizing code than with Python's file-is-a-module style) - Code files that can see declarations out of order (improves code organization) - gofmt! godoc! Love those. - None of the Python 2 => 3 migration mess (people are being told to program in a pseudo-language that is neither Python 2 nor 3 in recent times) And so on... That's not to judge your use of Python, though. By all means stick with Python if it suits your needs. As a last point, if you're interested in Qt bindings, I've been working on this: https://github.com/go-qml/qml https://github.com/go-qml/qml Some applications coming out of it: http://blog.labix.org/2014/04/25/qml-contest-results http://blog.labix.org/2014/04/25/qml-contest-results
rdtsc 12y ago
> 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?
- mseepgood 12y ago
  > how about REPL, does go have one? No. What? https://github.com/rocky/go-fish https://github.com/rocky/go-fish "Yet another Go REPL"
  - rdtsc 12y ago
    Made by a third party, it doesn't come with Go. Granted neither is numpy.
- jamra 12y ago
  Ok. You have a point, though I don't think my argument is a straw man. Numpy is one of those rare and great libraries. Go's error handling is the way it is for a reason. The authors chose to leave out exceptions. Stating that exceptions are better because you're more used to them or because they more easily hide errors is not a good critique. Even if you choose to squelch your errors in Go, you can always go back into your code and handle your errors appropriately. That makes it far easier to find bugs and makes your code very robust. I personally like how it compares to C in that regard. Go has some QML bindings that are pretty great, although I don't think that third party libraries are a good measure for a language. Especially seeing as how Go is quite young. I think that facets of the language itself are better choices of criticism. To help the OP, I think that python and other functional languages make dealing with abstract concepts more appealing. I walked the tight rope between writing Flask web sites and Go web sites. In the end, I know how to do either and I don't think one language needs to be better than another. In the case of my example, Sql Alchemy makes it much easier to make web apps. This does not detract from my issue with these kinds of articles in general. This seems to me more like a programmer trying to convince himself to not like a language due to his comfort zone.

by jamra 12y ago

S4M 12y ago

> 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 write: Matrix c= a.add(b); Which makes your code verbose and makes Java (and Go) painful for doing numerical analysis.

nordsieck 12y ago
It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).
- Someone 12y ago
  You should leave out the 'overloading': - Math (and it's very close relative logic) are the only domains that use operators, period. - other domains use overloading; homonyms are very common.
philbarr 12y ago
As it stands you can't in Java but you can in C#, although it's usually a really bad idea.
- S4M 12y ago
  My comment only applies for Java - I don't know C#. As you say, it's usually a bad idea but it's quite reasonable to do for numerical analysis, as your sibling comment says.
drdaeman 12y ago
Which leads us to that ugly a.equals(b) instead of sane a == b. When not abused, operator overloading is a bless.
- rmrfrmrf 12y ago
  Except that a == b and a.equals(b) are two different things.
jamra 12y ago
You are right. Can you tell which language I spent more time with?

_yosefk 12y ago

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

niemeyer 12y ago
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. - Static typing, yes. - A simpler language specification (a big one for me, game changer for large code bases in large teams) - Interfaces based on structural typing ("static duck typing", as some say) - Much better control of memory layout (struct with 2 int64s takes 128 bits in memory, a list of those takes N*128bits) - Built-in micro-threads (goroutines) - A runtime that schedules (means, you can block, despite concurrency) - Buffered and unbuffered channels managed by the runtime (with select, etc) - Builds native static executables, fast (maybe you don't care, many people do) - A much better organized standard library - A very good http server _and_ client package in the standard library - Good crypto packages and APIs in the standard library - Error handling without exceptions (that's a pro for me and many, feel free to disagree) - A very elegant system to define access control (private/public) on vars/funcs/types/fields/consts/etc. - All names inside files that are part of a package ("directory") are part of the same namespace (allows better organizing code than with Python's file-is-a-module style) - Code files that can see declarations out of order (improves code organization) - gofmt! godoc! Love those. - None of the Python 2 => 3 migration mess (people are being told to program in a pseudo-language that is neither Python 2 nor 3 in recent times) And so on... That's not to judge your use of Python, though. By all means stick with Python if it suits your needs. As a last point, if you're interested in Qt bindings, I've been working on this: https://github.com/go-qml/qml https://github.com/go-qml/qml Some applications coming out of it: http://blog.labix.org/2014/04/25/qml-contest-results http://blog.labix.org/2014/04/25/qml-contest-results

rdtsc 12y ago

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

mseepgood 12y ago
> how about REPL, does go have one? No. What? https://github.com/rocky/go-fish https://github.com/rocky/go-fish "Yet another Go REPL"
- rdtsc 12y ago
  Made by a third party, it doesn't come with Go. Granted neither is numpy.
jamra 12y ago
Ok. You have a point, though I don't think my argument is a straw man. Numpy is one of those rare and great libraries. Go's error handling is the way it is for a reason. The authors chose to leave out exceptions. Stating that exceptions are better because you're more used to them or because they more easily hide errors is not a good critique. Even if you choose to squelch your errors in Go, you can always go back into your code and handle your errors appropriately. That makes it far easier to find bugs and makes your code very robust. I personally like how it compares to C in that regard. Go has some QML bindings that are pretty great, although I don't think that third party libraries are a good measure for a language. Especially seeing as how Go is quite young. I think that facets of the language itself are better choices of criticism. To help the OP, I think that python and other functional languages make dealing with abstract concepts more appealing. I walked the tight rope between writing Flask web sites and Go web sites. In the end, I know how to do either and I don't think one language needs to be better than another. In the case of my example, Sql Alchemy makes it much easier to make web apps. This does not detract from my issue with these kinds of articles in general. This seems to me more like a programmer trying to convince himself to not like a language due to his comfort zone.