5 ms·

> Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness" Wh

> Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness" What are those languages? I may have a blindspot, but the languages that get enough buzz for me to notice are either not competing with Python in important dimensions (e.g. Rust) or have a narrower focus (e.g. Julia). Elixir maybe? JavaScript and its derivatives? But these lack the scientific programming ecosystem that's helped drive Python recently. I have no doubt that languages exist that might fit the bill of being both as easy as and more performant than Python -- there are a lot of languages out there. But I'm unaware of any whose mindshare has been sufficiently growing that it threatens Python in the mid-term. If I'm off base please let me know. I'd love to find a viable competitor to Python that's strictly better than it.

throwaway894345 6y ago
> I'd love to find a viable competitor to Python that's strictly better than it. I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is about 100-1000 times better for serial execution, and Go's goroutines allow you to take advantage of multiple cores much more easily than with Python. JavaScript and TypeScript are similarly easy-to-use, performant languages with a better-than-Python tooling story. I've also heard similar things about Elixir, Closure, and Kotlin.
- vosper 6y ago
  What's Go like for REPL-driven / exploratory development? That's mostly how I use Python.
  - bywaterstreet 6y ago
    Go has nothing on Python in this regard. I write Go every day, and come from a Python background. I often describe Go as the strongly-typed, more performant version of Python. I say this mostly because my Go code isn't too dissimilar from my Python code (structure, naming, packages). But I still drop into Python if I want to do something quickly. I don't really know why. Maybe it's the Go tooling, e.g. unused variables cause compilation errors, so things like this slow me down. Or maybe it's because Python just offers _so_ much out of the box, e.g. all the data structures you'll ever need (list, set, dict, tuples), and all small things you take for granted (like writing "is a in list", which would require a function in Go). The REPL is Python's killer feature.
    - pansa2 6y ago
      > I often describe Go as the strongly-typed, more performant version of Python. I've heard Go described this way several times, but I've found it to be a significantly lower-level language than Python. For example, it's much more verbose. In this recent blog post [0], the author converts some C++ code to Go - and it gets longer. 57 lines of C++ become 65 lines of Go. The same code in Python is about 20 lines. In particular, the author's Go code requires five lines to do the equivalent of Python's `with open(path) as f` and four lines for the equivalent of `word_array = list(word_counts.items())`: f, err := os.Open(path) if err != nil { return err } defer f.Close() // [...] wordArray := make([]WordCount, 0, len(wordCounts)) for word, count := range wordCounts { wordArray = append(wordArray, WordCount{word: word, count: count}) } [0] http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/
      - jgb1984 6y ago
        Exactly my opinion! I write python for a living since more than 13 years, and I find Go awfully verbose. It makes simple things feel like a chore. A three-to-one ratio of lines of code sounds about right. That's not a trade-off I can make, no matter how big the performance improvements.
        throwaway894345 6y ago
        > That's not a trade-off I can make, no matter how big the performance improvements. This is crazy. Many of those lines are closing brackets or whitespace. But moreover, optimizing for characters or LOC is absurd. Optimize for maintainability or readability, at which point Go is at least as good as Python (I would argue better). Optimize for tooling, especially package management and build tooling--Go is many times better than Python here. Optimize for performance--Go is literally hundreds or thousands of times better here. Optimize for breadth and quality of ecosystem. Optimize for deployment story (single small artifact vs hundreds of megabytes of dependencies). These are the things that matter, not lines of code.
- mrtranscendence 6y ago
  I'll be honest, as someone whose non-Python programming (paltry as it is) is mostly done in statically-typed functional languages, I have a bit of a bias against Go for the whole generics thing. I'll give it a closer look at some point.
  - omginternets 6y ago
    I gotta be honest, the lack of generics has never bothered me. The type-assertion escape hatch has always been largely sufficient for all but the most performance-critical projects (of which I have exactly 1, and it was a side project), and runtime panics due to failed assertions are quite easy to eliminate via wrapper types. My advice: just go for it. You almost certainly won't miss generics. (Edit: I've broken my own rule and given advice without first asking what kind of programming you do. My assertion holds for most run-of-the-mill stuff, e.g. writing REST interfaces, network servers, etc. If you're within 2-sigma of the industry, you won't miss generics.)
  - throwaway894345 6y ago
    I understand; lots of people have this sentiment. It’s an inconvenience in many cases, but we’re comparing it against Python, which has no type safety at all much less generics (apart from Mypy, which has many, many other issues).
    - pjmlp 6y ago
      All dynamic languages are generic by default.
      - throwaway894345 6y ago
        If that's how you define "generic", then Go is also generic by virtue of `interface{}`.
        pjmlp 6y ago
        No, because interface{} in an empty type that needs to be type cast to the actual type before use. Dynamic languages do that implicitly. Implement max in Go with interface{} without casts and reflection: def max(a, b): if a >= b: a else: b
