Hey HN, I’m one of the creators. We’re always dealing with each WYSIWYG’s quirks, strengths, and licensing. It’s tedious. Being able to preview and compare them in one place really speeds up picking the right editor for each project. Hope it helps. Let us know if we’re missing something!
Unfortunately the native interface is still pretty immature so I can't guarantee things will work as they should. In this case, I think the problem is that you have a *Response object which is not itself a struct. I've rewritten this part of the code a couple times and I think this functionality was lost. I've filed: https://github.com/google/grumpy/issues/13
Sorry, can't be very specific, but rewriting all the frontend code would take a lot more effort than writing a new Python runtime :)
> It seems like writing a translator to deal with all the use cases is so much more work and risky than iteratively rewriting portions (in whatever faster more concurrent language) and using some form microservice/process message passing to communicate with legacy pieces.
We do iteratively rewrite components as well. We are pursuing multiple strategies.
> Love to know how they compose async operations currently? Is it some sort of object (e.g. Futures, promises, observables, etc)?
Most async operations are performed out-of-process by other servers.
> Is Grumpy going to have some sort of language difference (to Python) to compose async stuff (e.g. async and await)?
I'd love to support async and await at some point.
> Of course being biased towards the JVM (since I know it so well) they could get really fast concurrency if they want with Jython today. Most of the Python tools already work with Jython (assuming 2.7).
We did also do an evaluation of Jython but there were a number of technical issues that made it unsuitable for our codebase and workload. One such example is this longstanding issue: http://bugs.jython.org/issue527524. I just noticed the very recent update on that thread that implemented the workaround outlined in 2010 by Jim Baker. We tried that workaround and found we got a huge performance hit on affected code. There were a few other general performance problems as well but I can't recall all the details.
Please note I'm not at all bashing Jython, I think it's a great project with a sound design, it just wasn't right for us.
> With Jython you could always drop down into Java (or any other JVM lang) if you need more speed as well C for cpython (or even C from Java). It is unclear what you do with Grumpy with performance critical code. Can you interface with Go code or is the plan C?
You can interface with Go code directly, e.g. from the blog post:
Reflection in Go is used minimally in Grumpy because it is slow. Currently importing Go packages into Python code is accomplished via the reflect module, but I think this will have to change to make such integration useful.
As has been said by others, Grumpy is not used in production at Google currently. There's still a lot of work to do -- especially on the standard library -- to support large real world codebases.
Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc.
The main reason why Grumpy's slower for most single threaded benchmarks is that most Python workloads involve creating and freeing a bunch of small Python objects. In Go, these objects are garbage that need to be GC'd in a very general way. In CPython, there are free lists, arenas and other optimizations for allocating small (especially immutable) objects. And cleaning up garbage in CPython involves pushing unreferenced objects back onto the free lists for later reuse.
> Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc.
Right, I suppose I assumed that straightforward numerical-looking code would be translated to Go numerical code. Perhaps they just aren't that ambitious yet.
It's been said a couple times in this thread already but basically, the YouTube Python codebase is very large and the cost of a rewrite is prohibitive.
