Comment by jsd1982 | Hacker News Reader

Comment by jsd1982 | Hacker News Reader

Parent Full thread

I'd rather stick with Golang here because it's not hiding anything. Everything in the Go stack is written in Go, and all your http handler (business) logic is written in Go.

With this mix of C and Python it's impossible to tell what will happen to the system's performance when you actually include significant amounts of business logic written in Python on top of the C framework here. The author even makes a point about how little actual Python code and/or data structures are in use. If use of the host language is discouraged in the framework, how can I trust the performance of the framework with my code written in the host language?

I bet if you put anything non-trivial on top and try to connect with real-world http clients which mostly don't use pipelining, it will fall over hard. Enjoy debugging what you can't understand.

The emphasis on http parsing using SSE intrinsics is odd, as http parsing is rarely a bottleneck. I'm not saying it can't be, but that'll only be when you've got the rest of your stack highly tuned, performance is predictable, and profiling has shown that http parsing is your actual bottleneck. Even so, http/2 in theory alleviates this bottleneck and you don't have to use processor-specific intrinsics, as well as providing a better solution to pipelining problems with its multiplexing of requests.

EDITED: "how can I trust the performance of the framework with my code written in the host language?" Original text lacked emphasized addition.

Python always made it possible to use C, that's a design feature. It's ridiculous to characterize this as untrustworthy.

I only meant trustworthiness in terms of predictability of performance.

The point was that Go's http stack and standard library and runtime being written all in Go gives me confidence that any Go code I write on top will enjoy the same performance characteristics and that there will be very few surprises. It's predictable due to its uniformity.

I assume your OS and hardware firmware is also written in GO...

Performance is a non-predictable good on macroscopic (application) scales.

This is also why I am looking into more analytics work in Go. Uniformity of performance across different data analysis processes.

I wouldn't say untrustworthy, but it's definitly misleading to say python achieves those performances, when it's actually calling into C for most of it.

It may be misleading to imply that this is pure Python, but if the C is encapsulated well enough that someone can write their server solely in Python then it's easy to argue that this is Python. After all, Go has bits that are written in assembly, but we don't have to qualify every Go benchmark with an asterisk and a footnote to mention that.

Well, I guess that's a good argument. Though I feel like unless it's part of the base language implementation, you'd have to consider it an extension to the language.

So CPYTHON can not in fact deliver those performances. But CPYTHON can be extended through Japronto to achieve them. I'd say it's still misleading, since casually when we refer to Python, it means CPYTHON.

Go's primary implementation provides all the fast goodies needed for fast performance. There could be a slow Go compiler which didn't, but when you say Go, it refers to Google's implementation.

You could argue that at least, CPYTHON makes it easy to extend the language with C. So Python language extensions are trivial to use compared to some other languages. So at least I'll give you that.

many parts of the stdlib in python are written in C, so C and python are really working close together in python.

That's how scripting languages have always worked. Typically the reason one language is considered scripting while another like Go is not. I tend to like the Python arrangement more because it's almost as high level as you can go and even pure Python performance suits me. But they're both good setups.

Reply on news.ycombinator.com