6 ms·

Yup at this point there is no reason to not use Python 3 for new projects. What I'm finding actually is that some companies that have their codebase in Python

Yup at this point there is no reason to not use Python 3 for new projects. What I'm finding actually is that some companies that have their codebase in Python 2 have actually started migrating to Golang rather than Python 3, because of the increased performance benefits. I'm kind of sad about this, but I think that Golang will eventually replace Python as the go-to back-end server language (maybe even data processing).

make3 9y ago
but at the same time, Python is the fastest growing language https://stackoverflow.blog/2017/09/06/incredible-growth-python/ https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... because of data science and AI, and I don't see Go replacing Python anytime soon in these domains.
- anameaname 9y ago
  Agreed. I think the reason is because the programming mindset for data science is different than for normal software engineering. In data science, you write a program, find the answer, write your paper, and throw the program away. Python fits this usage pattern very well.
- jernfrost 9y ago
  However Python is getting attacked by new language in all areas where it is being used. Go attacks just one area. Julia is a much better language for data science than Python. It was essentially designed for it, while for Python it was an afterthought. Python has a head start today with a large selection of packages and mindshare, but as we've seen with Go, I think that will start eroding in the future. Python simply can't keep up with the development pace and possibilities offered with Julia. For Data Science and AI packages in Python to have acceptable performance they need to be written in C/C++, this means slow development. Julia has high enough performance that all these packages can be developed in Julia itself. And this is what people in this area is observing. That package development is moving much faster in the Julia community than in Python. You can also combine these packages in ways that are simply impossible to do in Python. The need to interface with C/C++ creates a lot of artificial restrictions. E.g. processing lots of data fast requires big NumPy buffers with plain data types. In Julia you can e.g. create a an image buffer made up of color objects and process it fast. Unlike Go, Julia offers the ability of a gradual transition to Julia from Python, since Python packages can be used in Julia.
  - make3 9y ago
    To me, Julia feels clunky as all hell. The other thing is that Julia doesn't help for deep learning, where something like 99.99% of the computation time is actually CUDA kernels. I don't know; I actually really like the optional typing of Julia in theory, I don't know why I find the language so unpleasant.
bostik 9y ago
As much as a I like Go in general, there are two pythonic things that, IMO, really should go into the next major revision. 1: sets; in this day and age, not having sets as native, stdlib-provided data types is simply unacceptable.[ß] 2: The ease of python's "in" keyword; being able to test for a key in a map (or set!) without any indirection is crucial ß: granted, IIRC python moved sets into native stdlib types only somewhere in 2.x but better late than never
- hellcow 9y ago
  Sets, if you mean a collection that contains no more than 1 of something, are easy. Use a map with struct{}{} values. If ordering is important, it's ~30 lines of simple code to encase a slice and a map in a struct and define your desired interface. Testing for a key's existence is easy as well. Accessing a map returns two variables--the 1st is the value itself. The 2nd variable is that "exists" variable you're asking for. It's true when the key is present in the map and false if not. Often you'll see the 2nd variable omitted, but if you need to test for existence it's there for you to use.
  - chomp 9y ago
    Yes you can hack sets into most any modern language, but mostly involves writing annoying looking boilerplate, or pulling in external libraries. I think parent is looking for a native set type (which I agree with). I don't know if it has a place in golang, but I always sigh and roll my eyes when I have to implement a set in most languages.
  - keenerd 9y ago
    Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
    - frou_dh 9y ago
      This repository was named to emphasise the comedy of its existence :) https://github.com/frou/poor-mans-generics/ https://github.com/frou/poor-mans-generics/
striking 9y ago
For network glue, Go is a wonderful and super useful language. Not just in how efficient it is, or how easy FFI calls are, but also in how easy it is to deploy. I don't see Go replacing anything that isn't a lightweight server or really small data processing script, though. Anything Tensorflow or numpy of any notable complexity will probably remain Python afaict.
- merb 9y ago
  well I wouldn't call kubernetes less complex. and it's still written in go. I think stuff like that is where go shines.
  - pjmlp 9y ago
    The key question is how many lines of code would Kubernetes have if Go was an expressive language, but I don't have big hopes for a hypothetical Go 2.0.
makecheck 9y ago
It is still not installed by default on Macs and that is a sufficient reason not to use it for me. It is far better to be able to tell users they can simply download and run your app without external dependencies. It is also important that downloads be small (i.e. I’m not embedding an entire Python 3 interpreter into my download if the preinstalled Python 2 works as well as it needs to).
bandrami 9y ago
> at this point there is no reason to not use Python 3 for new projects Sure there is: Python 2 isn't going to change on me again. Python 3 might.
- bandrami 9y ago
  Why on earth do people downvote that? I want a language that isn't going to change. Every single other language community seems to understand that, but something about it pisses off Python people.
  - rspeer 9y ago
    You're claiming to know the future of Python better than "Python people" know the future of Python. Python has changed incompatibly once in 26 years, and never plans to do it again, yet you're making it sound like an ongoing pattern. What language are you going to run to that has that kind of track record?
    - yjftsjthsd-h 9y ago
      POSIX sh?
      - rspeer 9y ago
        Have fun with that?
        frou_dh 9y ago
        Real 'fun' to program in - with strict POSIX shell, functions cannot even have local variables.
    - bandrami 9y ago
      30 years later, scheme is still scheme. A different report has come out, and some compilers choose to implement it. But the language hasn't changed. See my point?
