¿La gente ha comenzado a lamentar haber elegido Python como su principal lenguaje de fondo?

Voy a expresar mi opinión personal . Puedo estar y probablemente estoy muy equivocado porque mi kilometraje en Python no es enorme.

“Lamento” es una palabra fuerte. Se puede hacer cualquier cosa y escalar en Python suponiendo que la potencia de la CPU sin procesar y la RAM son abundantes.

Python es ideal para la creación rápida de prototipos, la integración de diferentes componentes. Hay muchas bibliotecas convenientes con código razonablemente estable. Un proyecto de Python tiende a golpear un muro cuando ocurre una de las siguientes cosas:

• Necesita una mejor administración de memoria, porque por alguna razón no puede permitir que Python mantenga toda esta memoria asignada indefinidamente. Puede deberse a la visibilidad de la huella de la memoria: se ve mal. Puede ser porque hay otras cosas ejecutándose en la misma máquina. Probablemente una anécdota reveladora: la búsqueda en Google de “gestión de memoria de Python” arroja resultados de 3M frente a 1.5M para “gestión de memoria de C ++”.
• Desea aprovechar un sistema multinúcleo. La forma habitual de hacer esto en Python es ejecutar varias instancias del intérprete. Una instancia de Python que hace algo útil comienza alrededor de 200 MB de RAM.
• Necesita un mejor rendimiento y no puede aprovechar el multinúcleo / nube por cualquier motivo. Casi todo lo que Python “hace” se hace en el código C. No hay una manera fácil de mejorar el rendimiento parcheando el CPython. Lo que vas a hacer es extender Python con un código C / C ++ personalizado. El enlace entre un lenguaje dinámico y C conlleva una sobrecarga.
• Los costos absolutos de mantener un objeto en la memoria limitarán la cantidad de objetos que una sola máquina puede manejar. Yo estimaría que C ++ es 20 veces más eficiente.

Línea de fondo. Si conoce los objetivos, la tarea está bien definida, la visibilidad es buena. Python es un gran lenguaje. Si el tiempo de comercialización es de extrema importancia y se requiere una creación rápida de prototipos, que es el 100% del tiempo, Python es su mejor amigo y es insuperable.

Ahora intentaré responder la pregunta original. ¿ Han comenzado a arrepentirse las personas por haber elegido Python como su principal lenguaje de fondo? . La elección de Python no fue mía. Dadas las circunstancias, haría la misma elección. Estoy pensando que es hora de refactorizar el código.

La pregunta se cambió a Esta pregunta busca datos estadísticos de la vida real, por lo que no necesito esa elaboración teórica.

Soy consciente de un solo proyecto que, en mi humilde opinión, está llegando al punto en que partes del código de Python deberían reemplazarse (la mayoría de los problemas siguen relacionados con la base de datos). Esto no es suficiente para “datos estadísticos”. Apuesto a que hay Quorans trabajando en lugares grandes donde se están trabajando proyectos de 10 o 100 años, y que con gusto aprovecharán esta oportunidad para compartir con nosotros los dolores de Python y las estadísticas de tasa de éxito.

“El verdadero problema es que los programadores han pasado demasiado tiempo preocupándose por la eficiencia en los lugares equivocados y en los momentos equivocados ; La optimización prematura es la raíz de todo mal (o al menos la mayor parte) en la programación . ”- Donald Knuth [1]

Ahora con eso dicho, permítanme mantener mis prejuicios fuera de la discusión y analizar los diferentes parámetros sobre cuya base se determina el rendimiento de los lenguajes del lado del servidor:

1. Escalabilidad

Muchas personas a menudo no entienden la diferencia entre escalabilidad y rendimiento. Supongamos que un servidor de aplicaciones basado en Python tarda 200 ms en atender una solicitud. Podría tomar mucho menos decir 50 ms en el servidor de aplicaciones basado en el lenguaje de programación Go. Ahora esa es la comparación de rendimiento, no la escalabilidad. La escalabilidad es la medida de cuántas solicitudes puede manejar un programa mientras se mantiene el mismo rendimiento. Por lo tanto, el factor más crucial no es generalmente el rendimiento, sino la pendiente del rendimiento a medida que aumenta el número de solicitudes. Puede dibujar una analogía con una notación O grande, es decir, O (n) ~ = O (3n).

