When C extensions crash: easier debugging for your Python test suite | Hacker News Reader

When C extensions crash: easier debugging for your Python test suite

pythonspeed.com

23 pointsitamarst7 comments

This is why I think Python programmers are suffering from Stockholm syndrome. Why you'd write your app in Python and dealing with crashing C extensions, asyncio, mypy, etc, when you can write Go, which is fast, allows you to approach concurrency synchronously, and has a type system for anything other than data science is beyond me.

Go is really the successor to Python more than any other language. If combines the same love of simplicity, readability, and the "one way to do things" approach that made Python so successful with modern day takes on multithreading and safety.

There are areas that python is still ahead of go. Simply python having REPL to lack of REPL in Go is huge advantage. At least for me.

Go has REPLs, and the playground, and extremely fast compile times, faster than it takes to load python byte code in many cases.

You're missing the point of what makes Python attractive (to me at the very least):

-> Easy to pick up

-> Ecosystem of libs : whatever domain specific problem you're dealing with, there's probably something out there to help you.

-> Ecosystem of users : be it for hiring or simply stack overflowing your issues, there's plenty of people.

All of this contributes to make Python the best Swiss Army knife of programming.

If you go chopping some wood, I'd recommend using an axe / chainsaw / saw but for the day to day, your generalist tool does the trick.

None of those things are specific to Python. In fact Go's formal specification is small enough to be read in one sitting, and it omits concepts like decorators, generators, and sheds alternatives for single solutions, such as removing inheritance in favor of only composition. Go is designed to be picked up faster than any language.

Go is also designed to be easily understood. Python uses a lot of magic, like MagicMock, operator overloading, any all of the fun dynamic overloading you can do. Go favors being incredibly, stupidly simple instead.

Go also has a huge user base and although Go has no formal package repository, Go's popularity makes it exceedingly likely that you will not just find a package for what you're doing, but a package that is actually maintained and being actively worked on.

There's also nothing about Go that makes it less of a generalist language than Python.

Go only provides a better solution for a subset of the tasks and use cases that Python supports. It's no good being fast, if it's also missing library support. That said, I can see your frustration when you are dealing with a domain where Go is extremely strong.

If Go expands its use cases then over time, I think Pythonistas will move to it. It seems like a relatively compatible community compared to Java or .NET.

I don't understand why Go offers any advantages here for C extensions: either you're reimplementing the C code in Go, which is a different ballgame (the reason you're not reimplementing the C code in Python is rarely speed), or you're using cgo which has the same problems.

Reply on news.ycombinator.com