jchw 9y ago
I'm currently using Go (and Python - we did go from Python 2 to Go, but later continued using Python 3) at work, but for all of the hoopla about it's concurrency, the reality is I'd rather have Rust's superior runtime safety and metaprogramming. A few things have impeded on Rust adoption at work: - Learning curve. Rust is not as bad for learning as C++, but any language with strong metaprogramming and unfamiliar or relatively new language concepts are bound to be stumbling blocks. - Ecosystem. The Go ecosystem by and large is awesome. Rust's is getting up there, though. It'd be really cool if Mozillas work with Servo meant there would be pure Rust HTML rendering and JavaScript interpreter code though! So far, impressed with minimal but powerful libraries like Iron. - Maturity. Rust itself is pretty good, even nightly feels stable, but the developer tools are still shaping up. Until recently, rustup crashed on my Win10. Things are a lot better today, especially with the Rust Language Server. - Marketing. Rust has a ways to go on its marketing. This has improved recently as well and I'm glad. Some underestimate the importance of having good PR for a programming language - people need to be really confident to adopt a programming language for critical components, and Go is in a place where many would trust it just because of its reputation. Also good for convincing your coworkers to give it a shot. That being said, while Go makes concurrency easy and generally acts as a great simplistic language to develop services in, I really feel as though Rust's potential is enormous. The 'simplicity debt' of Go can be taxing sometimes. I still love Go, though. I am just struggling to figure out which tool to use for which jobs. Though there's large areas of overlap, there are definitely things that feel nicer in either than the other.
- jernfrost 9y ago
  I kind of like the idea of Rust, but I don't really have much belief in complex programming languages. C++ only has a large following because it piggy backed on C, which people already knew, then it gradually grew its complexity. It is quite a different challenge to get people to use an entirely new language with high complexity. Companies are going to be negative towards adopting a language with a steep learning curve for its employees. That represents too much risk and money. I think Swift is a much better alternative to those who want something like Rust. Much easier to learn and you still got native code and strict typing without a need for a garbage collector. People also know they can trust it in the sense that they know Apple supports it and all Apple development is switching to it. That takes a way a big risk factor for companies.

make3 9y ago

but at the same time, Python is the fastest growing language https://stackoverflow.blog/2017/09/06/incredible-growth-python/ https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... because of data science and AI, and I don't see Go replacing Python anytime soon in these domains.

anameaname 9y ago
Agreed. I think the reason is because the programming mindset for data science is different than for normal software engineering. In data science, you write a program, find the answer, write your paper, and throw the program away. Python fits this usage pattern very well.
jernfrost 9y ago
However Python is getting attacked by new language in all areas where it is being used. Go attacks just one area. Julia is a much better language for data science than Python. It was essentially designed for it, while for Python it was an afterthought. Python has a head start today with a large selection of packages and mindshare, but as we've seen with Go, I think that will start eroding in the future. Python simply can't keep up with the development pace and possibilities offered with Julia. For Data Science and AI packages in Python to have acceptable performance they need to be written in C/C++, this means slow development. Julia has high enough performance that all these packages can be developed in Julia itself. And this is what people in this area is observing. That package development is moving much faster in the Julia community than in Python. You can also combine these packages in ways that are simply impossible to do in Python. The need to interface with C/C++ creates a lot of artificial restrictions. E.g. processing lots of data fast requires big NumPy buffers with plain data types. In Julia you can e.g. create a an image buffer made up of color objects and process it fast. Unlike Go, Julia offers the ability of a gradual transition to Julia from Python, since Python packages can be used in Julia.
- make3 9y ago
  To me, Julia feels clunky as all hell. The other thing is that Julia doesn't help for deep learning, where something like 99.99% of the computation time is actually CUDA kernels. I don't know; I actually really like the optional typing of Julia in theory, I don't know why I find the language so unpleasant.

bostik 9y ago

As much as a I like Go in general, there are two pythonic things that, IMO, really should go into the next major revision. 1: sets; in this day and age, not having sets as native, stdlib-provided data types is simply unacceptable.[ß] 2: The ease of python's "in" keyword; being able to test for a key in a map (or set!) without any indirection is crucial ß: granted, IIRC python moved sets into native stdlib types only somewhere in 2.x but better late than never

