Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

Post reply on HN
Print view View original

421–430 of 463 posts

Re: Grumpy: Go running Python

#421

Post by takeda »

vram22 wrote: post #300
takeda wrote: post #229

Earlier quoted context omitted.

To me it looks like Google essentially is moving everything to Go, and this project is to help with it. They port their python libraries so they can reference them from their Go code, and then module by module will rewrite it in pure Go.

>To me it looks like Google essentially is moving everything to Go, and this project is to help with it. Interesting - first time I have heard such an opinion. Why do you think it may be so? One reason I can think of, is they get more control over the languages they use.

The Go seems to be developed for their needs (well it's coming from them). It's simple to learn, it's very opinionated, how code is stored, how it is formatted etc. It seems perfect for a company that gets a lot of college graduates.

Now with Python, they still seem to stick to Python 2.7 and don't show any effort to move. TensorFlow was released for Python 2.7 and only later Python 3 support was added. Grumpy is for Python 2.7 and first issue opened asking about Python 3 support was closed with change in documentation that only Python 2.7 is supported.

To me it seems like they wouldn't stick to Python 2.7 if they were planning on continuing using Python. It seems like it coincides with deprecating Python 2 in 2020.

Re: Grumpy: Go running Python

#422

Post by scriptkiddy »

pjmlp wrote: post #418
quotemstr wrote: post #417

Earlier quoted context omitted.

Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.

I am yet to see such benefits in action. The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.

>I am yet to see such benefits in action.

Here you go:

https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-...

https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-...

For more examples, just search "pypy faster than c".

Also, here is an article from the Python wiki about why speed doesn't really matter a lot of the time:

https://wiki.python.org/moin/PythonSpeed

And, my own two cents:

Speed is relative. Does every piece of code need to be as performant as possible? No. I would argue that, in most cases, speed of development is far more important than speed of execution. This is, of course, not true for things like drivers or statistical analysis.

Writing a web application? Speed isn't that important as the whole process is i/o bound anyways.

Writing a machine learning algorithm? Depends.

Web scraping? I/O bound, speed not really important.

Image processing? Speed matters at least a little bit.

Writing networking glue for distributed systems? Speed probably doesn't matter.

It's all relative. If it needs to be fast, it needs to be fast. Most things don't really need to be fast. For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?

Re: Grumpy: Go running Python

#423

Post by statsmatscats »

BuckRogers wrote: post #409
guitarbill wrote: post #330

Earlier quoted context omitted.

> you want to be writing Python2 syntax because that's where all the action is. > This is Python3 as most of us wanted it to be. > Valid Python2 is Grumpy already. > It compiles existing Python2 AND offers a legitimate upgrade from CPython at the same time. > As far as all of the lost C extensions? You won't need them None of the statements are true. You seem to be very confused what Grumpy can and can't do, and what…

Citations needed for your assertion on each point being false. Grumpy proves Python2 is where the action is at. Everyone wanted a speed improvement with a new Python, that's the ultimate carrot.. instead Python3 was and still is in some ways slower than 2. Other than exec, eval and C-extensions, Python2 is valid Grumpy. You didn't provide any reasoning or proof that my points, which were just reiterated, were false.…

Lead on the project said he would like to support python 3 at some point.

Re: Grumpy: Go running Python

#425

Post by statsmatscats »

pjmlp wrote: post #418
quotemstr wrote: post #417

Earlier quoted context omitted.

Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.

I am yet to see such benefits in action. The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.

Actually, they said they would keep programming in python.

Re: Grumpy: Go running Python

#426

Post by pjmlp »

scriptkiddy wrote: post #422
pjmlp wrote: post #418

Earlier quoted context omitted.

I am yet to see such benefits in action. The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.

>I am yet to see such benefits in action. Here you go: https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-... https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-... For more examples, just search "pypy faster than c". Also, here is an article from the Python wiki about why speed doesn't really matter a lot of the time: https://wiki.python.org/moin/PythonSpeed And, my own two cents: Speed is relative…

PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers.

I usually ignore it when talking about Python, because that is what the community does, by gathering around CPython.

> For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?

Because one can use languages like OCaml, Haskell, Lisp, Scheme, Racket, F#, C#,... thus having both the productivity of a REPL environment and the execution speed of native code.

Re: Grumpy: Go running Python

#427

Post by scriptkiddy »

oblio wrote: post #6

It seems interesting but my concern is that it's just another Unladen Swallow.

I made an agreement to myself to never use any Google language, tool, or library after they decided to shut down google code. Google has a history of creating all of these crazy projects and then just completely abandoning them leaving the early adopters to fend for themselves. It's really bad practice and leaves a nasty taste in my mouth. That's why I haven't even tried Go. I have no interest in it. As soon as Google develops some other language they'll drop Go like a hot potato and everyone using it in production will be forced to rewrite or stagnate.

Look at AngularJs for a more recent example.

Add to this that Google has some of the worst versioning practices I've ever seen and you get a recipe for destruction.

Re: Grumpy: Go running Python

#428

Post by pjmlp »

orf wrote: post #406
pjmlp wrote: post #405

Earlier quoted context omitted.

> LANPACK + BLAS = scipy Thanks, I already knew that. > Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages. Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.

> Scala, Clojure, F# Functional languages. The "year of Linux on the desktop" of programming languages. Also none of those look like pseudocode (Scala does if you ignore bits and squint).

The amount of job postings say otherwise.

Re: Grumpy: Go running Python

#429

Post by scriptkiddy »

pjmlp wrote: post #426
scriptkiddy wrote: post #422

Earlier quoted context omitted.

>I am yet to see such benefits in action. Here you go: https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-... https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-... For more examples, just search "pypy faster than c". Also, here is an article from the Python wiki about why speed doesn't really matter a lot of the time: https://wiki.python.org/moin/PythonSpeed And, my own two cents: Speed is relative…

PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers. I usually ignore it when talking about Python, because that is what the community does, by gathering around CPython. > For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc? Because one can use languages like OCaml, Haskell, Lisp, Scheme…

>PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers.

I thought we were talking about Python implementations exclusively. My mistake.

>OCaml

I have no experience with OCaml, so I won't make any comments regarding it's efficacy.'

>Haskell

Well thought out language. I like the purity, but it's too academic for real world use outside of scientific computing. FP isn't for everyone, and my personally belief regarding it is that it is better used as a tool alongside other paradigms than all by itself as the only paradigm.

>Lisp

Lisp is useful for a lot of things. It's also not very popular for new projects as far as I've seen. There are also a ton of different versions, so I don't know if "Lisp" is really a good descriptor.

>Scheme

As far as I know Scheme is the defacto teaching language for most compSci programs.Or, at least it was for a long time. Once again, FP is not for everyone. A lot of people also dislike Lisp style syntax, myself included.

>Racket

Same issues as Scheme.

>F#

F# is a fantastic language. There's not really a whole heck of a lot to complain about other than the .NET implications. The only detriment relative to Python is F#'s much smaller ecosystem and community.

>C#

Once again, some people just don't like .NET stuff. A lot of people also see static typing to be a detriment in many use cases.

Relative to Python, these languages also share several other problems when it comes to real world application: lack of competent developers, stagnating ecosystems, lack of third party libraries, ecosystem lock in, and cross-platform comparability issues. In the case of languages like Haskell, they could even be considered "esoteric".

I'll give you that many of these languages are more "pure" or "logical" than Python. I'll even give you that most of them are designed much better than Python. None of that changes the fact that Python is overall easier to read, easier to learn, easier to write, has a better ecosystem, is platform and file system agnostic, has a very non-restrictive license, and is, overall, very pleasant to work with.

Re: Grumpy: Go running Python

#430

Post by dagss »

ericfrederich wrote: post #74
the_duke wrote: post #36

Earlier quoted context omitted.

Actually, I would interpret this as "CPython is broken for scalability. It's not worth trying to fork/fix it, we'd rather just roll our own runtime". Not exactly an endorsement. Sadly, the code was just dumped into a new Git repo, so no way to tell how many people contributed internally so far.

I agree and disagree ... on one side this may signal a shift away from Python. Something to help the migration effort and the ultimate goal is to write everything in Go. ... but then I don't see Python going anywhere anytime soon. Didn't Microsoft just start a project to get Python's runtime to use CoreCLR's JIT? There was an article, can't find it now, about an upcoming Python renaissance saying there may be an infl…

Microsoft had IronPython, which was then semi-abandoned...
Post reply on HN