La programación concurrente suscita mucho interés entre los programadores que desarrollan aplicaciones para la nube o como servicio (SaaS, Software as a Service) por lo que terminan recurriendo a lenguajes como Go, Elixir o Erlang. Si te interesan más estos temas consideramos oportuno recomendaros los siguientes libros de Altenwald: Erlang/OTP Volumen I: Un Mundo Concurrente altenwald.com/erlang-i Elixir: Introdución para Alquimistas altenwald.com/book/elixir Phoenix Framework: Proyecto de Red Social en 7 días altenwald.com/phoenix-framework
De seguro que ya sabes que la programación se trata casi siempre de forma secuencial y cuando se menciona el trabajo con diferentes procesos/hilos/hebras/rutinas/... los programadores piensan en paralelización pero muy pocas veces en concurrencia. El cambio de paradigma que supone ir de sencuencial a concurrente fue problemático porque no concebían la programación concurrente como una forma de estructurar mejor el código en diferentes secciones trabajando entre sí. Es un tema muy interesante y de seguro en altenwald.com puedes encontrar mucha más información. Gracias por tu comentario!
Cierto, el personaje de los primeros 10 segundos del vídeo parece Henry Cavill :-D nos alegra que hayas aprendido algo nuevo. Gracias por tu comentario!
Una lástima que varios programas no son capaces de usar todos los núcleos al unísono, siendo que no se puede aumentar la velocidad de los núcleos individuales y aveces es indistinto tener 4 o 20 núcleos disponibles. Tambien cabe destacar que no toda la velocidad mononucleo se basa en su relojeo ya que el ipc también tiene influencia
Totalmente de acuerdo, al mantener los núcleos con elementos compartidos tienen la limitación de que deben "pedir turno" para acceder a ciertos elementos como la memoria (solo hay un BUS) y por eso el esquema de concurrencia propuesto por Go fue tan novedoso... y los gophers trabajan bien juntos. Gracias por el comentario y la puntualización.
Gracias por el comentario y el cumplido, esperamos seguir viéndote por los comentarios y que sigas disfrutando de los otros y siguientes vídeos. Saludos.
Interesantísimo el video! me ha gustado entender un poco más los dispositivos que manejamos hoy, no tenía ni idea de que es la concurrencia y ahora es un tema que me interesa mucho
Nos alegra que además de traer un poco del contexto histórico de las cosas, los temas susciten interés. En programación, la concurrencia es un tema muy empleado en lenguajes como Erlang, Elixir o Go, son los principales, altenwald.com suele publicar libros de estos temas para aprender programación por si son de tu interés. Gracias por tu comentario.
En realidad hay otras razones por las que un pc no es mas rápido mas allá de la velocidad del cpu y es que el verdadero cuello de botella es la velocidad de la memoria ram muchísimo mas lenta que el cpu y la velocidad aun mas lenta de las unidades de almacenamiento, esto provoca una latencia intrínseca que lograron parchear usando las memorias cache, aunque solo parcialmente. Lo otro es que software desde hace años tiene tendencia inflarse y volverse más lerdo, lento y pesado es la contrapartida a la ley de Moore: la Ley de Page y la Ley de Wirth, da igual el incremento en potencia si el consumo en vicio de los programas incrementa proporcionalmente a una escala superior al aumento de la potencia de hardware, y esto es así porque desde hace años se usan (compiladores) en lugar de escribir directamente los programas para se ejecuten sobre hardware (ensamblador) verdaderas montañas de parches sobre parches, código huérfano y complejidad que consume recursos, lo otro es que tarde o temprano las desarrolladoras intel, amd, arm, etc, llegaran finalmente al tope del limite económico donde los equipos y los procesos de fabricación se toparan con un aumento exponencial de los costos y una mayor tasa de fallos a medida que llegan a los limites miniaturización.
La programación concurrente suscita mucho interés entre los programadores que desarrollan aplicaciones para la nube o como servicio (SaaS, Software as a Service) por lo que terminan recurriendo a lenguajes como Go, Elixir o Erlang. Si te interesan más estos temas consideramos oportuno recomendaros los siguientes libros de Altenwald:
Erlang/OTP Volumen I: Un Mundo Concurrente
altenwald.com/erlang-i
Elixir: Introdución para Alquimistas
altenwald.com/book/elixir
Phoenix Framework: Proyecto de Red Social en 7 días
altenwald.com/phoenix-framework
P0 Mmmmmnnibímtntmmmmnn y resfrío que dices
exacto, deja helado y hay quien se resfría, abrígate, descansa y no te pierdas nuestro siguiente vídeo 😉
Aprendí muchísimo con el video!!!
Nos alegra que así sea, gracias por el comentario!
Me ha gustado mucho entender cómo funciona la potencia del ordenador❤ y soy muy fan de los goffers jajajajaja
Nos alegra que haya tenido utilidad el vídeo, gracias por el comentario y nosotros también somos fans! :-)
Interesante entender por qué se requiere hacer la distinción entre concurrencia y paralelismo.
De seguro que ya sabes que la programación se trata casi siempre de forma secuencial y cuando se menciona el trabajo con diferentes procesos/hilos/hebras/rutinas/... los programadores piensan en paralelización pero muy pocas veces en concurrencia. El cambio de paradigma que supone ir de sencuencial a concurrente fue problemático porque no concebían la programación concurrente como una forma de estructurar mejor el código en diferentes secciones trabajando entre sí. Es un tema muy interesante y de seguro en altenwald.com puedes encontrar mucha más información. Gracias por tu comentario!
Muy útil! Desconocia todo esto 😊 Ahora puedo ser el Henry Cavill del principio con mayor seguridad 😙
Cierto, el personaje de los primeros 10 segundos del vídeo parece Henry Cavill :-D nos alegra que hayas aprendido algo nuevo. Gracias por tu comentario!
Una lástima que varios programas no son capaces de usar todos los núcleos al unísono, siendo que no se puede aumentar la velocidad de los núcleos individuales y aveces es indistinto tener 4 o 20 núcleos disponibles. Tambien cabe destacar que no toda la velocidad mononucleo se basa en su relojeo ya que el ipc también tiene influencia
Totalmente de acuerdo, al mantener los núcleos con elementos compartidos tienen la limitación de que deben "pedir turno" para acceder a ciertos elementos como la memoria (solo hay un BUS) y por eso el esquema de concurrencia propuesto por Go fue tan novedoso... y los gophers trabajan bien juntos. Gracias por el comentario y la puntualización.
Muy buen video me ha encantado. La voz del primer chico me resulta muy agradable, me relaja mucho
Gracias por el comentario y el cumplido, esperamos seguir viéndote por los comentarios y que sigas disfrutando de los otros y siguientes vídeos. Saludos.
Interesantísimo el video! me ha gustado entender un poco más los dispositivos que manejamos hoy, no tenía ni idea de que es la concurrencia y ahora es un tema que me interesa mucho
Nos alegra que además de traer un poco del contexto histórico de las cosas, los temas susciten interés. En programación, la concurrencia es un tema muy empleado en lenguajes como Erlang, Elixir o Go, son los principales, altenwald.com suele publicar libros de estos temas para aprender programación por si son de tu interés. Gracias por tu comentario.
En realidad hay otras razones por las que un pc no es mas rápido mas allá de la velocidad del cpu y es que el verdadero cuello de botella es la velocidad de la memoria ram muchísimo mas lenta que el cpu y la velocidad aun mas lenta de las unidades de almacenamiento, esto provoca una latencia intrínseca que lograron parchear usando las memorias cache, aunque solo parcialmente.
Lo otro es que software desde hace años tiene tendencia inflarse y volverse más lerdo, lento y pesado es la contrapartida a la ley de Moore: la Ley de Page y la Ley de Wirth, da igual el incremento en potencia si el consumo en vicio de los programas incrementa proporcionalmente a una escala superior al aumento de la potencia de hardware, y esto es así porque desde hace años se usan (compiladores) en lugar de escribir directamente los programas para se ejecuten sobre hardware (ensamblador) verdaderas montañas de parches sobre parches, código huérfano y complejidad que consume recursos, lo otro es que tarde o temprano las desarrolladoras intel, amd, arm, etc, llegaran finalmente al tope del limite económico donde los equipos y los procesos de fabricación se toparan con un aumento exponencial de los costos y una mayor tasa de fallos a medida que llegan a los limites miniaturización.
Muy interesante 🤔