Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




PaCoX

asin: del verbo aser. Ej: lo he hecho *asin e ya
sin: lo que no tienen que llevar las &cervezas

2
MTX_Anubis

#35394 Si alguien no sabe la diferencia entre ocurrencia y paralelismo va mal.

Voy a caer en el bait de desu: Asíncrono no tiene nada que ver con paralelo, al igual que concurrente. Dos tareas, funciones o como quieras llamarlo, concurrentes pueden ejecutarse a la vez una en cada core (paralelo) o no, suspendiendo la ejecución de una para dar paso a la otra y así.

De hecho el problema de los mutex que hablabamos el otro día es que te cargas el paralelismo para hacerlo simplemente concurrente porque metes dependencias entre tareas así que una va a tener que esperar a que otra termine. Además a nivel de switch de contextos y demás es bastante costoso.

Async es que simplemente haces un deferred a la ejecución de la terea y dejas al engine su gestión. Y esto no lo sé pero estoy seguro que async/await en la V8 se utiliza para generar grafos internos de dependencias entre promesas y darle un orden a la ejecución. Quizá @desu lo sepa mejor.

1 respuesta
aren-pulid0

@desu segun esto hacen un gateway por dominio con graphql que es consumido por el aggregator https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2

Para hacer el RPV esta aqui:

spoiler

Esta bastante guay, eso si menuda complejidad tienen montada ahi dentro

1 respuesta
desu

#35402 no lo se mejor. lo se. no te quiero insultar, no eres uno de los targets habituales.

pero el async no tiene nada que ver con el scheduler. el scheduler esta por encima del async. precisamente ahi esta el error que comete la gente y por eso te sale hablar de paralelismo.

para explicar async tansolo hay que explicar que la diferencia con una funcion "normal"...

que cojones tendra que ver el entorno de ejecucion? es como explicar la diferencia entre un int y un []int y empezar a hablar de un patron de dis;eo que los usa. y la gente normalmente tambien suele explicar mal el patron de dise;o, porque ni sabe como funciona async, ni sabe como funciona un scheduler.

#35403 mucha sobre ingenieria que no vale para mucho.

el problema es que los pferos siempre haceis esto sin pensar en que cojones haceis:

FooController => FooService => FooRepository => FooTable
BarController => BarService => BarRepository => BarTable

xq normalizas? xq no escribes codigo para resopdner a tu caso de uso?

el fpero medio no tiene cerebro para estar en contra del status quo de patrones de dise;o que le han ense;ado en su bootcamp de mierda.

2 respuestas
MTX_Anubis

#35404 Bueno en el último párrafo me he colado porque realmente estaba pensando en JS.

Comenta como funciona la V8 en este tema.

1 respuesta
Kaledros

Pues yo tengo interés genuino en esa explicación de async, que todo son páginas que te enseñan a implementar soluciones pero no te lo explican.

r2d2rigo

Vaya ahora la estrategia de desu es "nah hoy no estoy inspirado, que os lo explique otro" para no dejar en evidencia que no tiene ni puta idea.

Por lo menos ya se ha cansado de hacer el ridiculo, vamos viendo algo de progreso.

1 respuesta
desu
#35405MTX_Anubis:

Comenta como funciona la V8 en este tema.

no se las diferencias entre todos los compiladores/runtimes. yo entiendo que todos son iguales o muy parecidos. lo que cambia es como estan representados en el compilador y los metadatos asociados. yo se como va en go, rust, zig, e imagino otros basados en c/cpp/java/c# por extension sera parecido pero con cosas mal hechas por ser lenguajes deprecated. que al final se reducen en compiladores menos potentes, menos eficientes, mas dificiles de escribir, problemas de inferencia.. el tema de tener funciones coloreadas... optimizaciones... problemas al pasarlo por la LLVM

no creo que haya muchas diferencias mas alla de comptime la verdad. aqui si que me pillas porque yo solo he hecho el scheduler no el compilador. y en runtime pues lo mismo... que los tipos sean valores por ejemplo te puede servir... es que es mas dise;o de un lenguaje que no el tema de async en si.

#35407 estoy esperando a un tontito como tu.

que lo explique y haga el ridiculo habitual.

hacerme unos HAHAHAHAHAs

se que no tienes ni puta idea y ahora estas cohibido, por eso me tiras el bait para que te lo explique, pero hoy estoy un nivel por encima de lo habitual.

me he levantado con +150IQ en lugar de los 145IQ habituales.

lo puedo explicar en 4 frases.

2 respuestas
r2d2rigo

#35408 tranquilo chico, llevo usando async/await exactamente 10 años, a mi no tienes que explicarme nada.

1 respuesta
desu

#35409 HAHAHAHAHHAHAHAHAHHAHAHAHAHAHAHAHAH

cavando tu propia tumba

10 a;os usando algo que no entiendes

como cuando te pusiste a explicar como funcionaba una cosa del compilador de C# y te puse un video de Anders Hejlsberg explicando como eso funcionaba distinto a lo que decias

