Por qué usar Python en vez de Javascript para aplicaciones financieras?

#1

Con un cliente estamos evaluando un cambio en el stack tecnológico para pasar de lenguajes y plataformas propietarias (Oracle y PL/SQL) a OSS.

Hoy ya tienen una cierta cantidad de desarrollos en Javascript, pero en aplicaciones no-financieras.

Lo que se está evaluando ahora es qué lenguajes y frameworks utilizar para el cómputo de datos. Ej. levantar datos de varias tablas y calcular el resultado del ejercicio o determinar impuestos o calcular intereses o etc.

Hay una posición que sostiene utilizar también Javascript para ese caso de uso, para aprovechar que ya hay desarrolladores en el equipo.

Yo quisiera hacer de “abogado de Python” e impulsar su adopción para ese tipo de procesos.

Como siempre casi todo se puede hacer en cualquier lenguaje que sea “turing-complete”, pero quisiera aportar argumentos de peso a favor de la conveniencia o practicidad de usar Python.

Sobre todos aquellos que puedan interesarle a un manager.

Me dan una mano?

#2

Yo iría por el lado de “no hay un tipo de dato para manejar dinero en JS” (podés ver acá el detalle).

Claro, hay hacks y workarounds, pero como decís “eventualmente todo sirve para todo”, así que el foco lo haría en “qué lenguaje está más preparado y te va a traer menos dolores de cabeza”.

Saludos.

1 me gusta
#3

El otro argumento que tenes es que Python tiene librerias muy potentes para manejo de datos, analisis financiero, big data, machine learning, etc. Y javascript (y sus derivados como Node o react) estan mas diseñados para frontend y no para manejo de datos.

Igual podes decirles de hacer backend (con procesamiento) en python y front end (para mostrar la info ya procesada) con react/javascript.

Saludos,

Javier

2 Me gusta
#4

Gracias @facundo @javiermarcon

Ya me dieron un poco más de letra. A ver cómo me va :crossed_fingers:

#5

Me falto agregar que Django es excelente para hacer apps web (backend
sobre todo) y hay muchas paginas groxas hechas con Django (como
instagram por ejemplo). Y si te fijas históricamente los avisos de
empleo de los bancos, vas a ver muchas posiciones de Python pedidas
precisamente porque es uno de los leguajes más usados en finanzas (y en
la comunidad científica también).

#6

Objetivamente hablando, Javascript SI tiene un tipo de datos nativo para manejo de nros decimales grandes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt .

Y, también, aunque esté originalmente pensado para frontend, desde que hay criptomonedas, hay mil librerias para cuestiones financieras y de manejo de nros. grandes y con decimales.

Para mí la ventaja de python es que los datos no se convierten automagicamente entre un tipo y otro…
y si tuviera que forzosamente utilizar node, eligiría typescript que me da un poco mas de seguridad en algunas cosas de ese índole.

Saludos!

#7

hola buenas,

imagino que ya te decidiste.

el gran tema con JS es que por mas que uses alguna biblioteca o solucion de manejo de numeros de punto fijo, en Python tenes Decimal que te salva la vida.

es mas si lo vas a hacer en JS, te diria que lo hagan en TypeScript que si tiene chequeo de tipos

trabajo en una entidad “financiera”, bueno técnicamente nuestros clientes son los bancos, desde emision y captura de tarjetas de credito, una red de ATM, un gateway de pagos, etc, etc, etc.

y en el mismo se migraron varios sistemas a python mas que nada porque nos daba seguridad de que no había perdida de dinero en el medio por conversiones magicas.

si bien el core principal esta en COBOL/HOST y Java/JBoss, Python viene creciendo mucho para muchas actividades.

y sobre todo es facil encontrar programadores Python y reentrenar la existente.

#8

gracias Gustavo.

por mi parte sí, me parece más natural Python que JS para este caso de uso. Al que necesitaba convencer es al cliente, que todavía está dudando.

Si llegaras a tener unos minutos me gustaría hablar un toque sobre librerías y arquitectura en este tipo de aplicaciones.

Saludos!

#9

perdon el cuelgue, pero muchas implementaciones antes del freeze de fin de año :slight_smile:

mucho no puedo hablar sobre la arquitectura debido al NDA que tengo firmado.

pero por arriba.

Python 3.8 puro, solo pocas bibliotecas, a nivel general python-dateutil nos salvo la vida con los cálculos de fechas.

Despues en algunos modulos el de reportlab para generar PDF (mas feo que a proposito IMHO)

La idea es que son N módulos cual microservicios que leen y escriben archivos, en caso de que haya info en BD es solo para configuración, se lee al principio de la ejecución.

El porque de esto se basa en que procesamos archivos con cientos de millones de líneas y se complicaría usar todo en BD.

además que por una buena estrategia de loggeo sabemos que paso y donde paso en caso de algún reclamo

un ultimo comentario logramos que nos aprueben sacar una funcionalidad CORE del negocio de Mainframe/COBOL a Python/AWS, cerro por todos lados.

asi que el año que viene me divertire con esto :slight_smile:

pd: mi mail es lu6avm en gmail