Feda /dev/ - No Javascript allowed

Estoy en contacto con Miriam Gonazalez para colaboradora:

No nos ponemos de acuerdo con la clausula en la que debe pasarme fotos de sus pies.

Seguiremos informando desde el equipo tecnico del stream(marca registrada pertenenciente al blog(marca registrada))

ya os digo que el contenido sera lo contrario a esto

mejor aun

seguramente sera refutar estas bobadas

madre mia 1,2k likes y los comentarios del hilo..........

cuanto tardaran en banearme de twitch? me tendre que estudiar bien el reglamento ..

#23728 Me he mirado un rato akka ahora y no lo recomiendo nada.

Tiene un API java enterprise horripilante.

Rust no quiero usarlo porque el async esta tambien hecho como el culo, es uno de sus grandes errores por lo que he leido, lo han rusheado.

Me queda elixir... ahora le hecho un ojo por curiosidad a ver si es muy chungo la sintaxis.

Sino lo haria haciendo CSP en lugar de actores y usaria golang.

Si hago CSP puedo tener un webserver normal que reciba las peticiones, para no bloquear el writer que seria a su vez un listener del webserver, creo una gorutina que hace handle. (nse si en go hay una manera facil de hacer esto, de cabeza creo que no es automatico sino que usa 1 request = 1 thread no?). dentro de esta gorutina escribo en el channel, si se bloquea me da igual. luego tengo una lista de workers que esta leyendo del chanel las entradas. el numero de workers lo podriamos controlar dinamicamente con algun algoritmo de balanceo (cuantos mas peticiones en un interval de tiempo peque;o le meto mas workers que consuman de la cola). o sino podriamos tener multiples colas si sabemos un numero de workers y writers que tiene sentido y no hara bottleneck de ninguna manera (mas o menos, una aproximacion valida para la mayoria de casos). lo importante aqui al ser csp (igual en actores) es que los mensajes serian transacciones/eventos/comands (no se cual es la palabra tecnica correcta), y van timestampeados, de esta manera sabemos como ordenarlos conforme los vamos procesando. tambien tendriamos que meterle aqui algo para asegurar que no hay doble consume de las transacciones. cuando algo se procesa y se commitea se marcaria la entrada en persistencia como toca.

falta algo?

a mi personalmente me gusta mas tener procesos anonimos como en CSP, pero me molaria que fuera escritura async como en actores, imagino que si escribes en un buffer no tendras problemas a priori. asique de momento me inclinaria por un csp en golang vs akka/rust. obviamente, veo que si tengo actores el recovery quizas es mas facil, aqui es donde elixir entiendo que brillaria, aunque en el caso este de entradas ... me suda tres huevos. si falla un actor lo siento, mala suerte. habria que ver el rate de fallo... en lo personal, me suda los huevos si el sistema no es justo.

#23755 Es algo conocido y en time series pasa mucho el data leakage xD

@desu , stream hoy?