Ahora, en el caso de los idiomas del lado del servidor, la mayor parte del tiempo no se dedica a tareas vinculadas a la CPU, sino a tareas de IO. Por lo tanto, a menudo la escalabilidad no tiene nada que ver con la elección del lenguaje de programación, y tiene mucho más que ver con sus bases de datos, almacenamiento en caché y selección de servidores web.

Entonces, declaraciones como “Los rieles no escalan” o “Django no escalan” no significan nada (y sé que lo he negado doblemente).

2. Capacidades de multiprocesamiento

En el caso de los programas del lado del servidor, como dije, la escalabilidad suele ser una preocupación mucho mayor que el rendimiento. Dado que los servidores web como uWSGI o apache que atienden solicitudes de Python ya tienen muchos procesos y subprocesos en ejecución y ya usan los recursos del sistema hasta el límite, generalmente no hay necesidad de una sola solicitud para usar múltiples subprocesos o procesos (hey, dije en general), dado que esos hilos o procesos no obtendrán tiempo de CPU de todos modos debido a la gran cantidad de procesos ya bifurcados por los servidores web. Además de desde la versión 3.3, Python tiene soporte incorporado para la programación asincrónica (o IO sin bloqueo) que limita más o menos el caso de uso de los hilos y, por lo tanto, evita el problema del bloqueo global del intérprete.

3. Escalabilidad del desarrollador

Permítanme citar una frase de Armando Fox, profesor de UC Berkeley y coautor de “Software de ingeniería como servicio” [2]

“Escribimos código para humanos, no para máquinas. Porque de lo contrario estaríamos usando lenguaje ensamblador “

Ahora ciertamente podemos programar en el lenguaje de programación más rápido que existe, y obtendríamos el máximo rendimiento de nuestras máquinas. Pero la verdadera pregunta es, ¿estamos obteniendo el mismo rendimiento de nuestros desarrolladores? El hecho de que la mayoría de la gente no tiene en cuenta al elegir un lenguaje de programación es que los desarrolladores no son gratuitos ni baratos (espero). Por lo tanto, cada hora adicional que un desarrollador dedica a comprender un código críptico le cuesta algo a la organización. Al menos con las empresas medianas y pequeñas, el costo de los empleados es mucho más que el costo del hardware. He trabajado en un portal de trabajo que tenía un equipo de 10 desarrolladores que usaban Python para mantener la misma funcionalidad que un equipo de 60 desarrolladores había realizado para un base de código basado en PHP.

4. Rendimiento

Ahora consideremos el escenario en el que finalmente llegó al punto en el que tiene tantos usuarios de su sitio web, y Python ya no parece satisfacer sus necesidades de rendimiento. Ahora hay una posibilidad razonable de que el problema no sea Python, sino su falta de almacenamiento en caché, consultas no optimizadas o una selección inadecuada de la base de datos. Aún así, si sus tareas están vinculadas a la CPU, o si realmente ha superado las necesidades que Python puede satisfacer, entonces diría “¿Por qué estás tan gruñón, amigo?”. Debería ser un momento de celebración. Su sitio web ya se ha vuelto realmente exitoso para exigir ese tráfico. Ahora puede cambiar fácilmente la base de código de Python con el idioma que elija, sin olvidar nunca que es Python lo que lo trajo aquí en primer lugar.

Tantas respuestas es NO, y ¿quieres saber por qué? Porque si hay una cosa que he aprendido de Ruby, es que “la felicidad del programador cuenta”.

Notas al pie

[1] Donald Knuth – Wikiquote

[2] Software de ingeniería como servicio: un enfoque ágil usando Cloud Computing + $ 10 de crédito AWS, Armando Fox, David Patterson, eBook – Amazon.com

Nunca me arrepiento de nada de lo que aprendí en los últimos 12 años. Ese es el tiempo que llevo trabajando en la industria.