hellcow 9y ago
Sets, if you mean a collection that contains no more than 1 of something, are easy. Use a map with struct{}{} values. If ordering is important, it's ~30 lines of simple code to encase a slice and a map in a struct and define your desired interface. Testing for a key's existence is easy as well. Accessing a map returns two variables--the 1st is the value itself. The 2nd variable is that "exists" variable you're asking for. It's true when the key is present in the map and false if not. Often you'll see the 2nd variable omitted, but if you need to test for existence it's there for you to use.
- chomp 9y ago
  Yes you can hack sets into most any modern language, but mostly involves writing annoying looking boilerplate, or pulling in external libraries. I think parent is looking for a native set type (which I agree with). I don't know if it has a place in golang, but I always sigh and roll my eyes when I have to implement a set in most languages.
- keenerd 9y ago
  Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
  - frou_dh 9y ago
    This repository was named to emphasise the comedy of its existence :) https://github.com/frou/poor-mans-generics/ https://github.com/frou/poor-mans-generics/

striking 9y ago

For network glue, Go is a wonderful and super useful language. Not just in how efficient it is, or how easy FFI calls are, but also in how easy it is to deploy. I don't see Go replacing anything that isn't a lightweight server or really small data processing script, though. Anything Tensorflow or numpy of any notable complexity will probably remain Python afaict.

merb 9y ago
well I wouldn't call kubernetes less complex. and it's still written in go. I think stuff like that is where go shines.
- pjmlp 9y ago
  The key question is how many lines of code would Kubernetes have if Go was an expressive language, but I don't have big hopes for a hypothetical Go 2.0.

makecheck 9y ago

It is still not installed by default on Macs and that is a sufficient reason not to use it for me. It is far better to be able to tell users they can simply download and run your app without external dependencies. It is also important that downloads be small (i.e. I’m not embedding an entire Python 3 interpreter into my download if the preinstalled Python 2 works as well as it needs to).

bandrami 9y ago

> at this point there is no reason to not use Python 3 for new projects Sure there is: Python 2 isn't going to change on me again. Python 3 might.

bandrami 9y ago
Why on earth do people downvote that? I want a language that isn't going to change. Every single other language community seems to understand that, but something about it pisses off Python people.
- rspeer 9y ago
  You're claiming to know the future of Python better than "Python people" know the future of Python. Python has changed incompatibly once in 26 years, and never plans to do it again, yet you're making it sound like an ongoing pattern. What language are you going to run to that has that kind of track record?
  - yjftsjthsd-h 9y ago
    POSIX sh?
    - rspeer 9y ago
      Have fun with that?
      - frou_dh 9y ago
        Real 'fun' to program in - with strict POSIX shell, functions cannot even have local variables.
  - bandrami 9y ago
    30 years later, scheme is still scheme. A different report has come out, and some compilers choose to implement it. But the language hasn't changed. See my point?

jchw 9y ago

I'm currently using Go (and Python - we did go from Python 2 to Go, but later continued using Python 3) at work, but for all of the hoopla about it's concurrency, the reality is I'd rather have Rust's superior runtime safety and metaprogramming. A few things have impeded on Rust adoption at work: - Learning curve. Rust is not as bad for learning as C++, but any language with strong metaprogramming and unfamiliar or relatively new language concepts are bound to be stumbling blocks. - Ecosystem. The Go ecosystem by and large is awesome. Rust's is getting up there, though. It'd be really cool if Mozillas work with Servo meant there would be pure Rust HTML rendering and JavaScript interpreter code though! So far, impressed with minimal but powerful libraries like Iron. - Maturity. Rust itself is pretty good, even nightly feels stable, but the developer tools are still shaping up. Until recently, rustup crashed on my Win10. Things are a lot better today, especially with the Rust Language Server. - Marketing. Rust has a ways to go on its marketing. This has improved recently as well and I'm glad. Some underestimate the importance of having good PR for a programming language - people need to be really confident to adopt a programming language for critical components, and Go is in a place where many would trust it just because of its reputation. Also good for convincing your coworkers to give it a shot. That being said, while Go makes concurrency easy and generally acts as a great simplistic language to develop services in, I really feel as though Rust's potential is enormous. The 'simplicity debt' of Go can be taxing sometimes. I still love Go, though. I am just struggling to figure out which tool to use for which jobs. Though there's large areas of overlap, there are definitely things that feel nicer in either than the other.

jernfrost 9y ago
I kind of like the idea of Rust, but I don't really have much belief in complex programming languages. C++ only has a large following because it piggy backed on C, which people already knew, then it gradually grew its complexity. It is quite a different challenge to get people to use an entirely new language with high complexity. Companies are going to be negative towards adopting a language with a steep learning curve for its employees. That represents too much risk and money. I think Swift is a much better alternative to those who want something like Rust. Much easier to learn and you still got native code and strict typing without a need for a garbage collector. People also know they can trust it in the sense that they know Apple supports it and all Apple development is switching to it. That takes a way a big risk factor for companies.