Qué opción es mejor para una API de alto rendimiento: Python asyncio o Go?

[James92]

Últimamente me he encontrado con un dilema en el trabajo. Llevo un par de años usando principalmente Python para automatizaciones y scripts, pero ahora en mi nuevo proyecto me pidieron que me encargue de una API que debe ser extremadamente eficiente con el manejo de peticiones concurrentes. Estuve leyendo y muchos recomiendan Go para este tipo de casos, específicamente por su modelo de concurrencia con goroutines. La verdad es que me da un poco de pereza aprender un lenguaje nuevo desde cero para esto, pero también me preocupa que si uso Python con asyncio pueda estar eligiendo la opción menos robusta a largo plazo. No sé si alguien ha pasado por una decisión similar.

[StevenTS]

Entiendo la pereza de aprender un lenguaje nuevo para un tema de rendimiento. La concurrencia en una API parece un acertijo en tiempo real. Go con goroutines suena bien pero implica otra curva de aprendizaje. A veces vale más intentar una microprueba en Go para ver si las promesas de rendimiento se sostienen.

[Isabella.M]

Desde la mirada técnica Python con asyncio puede bastar si la API es IO bound y se evita el cuello de CPU. El GIL no se ve cuando solo haces IO y si hay CPU heavy en handlers hay que migrar pesados a subprocess o usar herramientas como worker pools. Si ya dominas Python la productividad puede superar la ganancia de Go en un primer ciclo.

[Harper91]

Mi lectura es que la clave es que Go es imprescindible para la concurrencia pura y ya estoy convencido de que Python nunca alcanza. Pero quizá solo es un mito y con asyncio y uvloop puedes lograr lo mismo sin aprender un nuevo lenguaje.

[George64]

Tal vez la premisa es estrecha. ¿Y si el cuello de la botella es la red o la base de datos? Quizá la solución pase por diseño de API y caching y no por cambiar de lenguaje.

[Olivia91]

Podría ser interesante dividir la tarea en dos servicios. Un servicio en Go para la ruta de alta concurrencia y otro en Python para la lógica compleja. Eso mantiene lo mejor de cada mundo y evita apostar a ciegas.

[Scott_C]

Go tiene su encanto pero la productividad importa. Si el equipo ya domina Python y la entrega debe salir ya, quizá vale más una optimización en Python primero y luego migrar.

[Harper.R]

Lo práctico es medir con una prueba de concepto y que el negocio te diga si la latencia es aceptable. Si no, migras a Go para el cuello de la botella.