Python puede ser lento y tedioso de usar a veces, pero es un lenguaje prototipo rápido, ideal para probar la funcionalidad antes de implementarlo en otro lenguaje como Java o C ++.

Y siempre fue uno de mis puntos dulces. Puede que no sea el lenguaje más rápido, pero PHP, Ruby y JS tampoco lo son.

La mayor parte del tiempo pasará tiempo optimizando la base de código existente y agregando las nuevas características de forma incremental a medida que se presenten.

Y la mayoría de las veces cuando personalmente encontré el problema con las aplicaciones web, un cuello de botella era el DB.

Web2Py es un pequeño gran marco para aprender y usar. A diferencia de los grandes frameworks como Django, ofrece mucha flexibilidad.

Y al final sigue siendo cuestión de gustos personales.

Aunque me gusta Python para crear prototipos y pegar las partes de software escritas en C ++, para la web usé Ruby, porque fue mi elección.

Pero si toma la ruta Python para aplicaciones web, solo puede aprender algo nuevo y mejorarlo.

Y no creo que te arrepientas 🙂

Desde 2006 hasta 2016, primero Python (hasta 2012) y luego Ruby fueron mis idiomas principales. La abrumadora mayoría de mi experiencia en Python fue con una base de código de un solo programador. Mi experiencia en Ruby es con bases de código multiprogramador que tuvieron cierta rotación en el equipo de desarrollo a lo largo de los años. Me quedé con Ruby porque RSpec es muy superior al estado de la técnica en otros lenguajes de procedimiento y OO. Lo que voy a decir también es cierto (y probablemente más) de JavaScript.

Cuando dice backend, supongo que está hablando de un servicio expuesto a través de algún tipo de API de red. Lo que tengo que decir es válido para algo como un proyecto de Django, pero los pesos relativos de los costos y los beneficios son diferentes y tampoco en un área donde tengo experiencia.

Ruby y Python tienen algunas ventajas importantes para ellos, y la mayoría de estos puntos son bastante convencionales:

• Amplias bibliotecas estándar y bibliotecas de terceros están disponibles.
• Los problemas generalmente se pueden buscar fácilmente en Google o buscar en StackExchange.
• Es fácil comenzar a escribir código y, desde el principio, realizar cambios en la base de código.
• Es fácil mantener el impulso cuando está escribiendo código: no hay un compilador que lo obligue a pensar de antemano, por lo que tiene un ciclo de edición / prueba ajustado. Los lenguajes compilados tienen un ciclo más largo de pensar / editar / descubrir-por qué-esto-no-compilará / editará / compilará / probará. Obtienes gratificación instantánea. Este es en realidad un tema bastante importante con los idiomas: obtienes tu gratificación por adelantado. Sin embargo, como comerse un pastel entero, se odiará en el futuro.
• Te sientes productivo.
• Su código base probablemente será más pequeño que el equivalente en, por ejemplo, Java o C #.

También tienen enormes desventajas si tiene algún tipo de requisitos sobre la calidad del servicio que proporciona la base de código. Estos son los resultados de una experiencia duramente ganada:

