16 ms·
See Python, See Python Go, Go Python Go (2016)
- tech234a 7y agoTitle should mention this is from 2016.
- dang 7y agoAdded. Thanks!
- lostmsu 7y agoThere is a similar project for .NET: https://github.com/pythonnet/pythonnet https://github.com/pythonnet/pythonnet It makes calling C# as easy as: import clr import System uri = System.Uri('http://python.org') And also works the other way around. In both cases you have to mind GIL though.
- shbooms 7y agoA similar project to pythonnet (a CPython package that implements .NET) is IronPython (a C# implementation of Python 2.7) the latter of which isn't limited by the GIL since it's not using CPython. https://github.com/IronLanguages/ironpython2 https://github.com/IronLanguages/ironpython2
- lostmsu 7y agoAt this moment IronPython is nearly dead. 2.7 EoL has passed and IronPython 3.x is not ready.
- simonh 7y agoI don’t think the EOL of CPython 2.7 should necessarily bother anyone using IronPython. It’s not like IronPython depends on CPython in any way, or is exposed to any CPython bugs or vulnerabilities. I can see it from a standardisation point if view of course.
- shbooms 7y agoTrue, IronPython3 isn't ready and with 2.7 EOL I would say that it may not be a great fit for someone currently weighing up their options between it and pythonnet to use in a current project. Development on IP3 is, however, still very alive and active so I wouldn't consider the entire project dead: https://github.com/IronLanguages/ironpython3/commits/master https://github.com/IronLanguages/ironpython3/commits/master
- toyg 7y agoIs there anything about doing it the other way around, i.e. embed python code in Go...? I wish we could get the easy-deployment story of Go around the easy-development story of Python.
- maxmcd 7y agoYou might be interested in this: https://github.com/google/grumpy https://github.com/google/grumpy (although it looks like it's not close to supporting the needed functionality to import a typical python library)
- xyproto 7y agoGrumpy was abruptly abandoned by Google, 3 years ago. There is an active fork here: https://github.com/grumpyhome/grumpy https://github.com/grumpyhome/grumpy
- hopia 7y agoI'm also curious to know how people who use Python for data science and combine it with some other platform for web facing endpoints architect their apps in the cloud.
- rajamaka 7y agoPython web server triggering lambda functions to process jobs
- hopia 7y agoWhere do you put the web server? What's the purpose of it? Or you mean to use Python as the client facing API server? I meant how to architect if you use some other platform for the publicly exposed API. Would you build an internal Python API at the lambdas that run the actual data science computation, and invoke that from the client facing API/app?
- trufas 7y agoI haven't done this specifically but it seems like a perfect use case for a smaller separate service. You'd probably submit jobs through an internal API (REST, gRPC, pick your poison) or through a job queue like Celery, if they're slower operations.
- raziel2p 7y agoThe gohttp library seems to do a lot less than what gunicorn/werkzeug/flask does. I would guess this is what makes the drastic performance difference, not the fact that the HTTP handler is written in go. I'm surprised that it was so close to go-net/http performance, though.
- jchw 7y agoActually it’s probably concurrency: > Keep in mind that this is with 10 concurrent requests, so werkzeug-flask probably chokes more on the concurrency than the response time being slow. I am not sure though. I’d imagine Go can beat Python performance enough to make up for the (clearly not very egregious) CGo penalties.
- hermitdev 7y agoI haven't dealt with Go at all, but if you can use aiohttp on Python 3 (3.5+ IIRC), it is remarkably fast for handling asynchronous requests. In my testing, saw something like a 66% wall clock reduction over using multiprocessing to achieve parallelism. Sadly, cant use it in production, because aiohttp doesnt currently support Negotiate/SSPI auth.
- alimoeeny 7y agoI had not used python for like 5 year, since when I migrated all my work to go. Recently I went back to python and was shocked to see how hard (relatively) it is to setup a (moderately) high performing web server in python. I mean in my case I had a “data science” type application and sometimes a request would block and take a second to finish, and this meant a handful of users would bring the server to it’s knees (due to extremely high mem usage I could not have a lot of indepentend worker processes running at the same time), I wish I could call python code from within a go web server with some ease and safety.
- Something1234 7y agoYour claims are without merit unless you post details about your setup and what you were trying to do. Especially considering that there's quite a few sites which run entirely on Python.
- alimoeeny 7y agoThis claim is specifically related to blocking webserver in python vs concurrent webservers in go. I assumed this is common knowledge, that scaling python webservers is a complicated thing, while in go you get a concurrent web server in standard library,
- throw_14JAS 7y agoWere you deploying using a Python webserver (e.g. SimpleHTTPServer), or was it nginx routed to an app server?
- infecto 7y agoAnd this is the trouble with the OP imo. While its true, I find it an unfair comparison to make.
- hermitdev 7y agoHow about comparing a blocking server in Go versus the same in Python, then an async server in Python vs the concurrent Go server? That would be a more apt comparison.
- allanrbo 7y agoHe touches upon it in the "Runtime Overhead" section, but I think when calling Go from C like this you loose a lot of the goodness of Goroutines, and any code making heavy use of Goroutines could become seriously problematic. In native Go, Goroutines are very lightweight and cooperatively scheduled. In a CGo env I believe they each have an OS thread and a full stack. Source: https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
- sascha_sl 7y agoThey do not, the go runtime just locks the OS thread to the goroutine calling C until it comes back out. This can lead to fun deadlocks that only appear on single-core machines (because by default GOMAXPROCS is equal to the core count). Similarly, Docker locks goroutines to the OS thread when using the unshare system call to spawn containers. These are of course later discarded. It has to be locked because any goroutine might be stopped at any (automatically inserted by the compiler) checkpoint and resumed on a different OS thread. Unsharing the network interfaces from half your OS threads is a fun way to chaos test networking in Go. https://golang.org/pkg/runtime/#LockOSThread https://golang.org/pkg/runtime/#LockOSThread http://man7.org/linux/man-pages/man2/unshare.2.html http://man7.org/linux/man-pages/man2/unshare.2.html
- justaguy12 7y agoor like just use go
- dragonsh 7y agoWerkzeug/flask and gohttp in my view is not a fare comparison. Based on the details of the project werkzeug is designed to build WSGI apps easier and flask is just a convenient library on top of it providing easier way to manage request/response. It is designed for developer productivity and performance is left to specific infrastructure software like gunicorn, uwsgi and others. Flask/werkzeug or any WSGI/ASGI related servers were designed for interfacing with a http server like nginx, apache, gunicorn, uwsgi and many. A python LWAN http server can beat go http server [1] [2]. Also take a look at comparison of various frameworks in Python including go http server [3]. People are most productive in the language/framework they are most familiar and will defend it. Every language/framework has their own strength and weakness and I believe over a period of time ideas flow from one language to another. Indeed today many people in Python community will be moving towards Rust or Go because they think it can solve all their problems they face with dynamic typing and performance, which might not be entirely true. It's upto an individual to decide if they want to go that path. As an example werkzeug/flask framework developer Armin moved to Rust in spite of it being a complex language with very large syntax surface area and a steep learning curve. In my opinion Rust's complexity, difficulty to learn and understand, and probably a promise of type and memory safety (which is not 100% true given it needs to interface with C in unsafe mode and will only be as safe as the underlying C implementation), makes people adopt it to make them feel better programmers (Personally I would have chosen Haskell, if needed to do the same). Now all the Python projects he worked on is mostly maintained by volunteers and David. But being a responsible open source developer and contributor before moving in that direction Armin did create pallets projecs [4]. So his decision to move is right for him given his preference and learning priorities. [1] https://www.nexedi.com/NXD-Blog.Multicore.Python.HTTP.Server https://www.nexedi.com/NXD-Blog.Multicore.Python.HTTP.Server [2] https://lwan.ws/ https://lwan.ws/ [3] https://www.freecodecamp.org/news/million-requests-per-second-with-python-95c137af319/ https://www.freecodecamp.org/news/million-requests-per-secon... [4] https://www.palletsprojects.com/ https://www.palletsprojects.com/
- blargmaster33 7y agoStill no {} still shit
- bra-ket 7y agothere is a video of Andrey's talk on this from PyCon CA 2016: https://pyvideo.org/pycon-ca-2016/see-python-see-python-go-go-python-go.html https://pyvideo.org/pycon-ca-2016/see-python-see-python-go-g...
- The_mboga_real 7y ago2016, the year of all those hard times!
- hwestiii 7y agoShouldn’t that be “C Python Go, Go Python Go”?