Feda /dev/ - No Javascript allowed

Quién hace un CRM con go? Jaja qué putos colgaos

Experience dealing with high traffic applications (1M+ requests per day) is a must

#53401 capear el temporal y no desanimarse, poco más se puede decir; es una lotería.

#53402

Quién hace un CRM con go? Jaja qué putos colgaos

Why not?

Experience dealing with high traffic applications (1M+ requests per day) is a must

No me parece mal requerimiento, mantener una app usada por GENTE no 4 pacos tiene sus retos

#53404 los crm son rule heavy y el lenguaje apenas tiene constructos semánticos que te ayuden a sintetizar un poco las cosas (blah blah syntax sugar blah blah pajeet en HK soy libre). Inviertes mucho tiempo con cosas tontas de infra que ya están resueltas hace años; es como picártelo en java 6. Also lol no generics. Lo puedes dejar como mi cruzada en contra del nuevo node pero lo veo bastante absurdo sobre todo porque normalmente la gente escoge go por moda pero lo enmascara con performance... será que en la jvm no tienes micro frameworks http que te van a hacer lo mismo a cambio de 100mb más de ram en el pod que a nadie le van ni le vienen.

Igual que para las cripto que todo el mundo usa rust porque no pueden mover más de 5 transacciones por segundo y necesitan invocar al dios de la performance mediante sacrificios rituales con sangre de virgen (aka el dev de turno que aún no ha mojado el pincelín).

#53404aren-pulid0:

mantener una app usada por GENTE

Lo de usar las requests como métrica es un poco absurdo porque no sabes realmente qué implicaciones tiene pero vamos a asumir que son requests que entran de usuario en el sistema/servicio core que es una forma algo safe de interpretarlo. Independientemente del fan-out que tengas hacia otros servicios es un número ridículo.

Vamos a asumir que en 24h sólo tienen el servicio activo 3h y las 21 horas restantes está apagado, eso es 1_000_000/(3*3600) = 92 req/s eso tiene lo mismo de high traffic que yo de atleta de élite. Que un 1M lo tengo yo en una hora y mi curro lo hace cualquier pordiosero mental (para muestra recordar que lo estoy haciendo yo, así que hipótesis validada check mate git gud).

#53406

los crm son rule heavy y el lenguaje apenas tiene constructos semánticos que te ayuden a sintetizar un poco las cosas (blah blah syntax sugar blah blah pajeet en HK soy libre). Inviertes mucho tiempo con cosas tontas de infra que ya están resueltas hace años; es como picártelo en java 6. Also lol no generics

tonterías, por cierto sí tiene generics. Ahora soy un Gopher, hdp, así que a ver que dices

Que un 1M lo tengo yo en una hora

Cierto, 1M req al día es basura, mínimo 1M req cada 5'. De todas maneras te sorprenderías la de gente que construye software que no usa NADIE

#53409Wei-Yu:

Dime un motivo por el cual usar go en vez de un microframework de java, nestjs o c#

Es infinitamente más simple y no tiene absolutamente nada de boilerplate. Por lo demás, a elección del consumidor.

#53409 nestJs es un framework fyi

#53411 El problema es qué encuentras xD

P.D Deberíais pasar más tiempo aprendiendo a usar un lenguaje que a despotricar de todos lo que existen

#53413 te puedo poner un ejemplo de ioc en c# y otro en go, con eso me vale. Si la app tiene la complejidad en otro sitio pues go puede ser buena herramienta, pero un crm que es feature rich me parece que se va a beneficiar mucho de patrones battle tested como ese...

De la misma forma que las libs y el ecosistema gira todo en torno en conceptos a mucho más alto nivel. No quiero reinventar la rueda 300 veces y cuanto menos código no relevante para la feature tenga que picar mejor.

Para mí esto es el webscale de node de hace 15 años otra vez más. Que si boilerplate, elegencia, bloat, entreprise cucks y otras mierdas sin sentido.

#53414 y un microframework de la jvm es un framework también

Imagina ir all in con Go porque tienes la fe de que va a seguir vivo en 5 años.

#53425 Que si un lenguaje se usa en un proyecto tocho, y además reciente, es porque no va a ir a ninguna parte.