• Debe obtener una cobertura del código del 100% para asegurarse de que su código sea correcto “sintácticamente”. No me refiero a una gran invalidez de sintaxis, como parens faltantes o un ‘%’ atascado en algún lugar al que no debería pertenecer. Me refiero a un código bien formado que, sin embargo, es trivialmente incorrecto, como hacer referencia a un nombre de variable con tipografía. Eso no será atrapado excepto en tiempo de ejecución.
• Tienes que escribir pruebas que sean ridículamente minuciosas para minucias. Por ejemplo, supongamos que tiene una estructura de “registro”, implementada utilizando dictos o lo que sea. Digamos que se supone que un campo contiene un número entero y el otro una cadena. Debe escribir pruebas para asegurarse de que no transpuso accidentalmente los campos o lo que sea porque no tiene un sistema de tipos para garantizar la validez estructural de su código.
• Estos lenguajes no son de mano de obra eficiente. Una base de código “robusta” en cualquiera de estos lenguajes, como regla general, tendrá una proporción de pruebas de 3.4 a 1 sobre el código. Las pruebas son más cansado de escribir que el código original en sí, por lo que esto proporciona un límite superior en la eficiencia laboral del código. Pasar el 20% de su tiempo trabajando en problemas valiosos es probablemente optimista a largo plazo.
• A pesar de que no tiene un compilador (significativo) para aplicar la consistencia estructural de su código, aún necesita aplicar la consistencia estructural de su código. Eso eleva el problema de eliminar ideas erróneas del ciclo de edición / compilación / prueba al proceso de revisión del código. Las personas tienden a no reaccionar bien cuando se les dice que su trabajo de la semana pasada debe descartarse y rehacerse. Si escribe documentación para todos estos supuestos pensando que resolverá el problema, lo que sucede en la práctica es que la documentación no es útil o significativa hasta que la persona experimente el problema que la documentación fue escrita para evitar. También volvemos al problema de la eficiencia laboral.
• La integridad de la cobertura de la prueba es ambigua. Sin introducir algo como las pruebas de mutación (que ejecuta su conjunto de pruebas O (S) veces, donde S es el número de expresiones en su base de código y, por lo tanto, lleva mucho tiempo ), no tiene forma de saber que su conjunto de pruebas está completo.
• Incluso si tiene una cobertura del estado de cuenta del 100%, los conjuntos de pruebas son inadecuados para realizar cambios transversales en la base de código. Le dirán que tiene inconsistencias semánticas pero que no serán útiles para señalar las formas sintácticas que están causando los problemas. Es decir, le dirán que su constructor desde hace algunos puntos es incorrecto. No le dirán en su editor que es debido a un error tipográfico que hizo durante un cambio de nombre variable que ahora está tratando de agregar un número y una cadena. Aún necesitas descubrirlo por ti mismo.
• El código se vuelve más difícil de trabajar con el tiempo. Debe tener grandes partes de la estructura del programa en su cabeza para saber qué cambiar, todas esas suposiciones de consistencia estructural de antes. La inadecuación de la documentación se aplica a usted desde el futuro tanto como a otra persona que trabaje en la base de código con usted.

Tengo muchas más ideas para transmitir, pero lo cortaré en este muro de texto. Python es útil si necesita probar un concepto y no le importa la calidad del resultado. Lo mismo para Ruby. Estos idiomas imponen costos sustanciales cuando necesita realizar cambios en los programas escritos en ellos. Cuando llegue al punto en que decida que necesita realizar pruebas unitarias, probablemente sea hora de cambiar a algo más adecuado para mantener la consistencia estructural de su programa mientras lo cambia.

No, no lo son. La gente ha comenzado a buscar nuevos lenguajes que sean mejores para los lenguajes de fondo primarios que Python, pero la mayoría de las veces, cuando se inició el proyecto, los equipos de desarrollo eligen el idioma adecuado dada la experiencia de los desarrolladores y qué idiomas tienen las mejores herramientas para el problema. a mano.

Por ejemplo, tienes Google. Google hizo parte de su trabajo de back-end en Python (y otras partes en C ++, y posiblemente otros lenguajes). Ahora están haciendo más y más en Go. Pero tuvieron que crear Go para resolver sus problemas específicos y satisfacer sus necesidades específicas. No podrían haber usado Go en ese entonces porque aún no lo habían logrado y realmente no sabían lo que necesitaban.

No tengo dudas de que hoy, cuando un equipo tiene que decidir qué idioma usar, no debería elegir Python de antemano, sino que es muy diferente de lamentar lo que se hizo hace 10 años.

Es bastante despreciable tener opiniones “absolutas” sobre los lenguajes de programación. Debería arrepentirse de usar C ++ cuando Python podría haber funcionado bien (es decir, su diseño valora la simplicidad). Por el contrario, debe arrepentirse de usar Python cuando es consciente del rendimiento de su back-end (es decir, prioriza el tiempo de ejecución). Perdón por la respuesta de alto nivel, pero creo que es importante recordar que nunca habrá un idioma absoluto mejor o peor . Debe identificar sus necesidades e implementar en consecuencia.

