3 ms·

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

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 and _like_ it. Are these Python coders who've never heard of itertools??

drdaeman 12y ago
There are some Python programmers who sometimes regret Python doesn't have some static typing. Go has that and also provides an easy way to be quite dynamic when that's wished for (or even when not - without generics one'll have to resort to `interface{}` even if that's not desired, huh).
sergiosgc 12y ago
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 model, but could force myself to live with it for the sake of trying composition over inheritance. Error returning, however, is taking the ideology too far.
- niemeyer 12y ago
  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 http://blog.labix.org/2013/04/23/exceptional-crashes
  - sergiosgc 12y ago
    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.
    - niemeyer 12y ago
      It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the success case. In my experience with the medium sized projects I've been closely responsible for (in the hundreds of thousands of lines ballpark), we were interested in doing a really good job in both the exception and the error result cases, because the misbehavior scenario is a real issue, and followed all the good practices in the modern developer's backpack. In the end, exception-rich code just turned out obviously hard to get right, no matter how much we _wanted_ to get it right, because the program is allowed to jump out of arbitrary stack frames that the developer was conveniently taught to not handle errors on, because.. hey! the "default behavior"! After getting involved in these experiments, I started paying more attention to how people can possibly be happy with exception-rich logic that behaves like that. My empiric observation is that the lack of proper error handling turns out to have a relatively low impact for lots of projects. Crashed or misbehaved? Whatever.. file a bug.
  - sergiosgc 12y ago
    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.
    - niemeyer 12y ago
pekk 12y ago
Less than 100% of the reported switches from Python to Go actually started with serious knowledge of Python.
niemeyer 12y ago
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.

drdaeman 12y ago

There are some Python programmers who sometimes regret Python doesn't have some static typing. Go has that and also provides an easy way to be quite dynamic when that's wished for (or even when not - without generics one'll have to resort to `interface{}` even if that's not desired, huh).

sergiosgc 12y ago

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 model, but could force myself to live with it for the sake of trying composition over inheritance. Error returning, however, is taking the ideology too far.

niemeyer 12y ago
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 http://blog.labix.org/2013/04/23/exceptional-crashes
- sergiosgc 12y ago
  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.
  - niemeyer 12y ago
    It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the success case. In my experience with the medium sized projects I've been closely responsible for (in the hundreds of thousands of lines ballpark), we were interested in doing a really good job in both the exception and the error result cases, because the misbehavior scenario is a real issue, and followed all the good practices in the modern developer's backpack. In the end, exception-rich code just turned out obviously hard to get right, no matter how much we _wanted_ to get it right, because the program is allowed to jump out of arbitrary stack frames that the developer was conveniently taught to not handle errors on, because.. hey! the "default behavior"! After getting involved in these experiments, I started paying more attention to how people can possibly be happy with exception-rich logic that behaves like that. My empiric observation is that the lack of proper error handling turns out to have a relatively low impact for lots of projects. Crashed or misbehaved? Whatever.. file a bug.
- sergiosgc 12y ago
  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.
  - niemeyer 12y ago

pekk 12y ago

Less than 100% of the reported switches from Python to Go actually started with serious knowledge of Python.

niemeyer 12y ago

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.