- pansa2 6y ago
  > single-binary deployments More than performance (pure Python can be too slow, but NumPy is usually fast enough), this is what I miss when using Python. There's currently no good solution for bundling Python code and the interpreter into a single binary. PyInstaller works, but the resulting binaries write lots of files to `/tmp` every time they run, which is a hack that leads to long startup times. PyOxidizer avoids this, but includes the entire standard library in every binary, making them too large by an order of magnitude.
- solidasparagus 6y ago
  Go and Python have pretty minimal overlap IMO. If you are using Python for anything other than a server or CLI, Golang is not a very good replacement for Python. Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some people are going to disagree with that one), quick to prototype code. If you really need performance in Python, you can probably get it out of the box (if you can run deep learning with Python, performance isn't a limitation). I love Go and use it for a bunch of projects, but I've only once wanted to move a project from Python to Go and that was a performance-centric CLI that was only written in Python originally because of how quickly it let us prototype in comparison to Go.
  - xvilka 6y ago
    Julia covers your use cases and overwhelmingly fast.
    - solidasparagus 6y ago
      Possibly - I'm keeping my eye on it. But I can't stand the matlab-esque syntax.
    - semi-extrinsic 6y ago
      My gripe with Julia etc. as replacements, is that Python is duct tape. I don't need fast duct tape, I need duct tape that is understood and used by essentially everyone I work with, and that has native, fast handling of large amounts of data (NumPy, Pandas). Good user experience as duct tape. From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction. Whenever we need more speed, we just pull the slow bits down into compiled languages, and scale them out to many cores with solutions like MPI. R is another language that is mainly duct tape for stringing pieces of compiled code together. If it had a better UX for developers than Python, I think we would see it dominating much more today, without having any speed advantage.
      - 6y ago
newen 6y ago
I think Julia is strictly better than Python, both for data oriented applications and for web development.
- mrtranscendence 6y ago
  Julia might be. It's certainly higher performance from what I understand, and it offers some syntactic flexibility that I miss from R when using Python (Python could never have a fully complete dplyr). It seems from afar to be rather more complex than those languages, though.
  - disgruntledphd2 6y ago
    I actually think that from a programming perspective, Julia is much closer to R than Python, because of the focus on generic functions rather than objects as a means of abstractions. It's still a little too wild-west for my tastes right now, but I want it to improve as I think it's got real potential.

throwaway894345 6y ago

> I'd love to find a viable competitor to Python that's strictly better than it. I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is about 100-1000 times better for serial execution, and Go's goroutines allow you to take advantage of multiple cores much more easily than with Python. JavaScript and TypeScript are similarly easy-to-use, performant languages with a better-than-Python tooling story. I've also heard similar things about Elixir, Closure, and Kotlin.

vosper 6y ago
What's Go like for REPL-driven / exploratory development? That's mostly how I use Python.
- bywaterstreet 6y ago
  Go has nothing on Python in this regard. I write Go every day, and come from a Python background. I often describe Go as the strongly-typed, more performant version of Python. I say this mostly because my Go code isn't too dissimilar from my Python code (structure, naming, packages). But I still drop into Python if I want to do something quickly. I don't really know why. Maybe it's the Go tooling, e.g. unused variables cause compilation errors, so things like this slow me down. Or maybe it's because Python just offers _so_ much out of the box, e.g. all the data structures you'll ever need (list, set, dict, tuples), and all small things you take for granted (like writing "is a in list", which would require a function in Go). The REPL is Python's killer feature.
  - pansa2 6y ago
    > I often describe Go as the strongly-typed, more performant version of Python. I've heard Go described this way several times, but I've found it to be a significantly lower-level language than Python. For example, it's much more verbose. In this recent blog post [0], the author converts some C++ code to Go - and it gets longer. 57 lines of C++ become 65 lines of Go. The same code in Python is about 20 lines. In particular, the author's Go code requires five lines to do the equivalent of Python's `with open(path) as f` and four lines for the equivalent of `word_array = list(word_counts.items())`: f, err := os.Open(path) if err != nil { return err } defer f.Close() // [...] wordArray := make([]WordCount, 0, len(wordCounts)) for word, count := range wordCounts { wordArray = append(wordArray, WordCount{word: word, count: count}) } [0] http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/
    - jgb1984 6y ago
      Exactly my opinion! I write python for a living since more than 13 years, and I find Go awfully verbose. It makes simple things feel like a chore. A three-to-one ratio of lines of code sounds about right. That's not a trade-off I can make, no matter how big the performance improvements.
      - throwaway894345 6y ago
        > That's not a trade-off I can make, no matter how big the performance improvements. This is crazy. Many of those lines are closing brackets or whitespace. But moreover, optimizing for characters or LOC is absurd. Optimize for maintainability or readability, at which point Go is at least as good as Python (I would argue better). Optimize for tooling, especially package management and build tooling--Go is many times better than Python here. Optimize for performance--Go is literally hundreds or thousands of times better here. Optimize for breadth and quality of ecosystem. Optimize for deployment story (single small artifact vs hundreds of megabytes of dependencies). These are the things that matter, not lines of code.
mrtranscendence 6y ago
I'll be honest, as someone whose non-Python programming (paltry as it is) is mostly done in statically-typed functional languages, I have a bit of a bias against Go for the whole generics thing. I'll give it a closer look at some point.
- omginternets 6y ago
  I gotta be honest, the lack of generics has never bothered me. The type-assertion escape hatch has always been largely sufficient for all but the most performance-critical projects (of which I have exactly 1, and it was a side project), and runtime panics due to failed assertions are quite easy to eliminate via wrapper types. My advice: just go for it. You almost certainly won't miss generics. (Edit: I've broken my own rule and given advice without first asking what kind of programming you do. My assertion holds for most run-of-the-mill stuff, e.g. writing REST interfaces, network servers, etc. If you're within 2-sigma of the industry, you won't miss generics.)