Como preguntaste, Instagram usa Django de Python considerablemente en su backend. Y no, no creo que se arrepientan de su elección 🙂 A continuación se muestra el enlace de lo que usan.

Lo que impulsa Instagram: cientos de instancias, docenas de tecnologías

No me arrepiento porque no lo hice. Además, NUNCA elegiría Python para ningún proyecto nuevo que fuera grande o que tuviera múltiples programadores.

No me malinterpretes. Hay mucho que me gusta de Python. Es moderno, su sistema OO es limpio y simple, y tiene algunas características verdaderamente vanguardistas como iteradores como objetos de primera clase. Todos esos son admirables y atractivos. Es un excelente lenguaje para principiantes para pequeños programas escritos por una persona. Lo he usado yo mismo para programar un Raspberry Pi 3.

El factor decisivo, para mí, es un pequeño defecto de diseño, es decir, que hace que todas las variables internas de los objetos sean públicamente visibles y escribibles públicamente. En otros lenguajes OO (como Smalltalk), las variables internas son inaccesibles a menos que cree intencionalmente métodos de acceso. Esto hace posible escribir código “a prueba de bombas”, código que se garantiza que funcione como se anuncia, sin importar lo que haga el usuario o cualquier otro programador.

Python hace IMPOSIBLE escribir código a prueba de bombas, POR DISEÑO. Me faltan las palabras para decir cuán ridículamente estúpido y peligroso es eso. Todas las variables internas de los objetos están desprotegidas por defecto y no hay forma de cambiar eso , no hay forma de protegerlas.

En consecuencia, no puede cambiar la estructura de datos interna de NADA sin arriesgarse a romper el programa. Suponga que tiene una clase Vector con variables internas x e y . Después de algunos perfiles, se da cuenta de que la mayor parte del tiempo de CPU del programa se gasta en vectores rotativos, por lo que tendría más sentido usar coordenadas polares y que las variables internas sean r y theta . Si sus variables internas son inaccesibles, puede hacer este cambio rápida y simplemente cambiando la definición de clase y algunos métodos, y se garantiza que todo seguirá funcionando. Pero si no lo están, alguien en algún lugar podría estar sacando el valor x directamente, y su código se romperá.

Supongo que podría usar Python sin definir ninguna clase u objeto, pero las clases integradas aún serían vulnerables.

¿La gente ha comenzado a lamentar haber elegido Python como su principal lenguaje de fondo?

Esto no es para burlarse, sino para aprender de la experiencia. Si la respuesta es sí, me gustaría evitar Python en mi futuro backend. Si no es así, es probable que también comience con Python para mi próximo proyecto.

No he usado Python hasta ahora, pero como conozco a Ruby, que ofrece casi las mismas ventajas y desventajas, creo que estoy calificado para responder esta pregunta.

El objetivo de Python es tener un lenguaje simple de propósito general que le permita desarrollar aplicaciones muy rápido. Entonces, desde la perspectiva de una startup que necesita ser muy flexible al principio para desarrollar una nueva aplicación hasta ahora no probada, Python tiene mucho sentido. Por supuesto, Python también tiene desventajas: el bloqueo global del intérprete, por ejemplo, o la velocidad de ejecución pura. Pero cuando se crea un nuevo producto, generalmente no se alcanza el conjunto problemático de usuarios de manera que esto se convierta en un problema. Más tarde, cuando logró que tuviera éxito con su producto, esto podría cambiar, pero, sinceramente, Python ofrece demasiadas ventajas al principio para verlo como un problema real.

En muchos casos, Python es una opción suficiente, así que si te gusta el idioma, hazlo. Si desea probar una alternativa, verifique si el idioma coincide. Al final del día, un lenguaje de programación es una herramienta. Antes de usar un control de martillo, tiene un clavo frente a usted.

Lamentarse es ninguno si elige Python. Por ejemplo, solo para darle una escala de cosas, YouTube se ejecuta en python. Pero el punto es: debe ser un usuario avanzado de Python y debe conocer las advertencias de las características del lenguaje.

