(original) (raw)

On 29 May 2015 22:50, "Donald Stufft" <donald@stufft.io> wrote:
\>
\> This might be something that people could have done before with C/C++ but with
\> a nicer language behind it... but that's kind of the point? You don't need to
\> be stuck with a terrible language to get a nice single file executable anymore,
\> you can get that and use a good language at the same time which makes it a lot
\> more compelling to a lot more people than having to be stuck with C.

Right, but the only things you can really write in Go are network services and console applications - once you start looking at curses & GUI applications on the end user side, you're back to the same kind of distribution complexity as C/C++ (where you have to choose between external dependency management or very large downloads), and once you start looking at the infrastructure side, Docker, Rocket & Kubernetes are bringing this kind of easy deployability to network services written in arbitrary languages.

Hence my comment about MicroPython: the easiest way to make an interpreter runtime that's lighter than CPython is to have it \*do less\*.

Communicating with embedded MicroPython instances via cffi could even potentially offer a way for both CPython and PyPy to split work across multiple cores without having to fundamentally redesign their main interpreters.

Cheers,
Nick.