
Ask HN: Could Python be reborn in the image of Go? - peterwwillis
(Disclaimer: I&#x27;m not a CS major and I&#x27;m generally a novice at software engineering, so I have no idea if what I&#x27;m proposing is crazy or not)<p>I&#x27;ve been noticing the increase in projects using Go seemingly to replace other existing projects written in Python. Go seems to have a strong following now due to a couple of useful features, but it&#x27;s still a new language, whereas Python is an established language that many people enjoy writing code in. The question is, could Python be updated to include the kinds of core features that make Go attractive, while still retaining its Pythonisms?<p>Go&#x27;s strengths seem to be in its static types, concurrency features, static analysis tools, lack of generics, and compiled binaries. I could be wrong, but it seems like all of these (save maybe the improved concurrency) could be added to Python and be a strong competitor to Go. Most of the language could remain the same, but it could then be adopted in places that Go is gaining a foothold. The main purpose would be to increase the utility of the existing body of knowledge around Python, and increase its usefulness.<p>Am I crazy?
======
shoo
python already forked the language once for py2 --> py3. it has taken a long
time in many places for py3 to be adopted. i worked professionally with python
for about 8 years and never once wrote a python 3 program for a client. the
last enterprise i was working at that had python code would have had something
like 1 million lines of custom python 2 code last year, and was showing no
signs of slowing down, or thinking about porting to python 3. it is arguably
not a winning move to make another backwards incompatible change to the
language. a lot of the value is in the ecosystem of existing useful libraries.

one of the things i like about go - ease of deployment - is more irritating
with python. but: once you have set up a pipeline for deploying your python
code, then you're good. it's not really like the python language needs to be
reengineered to compile into a single statically linked binary to make it
possible to ship. these days there are containers and so forth, and
historically a number of bundling and packaging tools for python apps have
been available.

i would still pick python over go any day for prototyping algorithmic or
numeric code -- it is a terser and more expressive language for computing
things, and python's dynamic typing + duck typing lets you write syntactically
generic code.

------
mattmanser
Yes, but mainly because you have identified the wrong differences.

Go is fast, because it is statically typed and compiled. But this requires a
good understanding of programming or your program will simply not run.
Learning Go as a first language is hard.

Python is slow, because it is dynamically typed and interpreted. This makes
Python easier and more forgiving to beginners. Learning Python as a first
language is much easier.

One is Meccano, the other is Duplo.

What you've said doesn't make sense as they have different aims and target
markets as languages.

What happened with Python is the it got adopted by academics, amateur
programmers, who a decade or two ago needed an easy language as they first
started experimenting using programming in their fields. So Python ended up
with a huge number of specialist libraries.

Now they are experienced, a lot of academics want a fast one and Go fits that
niche better than C/C++ (hard, easy to make very bad mistakes) or Java/C#
(complicated, need compilation and deployment).

------
abhijat
Possibly unrelated but [https://nim-lang.org/](https://nim-lang.org/) has a
syntax somewhat similar to python (and pascal), and has a static type system
(plus generics). It compiles to multiple languages like C, C++ and JS and can
produce native binaries.

------
HelloNurse
No, it's a completely different design with completely different priorities
and objectives. Copying good approaches to tools (e.g. the dependency
management found in Cargo instead of the current need for manually managed
Python virtual environments and related inconveniences) is a good idea in
principle, but compromising what you correctly call "core features" would
alienate users who like Python for what it is without attracting new ones.

------
paulie_a
Please no. I love both languages but they are a different for a reason

------
dyeje
They are complete opposites in many aspects of their design. It would not make
sense.