Ejecutamos cosas en Python y personalmente tengo servidores escritos y utilizo algunas aplicaciones internas de alto volumen que funcionan a la perfección con Python.

Explore las características que más le convengan y luego comience a diseñar.

La documentación es muy buena y la ayuda de la comunidad es increíble. Por lo tanto, no hay problema en considerarlo como un idioma primario para diseñar.

La satisfacción del usuario final es el factor más importante en el éxito de un producto. La satisfacción del programador no lo es. Python o Ruby podrían ser buenos para la creación rápida de prototipos, pero ¿por qué no simplemente escribir el backend en algo más escalable como mod_perl o Java o NodeJS en primer lugar? Ninguno de estos es sustancialmente más difícil que Python. Y encontrar un final de línea o un cierre con estos lenguajes es trivial (a diferencia de Python / ROR / Coffeescript).

Aquí hay una ilustración del problema de Global Interpreter Lock Python en un sistema móvil x86 (core m3–7y30). Observe cómo Perl es 6 veces más rápido. Incluso sin hilos, Perl es casi siempre más rápido que Python en mi experiencia.

./thread.py 8 # 46.7 tiempo de ejecución, 360.9 tiempo de ejecución combinado
./thread.pl 8 3 8.6 tiempo de ejecución, 67.8 tiempo de ejecución combinado

El código de Python empeoraría considerablemente si los subprocesos compitieran por recursos limitados y luego los bloquearan, ya que cada bloqueo duraría 6 veces más. Si cada hilo compitiera por un solo recurso, tardaría 36 veces más que Perl. Si competían por dos recursos, ese número aumenta a 216x.

Este tipo de cuello de botella en el rendimiento se traduce en problemas de escalabilidad. Considere, por ejemplo, que algunas soluciones de NodeJS pueden reemplazar 6 servidores Python con una sola caja. Esa es una gran cantidad de costos, mantenimiento y sincronización que simplemente no existe para la solución NodeJS hasta que el tráfico alcanza el umbral 6 veces mayor que el servidor Python. Incluso entonces, estaríamos agregando servidores a 1/6 del ritmo de Python y tendríamos muchos menos problemas de contención de recursos a medida que escalamos.

Lo usé en un proyecto personal que actualmente ronda los 20 KLOC.

He usado otros lenguajes de programación populares y, en conjunto, creo que Python es el mejor lenguaje de programación que existe, si se considera la variedad de bibliotecas, la comunidad y los extras bien documentados y bien mantenidos.

Python tiene literalmente todo lo que pueda desear para construir cualquier cosa. Realmente no se puede decir eso sobre otros idiomas populares.

Estoy respondiendo prácticamente aquí. En realidad, Python no es mi idioma favorito para escribir, pero es difícil encontrar situaciones en las que cometas un grave error al usarlo, y cualquier arrepentimiento que tenga quedaría eclipsado por su practicidad y flexibilidad.

Pregunta original: “¿La gente ha comenzado a lamentar haber elegido Python como su principal lenguaje de fondo?”

He estado usando Python 2.7 durante más de 4 años en un entorno de producción para organizaciones de renombre y startup para resolver problemas de big data. Creo que puedo responder a esta pregunta con cierta autoridad.

Python es un excelente lenguaje de programación para hacer código rápido y sucio a largo plazo. Hay algunas peculiaridades que uno debe tener en cuenta, como GIL, cómo funcionan los tipos, etc., para no caer en el agujero de la rata. No hay tantos para recordar.

También las bibliotecas y los marcos de Python han madurado con el tiempo, lo que hace una inversión sensata. Estos beneficios superarán las preocupaciones sobre el rendimiento de wrt, escale si Python se usa en un entorno adecuado como Hadoop o Spark.

Otro beneficio adicional es que Python también es uno de los idiomas preferidos por los científicos de datos, por lo que es fácil trabajar con ellos y compartir la misma base de código y entorno.