- throwaway894345 6y ago
  I understand; lots of people have this sentiment. It’s an inconvenience in many cases, but we’re comparing it against Python, which has no type safety at all much less generics (apart from Mypy, which has many, many other issues).
  - pjmlp 6y ago
    All dynamic languages are generic by default.
    - throwaway894345 6y ago
      If that's how you define "generic", then Go is also generic by virtue of `interface{}`.
      - pjmlp 6y ago
        No, because interface{} in an empty type that needs to be type cast to the actual type before use. Dynamic languages do that implicitly. Implement max in Go with interface{} without casts and reflection: def max(a, b): if a >= b: a else: b
pansa2 6y ago
> single-binary deployments More than performance (pure Python can be too slow, but NumPy is usually fast enough), this is what I miss when using Python. There's currently no good solution for bundling Python code and the interpreter into a single binary. PyInstaller works, but the resulting binaries write lots of files to `/tmp` every time they run, which is a hack that leads to long startup times. PyOxidizer avoids this, but includes the entire standard library in every binary, making them too large by an order of magnitude.
solidasparagus 6y ago
Go and Python have pretty minimal overlap IMO. If you are using Python for anything other than a server or CLI, Golang is not a very good replacement for Python. Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some people are going to disagree with that one), quick to prototype code. If you really need performance in Python, you can probably get it out of the box (if you can run deep learning with Python, performance isn't a limitation). I love Go and use it for a bunch of projects, but I've only once wanted to move a project from Python to Go and that was a performance-centric CLI that was only written in Python originally because of how quickly it let us prototype in comparison to Go.
- xvilka 6y ago
  Julia covers your use cases and overwhelmingly fast.
  - solidasparagus 6y ago
    Possibly - I'm keeping my eye on it. But I can't stand the matlab-esque syntax.
  - semi-extrinsic 6y ago
    My gripe with Julia etc. as replacements, is that Python is duct tape. I don't need fast duct tape, I need duct tape that is understood and used by essentially everyone I work with, and that has native, fast handling of large amounts of data (NumPy, Pandas). Good user experience as duct tape. From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction. Whenever we need more speed, we just pull the slow bits down into compiled languages, and scale them out to many cores with solutions like MPI. R is another language that is mainly duct tape for stringing pieces of compiled code together. If it had a better UX for developers than Python, I think we would see it dominating much more today, without having any speed advantage.
    - 6y ago

newen 6y ago

I think Julia is strictly better than Python, both for data oriented applications and for web development.

mrtranscendence 6y ago
Julia might be. It's certainly higher performance from what I understand, and it offers some syntactic flexibility that I miss from R when using Python (Python could never have a fully complete dplyr). It seems from afar to be rather more complex than those languages, though.
- disgruntledphd2 6y ago
  I actually think that from a programming perspective, Julia is much closer to R than Python, because of the focus on generic functions rather than objects as a means of abstractions. It's still a little too wild-west for my tastes right now, but I want it to improve as I think it's got real potential.