1 respuesta
TitoBurns

Hagan sus apuestas! Quien ganara este apasionante combate?

aren-pulid0
#35404desu:

FooController => FooService => FooRepository => FooTable
BarController => BarService => BarRepository => BarTable

que quieres decir con codigo para responder a tu caso de uso? en las aplicaciones fperitas CRUD lo veo bastante util

ense;ame maestro

1 respuesta
eondev

#35397 tú eres gilipollas así sin más. Ni puta idea de lo que hablas. Alonso es la leyenda viva por encima de cualquier otro piloto actual.

En otro orden de cosas, @desu tampoco , aunque acierta 100% en la descripción de los influencers del siglo XXI para los average devs.

Mi opinión es bastante sencilla y directa, estás en el top 0.99999% si no sigues ninguno de esos imbéciles por convicción propia, tengas conocimientos o no de la carrera.
Yo quiero creer que si desu hubiese hecho un FP no habría terminado consumiendo a mouresdev ese y la tipa del escote de instagram como ahora hace con sus x10 idols engineers.

1
Soltrac

#35408 Estás deseando que te comamos el culo y te pidamos que lo expliques en 4 frases. Narcicista de manual xDDDD.

Venga porfi porfi porfi porfi porfi porfi porfi

1 1 respuesta
desu

#35412 existen casos de uso en entornos de heavy read donde es mejor no normalizar. o casos donde importa la performance y quieres devolver las cosas rapido. no computar cosas mil veces duplicadas etc

la gente siempre empieza haciendo algo OOP, hace HTTP "rest" donde tiene un /foo endpoint, porque tiene un objeto foo conceputal, que le hace get,post,put,delete para modificarlo y eso va del controller a la tabla. esto es algo OOP por dentro en tu servicio. y ese es el flujo de casi todos los CRUDs. es facil de entender. es escalable. cubre casi todo lo que queiras a base de hacer mas trabajo.

el fpero medio le faltan las neurononas para pensar. tiene muchos beneficios. performance no es uno de ellos. y hay muchos casos de uso de tu dia a dia que podrias resolver directamente en backend. la mayoria de cosas, sino todas, que hace la gente sobre sus cruds lo pueden resolver en una query de SQL directamente. pues porque no a;ades un endpoint para ello y fuera?

si tienes 10 casos de uso, puedes tener 10 endpoints. existen muchos CRUDs que son mas faciles tenerlos asi... rollo RPC que HTTP expoinendo entidades.

esta idea seria la base de las db columanres, orientadas a timeseries, new sql etc etc etc. haces una DB optimizada para tu caso de uso.

te puede parecer una idea rara el no tener el CRUD exponiendo tus entidades, pero si te paras a pensar en los casos de uso de tus usarios de tus apps... te aseguro que la mayoria de backends serian mas faciles de escribir y mantener siguiendo un estilo de endpoint = funcionalidad.

#35414 para mi explicar la cosa a ni;os peque;os o tontitos es una manera de ponerme a prueba

como hacia feynman

si tu un fpero que no sabe lo que es un puntero entiende mi explicacion, es que yo soy bueno explicando

porque yo ya tengo los conocimientos, lo importante ahora es transmitirlos

1 respuesta
Soltrac

#35415 Hoy me he levantado con +155IQ. Me suda los cojones.

3
PaCoX

si estas por debajo de 200 de iq eres un fpero

r2d2rigo

#35410 👍

Kaledros

Al final me quedo sin saber lo del async, tócate los cojones, dos páginas de gente haciendo un Gila ("alguien es muy bueno", "alguien es muy malo") pero aquí nadie tira el triunfo sobre la mesa. Muy mal.

2 respuestas
B

#35419 pero aquí no sabemos de nada, ni de programación ni de deportes, al menos de F1 si no mírate a ti y al pythonero de @eondev

Menos mal que Fernando Alonso no es alemán, si no te acusaría de patriotismo

MTX_Anubis

#35419 pero que quieres saber exactamente de async? Una función asíncrona es basicamente una función no bloqueante (que no quiere decir que sea paralela) y en cada lenguaje se puede hacer de formas distintas.

1 respuesta
Kaledros

#35421 Esa parte la sé, he trabajado con Reactor en Java y sé usar funciones asíncronas en JS, pero parecía que desu iba a explicar cómo funciona por debajo y cómo se relaciona con el scheduler y tal. Vamos, que sé usarlas pero no sé cómo hacen lo que hacen. Que por cierto es algo que quiero aprender ahora en el paro, así que me viene bien.

2 respuestas
eondev

#35422 mirate el esquema de un event loop o un reactor y au, no hace falta rascar más

desu

#35422 es cuestion de terminologia. si una funcion es una rutina/subrutina, una async es una corrutina.

En el main tienes la stack principal. Y el espacio de memoria alocado para ejecutar una funcion donde pones las variables locales y los parametros es el stack frame. En el stack tienes variables y stack frames de las funciones ejecutándose.

cuando haces return tiras el stackframe del stack del main. pierdes las variables locales de esa funcion.