Nunca he usado Python 3, así que no puedo comentarlo. Si tuviera que rehacer algunos de los proyectos: cambiaré muy pocos en Scala u otro lenguaje funcional debido a la naturaleza del problema y los marcos que se ejecutan en JVM.

Python es mi idioma de acceso a menos que sienta que otro lenguaje o marco es más adecuado para el problema.

Sí, lo tengo absolutamente.

Si bien Python el lenguaje es versátil y se presta bien para un desarrollo rápido, el empaquetado de Python es una pesadilla.

En los equipos en los que he trabajado, siempre termino pasando una cantidad excesiva de tiempo trabajando en las idiosincrasias de las herramientas de compilación, empaquetado y despliegue, particularmente en torno a la administración de dependencias nativas y virtualenvs.

Cualquier persona que comience un nuevo proyecto empresarial de Python tendrá que decidir primero si usar pip + virtualenv + make, buildout, Conda u otra cosa. LinkedIn incluso llegó a crear pygradle. Y luego debe hacer que funcione con su infraestructura de compilación y despliegue, lo que significa que todos deben tener la misma versión de Python, el mismo conjunto de dependencias nativas y el mismo conjunto de herramientas. O bien, aísla completamente su entorno con Docker u otra solución en contenedores. Algunos de estos problemas son compartidos por igual por otras plataformas como Java o NodeJS, pero Python exacerba y agrega a estos problemas.

Todavía usaría Python para todos mis proyectos personales en los que no tengo que preocuparme por el soporte del desarrollador o forzar mi código para que se ejecute en la infraestructura corporativa existente, pero ya he decidido que mi próximo trabajo será completamente Basada en Scala. Amazon tomó la decisión correcta al apegarse a Java.

Su pregunta debe aclararse. Hay dos tipos de “arrepentimientos” que pueden ocurrir si elige Python.

1. Eligió un lenguaje dinámico, sin tipo, GIL, en el que, de hecho, debería haber elegido un lenguaje estático de tipo simultáneo.
2. Elegiste Python sobre sus alternativas JavaScript y Ruby.

Como arquitecto, si eligió Python pero debería haber elegido un lenguaje basado en JVM, lenguaje basado en LLVM, lenguaje basado en .NET CLR, Go, C / C ++, Rust, etc., entonces la verdadera pregunta que desea responder es “Tener la gente comenzó a arrepentirse de haber elegido un lenguaje de programación dinámico y no concurrente como su principal lenguaje de fondo ”. Sin embargo, si elige Python pero lamenta no haber elegido JavaScript o Ruby, entonces es justo hacer la pregunta que hizo.

La mayoría de las respuestas aquí se refieren al n. ° 1, por lo tanto, el “problema” aquí no es Python como lenguaje sino el tipo de lenguaje que representa.

No hay un lenguaje verdadero. Ese es un error de principiante. Elija el idioma según los requisitos, objetivos y limitaciones del proyecto. No intente ajustar todos los proyectos en un solo cuadro de idioma.

Python es una excelente opción para algunos proyectos y un desastre para otros. Lo mismo es cierto para cualquier idioma. SO o arquitectura.

Si tiene interés en trabajar como desarrollador a largo plazo, debe aprender a identificar las características de un proyecto que definen una herramienta adecuada. Espere aprender muchas herramientas a lo largo de su carrera. Nunca debe arrepentirse de aprender una herramienta si le enseña nuevas habilidades y satisface una necesidad, incluso si esa necesidad es simplemente aprender algo diferente. Mi opinión de todos modos.

Esta es una pregunta peculiar … ¿Qué amigos? Que proyectos También podría preguntar: “¿La gente ha comenzado a arrepentirse de comer pastel de chocolate?” Algunas personas sin duda se arrepienten, otras, por otro lado, están contentas de haber elegido Python. El lenguaje para el back-end depende de muchas restricciones que varían de un proyecto a otro. Estos incluirán el tamaño del proyecto, el tamaño del equipo, las limitaciones de tiempo real / escalabilidad, la experiencia previa del equipo, etc. Python está bien para proyectos pequeños, especialmente cuando el equipo también es pequeño y la velocidad de procesamiento sin procesar no es un factor. Mucha gente se queja de la falta de tipos de Python, pero en la práctica en un proyecto pequeño puede determinar fácilmente el tipo deseado según el contexto. Tengo un pequeño programa de base de datos escrito en Python con PyQt4 y Sqlite3, excluyendo el código generado automáticamente (de PyQt4). He escrito alrededor de 2000 líneas de código, y no tengo problemas para entenderlo o extenderlo. Con 20000 líneas, podría ser una historia diferente. Y si esas 20000 líneas se dividieran entre un equipo de 10 personas, entonces Python podría no ser la mejor opción. Si tuviera que cumplir con las restricciones en tiempo real, de modo que los retrasos introducidos por un recolector de basura fueran intolerables, entonces Python podría no ser la mejor opción. Pero si desea crear un prototipo de una idea y hacer que algo funcione rápidamente, entonces Python es excelente.

Use la herramienta adecuada para el trabajo.

¿Python suena, por supuesto, como el adecuado para el próximo proyecto? Si la respuesta es sí, entonces adelante.

No hay una respuesta universal a esa pregunta, las personas se centran en uno u otro idioma por varias razones, ya sea su preferencia personal, requisitos de trabajo, influencia de su entorno, estrategia de la empresa, amor / odio en Internet, comunidades sesgadas, lo que sea.

No hay tecnología malvada de la que uno pueda mantenerse alejado a toda costa. Puede cometer un error al elegir una tecnología / lenguaje incorrecto que no resolverá (correctamente) algún problema en particular, pero esa no es la razón para odiarlo o descartarlo por completo.

Sin ningún detalle sobre sus próximos proyectos, nadie en la tierra puede decirle con certeza si Python (o cualquier otra cosa) es bueno o no para ello. Yo mismo ni siquiera conozco Python (nunca tuve la necesidad de concentrarme en él, excepto algún interés general), pero sería bastante inútil sugerir mi pila; de lo contrario, sería solo otra opinión sesgada en Internet.

He trabajado en muchos proyectos a lo largo de los años en C, C ++, Java, PHP, Python, Perl, node.js, VB y probablemente algunos que he olvidado. Lo que puedo decir con certeza es que cada uno de esos proyectos ha tenido momentos en los que lamentamos la elección de la tecnología. Cada vez que elige una tecnología que conlleva ventajas y desventajas, ninguna de ellas es perfecta.

Si trabaja en un proyecto el tiempo suficiente, eventualmente se encontrará con algo que golpea el punto débil en la tecnología elegida y habrá un montón de retorcimientos de manos, santurronería, le dije y declaraciones sobre cómo no tendríamos este problema si había elegido ____. Si bien eso podría ser cierto, habría tenido algún otro problema que hubiera sido igualmente preocupante.

En pocas palabras, cuando esté considerando qué usar, reúna tanta información como sea posible, piense cuidadosamente sobre los pros y los contras de todas las tecnologías disponibles y tome la mejor decisión que pueda. Después de eso, haz lo mejor que puedas. No pienses en lo emocionado que estás de haber tomado la decisión correcta o en lo triste que estás de haber tomado la decisión incorrecta. Es una certeza absoluta que habrá ocasiones en que la elección se verá brillante y en ocasiones se verá estúpida.

¡Diablos no! Trabajo con GIL sin problemas gracias a algunas bibliotecas avanzadas en Python 3. Lo que le falta en rendimiento puro está más que compensado por mi capacidad para producir código rápidamente que también es legible.

Además, el rendimiento no es realmente un problema gracias a la arquitectura de microservicio nativa de la nube en estos días. La extensibilidad del lenguaje a través de proyectos comunitarios hace que sea fácil para mí saltar a cualquier ámbito, ya sea ciencia de datos, desarrollo web o scripting de pegamento.

Aquí está la cosa, sin embargo … nadie elige un idioma. Estoy muy contento de conocer Python profundamente, pero no es la herramienta adecuada para cada trabajo. Nadie debería tener un solo idioma “primario”. Python es absolutamente un excelente lugar para comenzar.