en las corutinas puedes suspender la ejecucion, devuelves el control a donde estabas pero sin hacer pop. esto es una funcion async.

1 main () {
2   foo()
3 }
4 foo() {
5   suspend 
6 }

para poder volver a esa funcion se usa el famoso "async", que nos devuelve un puntero al stackframe de la corutina. asi desde main puedes volver a donde estabas. Que esto solo es convención, el nombre y lo que devuelve. Puede ser lo que quieras.

1 main () {
2   f = async foo()
3   resume f()
4 }
5 foo() {
6   suspend 
7   return 10
8 }
  1. Empiezas cargando el main en LOC 1.
  2. En tu stack tienes la linea de ejecucion y las variables del main y los frames...
  3. En LOC 2 invocas foo(), y te guardas el puntero al frame.
  4. Estas en LOC 6 dentro del stackfram de foo(), ahi haces un suspend y devuelves al ejecucion sin hacer pop del frame.
  5. Estas en LOC 3, ahi haces resume del frame.
  6. Estas en LOC 7, ahora haces return del 10 y haces pop del frame.
  7. Ahora estas en LOC 4, ahi si te hubieses guardado el valor pues lo podrias usar normal... no es mas que otra variable en tu stack.

No hay ningun secreto. Podrias tener una variable global e ir modificandola desde una corutina asi:

1 var global = 0
2 main () {
3   f = foo()
4   while (global != 3) {
5     resume f
6  }
7 foo() {
8   global++
9 }

Luego tienes el keyword await. Que lo que hace es esperar en el main en lugar de seguir la ejecucion... No tiene ningun secreto... en lugar de seguir el codigo espera a que el frame haga return...

Luego porque necesitas que las cosas async vayan con async y hay cosas que no pueden serlo como el main? Pues porque si estas modificando memoria y el codigo se va ejecutando llegara puntos donde estas apuntado a variables no inicializadas, si no haces await y ejecutas el codigo de antes del foo() que devolvia 2 al final. que pasa? pues que te printara lo que sea que tenga en memoria para el stack o puntero. algunas cosas el compilador te las detecta como usar el stack, pero si tienes un puntero no inciializado esperando un valor te printara basura.

Y al final pues como peudes ver solo son punteros para ejecutar las cosas y corutinas. Si tu quieres aqui ejecutarlo en un thread o en otro thread... tener un scheduler inteligente que te haga las cosas o de prioridades... pues haz lo que quieras fpero. Es que el paralelismo no tiene nada que ver con las corutinas XD

La convención de los keywords pues es para que los compiladores detecten fallos. No hay mucho más.

2 2 respuestas
JuAn4k4

#35424 En el fondo no se diferencia mucho de llamar a una función/método, en cuanto a stack/puntero. La diferencia principal es que se ejecuta en otro thread (normalmente) y que lo controla el cpu scheduler al sacarte en el suspend. Luego está la mierda de necesitar el mismo thread principal para poder hacer ciertas cosas y la cosa se complica un poco, con posibles deadlocks que tenía c# por ejemplo con el ConfigureAwait.

1 1 respuesta
desu

#35425 no es cierto

Ejecutar en otro thead y tener un scheduler no tiene nada que ver.

La corruitna se suspende y puede seguir.
La función hace return.

todos mis ejemplos de arriba son en el mismo thread... no hay ningun scheduler mas alla del OS. y es async...

decir que la diferencia entre una funcion es que se ejecuta en otro thread es mentira. yo puedo ejecutar una FUNCION en otro thread sin problema... no tiene porque ser async... o puedo ejeuctar todo en el mismo ... y el scheduler lo mismo. es que no tiene nada que ver ni existe ninguna correlacion o conclusion o lo que sea que esteis tratando de decir. no tiene sentido ninguno.

hipotesis: la diferencia es que se ejecuta en otro thread
refutacion: una funcion tambien se puede ejecutar en otro thread

voy a subir el 99% al 99.9%. 1 de cada 1000 usuarios de este hilo.

en rust:

fn main() {
    thread::spawn(|| {
            println!("hi from the spawned thread!");
        }
    });
}

vs

fn main() {
    thread::spawn(async || {
            println!("hi from the spawned thread!");
        }
    });
}

no tiene sentido tener una async que no suspende XD pero me da pereza hacer un ejemplo real. se entiende.

Edit: refutación mejor, async también puede ser el mismo thread. XD tiene más sentido como refutación a lo de arriba.

Pero hay mucha gente que cree que async es un nuevo thread siempre y función no. En plan java y go he leído gente así de tontita.

2 respuestas
B

Los que usáis el git desde la consola en lugar de hacerlo desde el IntelliJ ¿vuestros padres os querían?

3 respuestas
Leos

#35427 Somos fperos, nadie nos quiere

1
Frave

#35427 A mi me gusta mas usar el gui de vscode, debo ser batman.

1 respuesta
B

#35429 VS Code, detector de pajeets, aunque menos detector que los que usan git en consola