Nota perev. : Este artículo de éxito medio es una descripción general de los cambios clave (2010-2019) en el mundo de los lenguajes de programación y el ecosistema tecnológico relacionado (se presta especial atención a Docker y Kubernetes). Su autora original es Cindy Sridharan, que se especializa en herramientas para desarrolladores y sistemas distribuidos, en particular, escribió el libro "Observabilidad de sistemas distribuidos", y es bastante popular en el espacio de Internet entre los profesionales de TI que están especialmente interesados en el tema de la nube nativa.
El 2019 ha llegado a su fin, por lo que me gustaría compartir mis pensamientos sobre algunos de los logros e innovaciones tecnológicas más importantes de la última década. Además, intentaré mirar un poco hacia el futuro y describir los principales problemas y oportunidades de la próxima década.
Quiero hacer una reserva inmediata de que en este artículo no cubro cambios en áreas tales como
ciencia de datos , inteligencia artificial, ingeniería frontend, etc., ya que personalmente no tengo suficiente experiencia en ellos.
Typing Strikes Back
Una de las tendencias más positivas de la década de 2010 fue el renacimiento de los idiomas con tipificación estática. Sin embargo, dichos lenguajes no desaparecieron en ninguna parte (C ++ y Java tenían demanda hoy; dominaron hace diez años), sin embargo, los lenguajes con tipeo dinámico (dinámico) experimentaron un aumento significativo en popularidad después de la aparición del movimiento Ruby on Rails en 2005. Este crecimiento alcanzó su punto máximo en 2009 con la apertura del código fuente de Node.js, haciendo realidad Javascript en el servidor.
Con el tiempo, los lenguajes dinámicos han perdido parte de su atractivo en el desarrollo de software de servidor. El lenguaje Go, popularizado durante la revolución de los contenedores, parecía mejor adaptado para crear servidores de alto rendimiento y eficientes en recursos con procesamiento paralelo de información (con lo que el creador de Node.js
está de
acuerdo ).
Rust, introducido en 2010, incluyó avances en la
teoría de tipos en un intento de convertirse en un lenguaje seguro y mecanografiado. En la primera mitad de la década, la actitud hacia Rust en la industria fue bastante buena, pero en la segunda mitad su popularidad aumentó significativamente. Los ejemplos notables del uso de Rust incluyen su uso para
Magic Pocket en Dropbox ,
AWS Firecracker (hablamos de esto en este artículo , aprox. Transl.) , El compilador de WebAssembly anterior de Fastly de Fastly (ahora parte de Bytecode Alliance), etc. En una situación en la que Microsoft está considerando reescribir algunas partes de Windows para Rust, es seguro decir que en la década de 2020 este lenguaje tiene un futuro brillante.
Incluso los lenguajes dinámicos han adquirido nuevas características como los
tipos opcionales . Primero se implementaron en TypeScript, un lenguaje que le permite crear código escrito y compilarlo en JavaScript. PHP, Ruby y Python han adquirido sus propios sistemas de escritura opcionales (
mypy ,
Hack ), que se utilizan con éxito en la
producción .
SQL vuelve a NoSQL
NoSQL es otra tecnología que fue mucho más popular al comienzo de la década que al final. Creo que hay dos razones para esto.
En primer lugar, el modelo NoSQL con falta de esquema, transacciones y garantías de consistencia más débiles resultó ser más difícil de implementar que el modelo SQL. En una
publicación de blog titulada "
Por qué debería elegir una coherencia fuerte, siempre que sea posible", Google escribe:
Una de las cosas que aprendimos en Google es que el código de la aplicación es más simple y el cronograma de desarrollo es más corto si los ingenieros pueden confiar en el almacenamiento existente para manejar transacciones complejas y mantener el orden de los datos. Citando la documentación original de Spanner, "creemos que es mejor si los programadores abordan los problemas de rendimiento de la aplicación debido al abuso de transacciones a medida que se producen cuellos de botella en lugar de tener en cuenta permanentemente la ausencia de transacciones".
La segunda razón está relacionada con el crecimiento de bases de datos SQL distribuidas "escalables" (como
Cloud Spanner y
AWS Aurora ) en el espacio público en la nube, así como con alternativas de código abierto como CockroachDB
(también escribimos sobre ello - Transl. Aprox.) , Que muchos resuelven de problemas técnicos, debido a que las bases SQL tradicionales "no escalaron". Incluso MongoDB, una vez el epítome del movimiento NoSQL, ahora
ofrece transacciones distribuidas.
Para situaciones que requieren operaciones de lectura y escritura atómicas en múltiples documentos (en una o más colecciones), MongoDB admite transacciones con múltiples documentos. En el caso de transacciones distribuidas, las transacciones pueden usarse para muchas operaciones, colecciones, bases de datos, documentos y fragmentos.
Transmisión total
Apache Kafka, sin duda, se ha convertido en uno de los inventos más importantes de la última década. Su código fuente se abrió en enero de 2011, y con los años Kafka ha revolucionado la forma en que funciona el negocio de datos. Kafka se utilizó en todas las empresas en las que tuve la oportunidad de trabajar, desde nuevas empresas hasta grandes corporaciones. Las garantías y los casos de uso que se les proporcionan (pub-sub, streams, arquitecturas orientadas a eventos) se utilizan en diversas tareas: desde la organización del almacenamiento de datos hasta el monitoreo y análisis de transmisión, que son muy demandados en muchas áreas, como finanzas, atención médica, el sector público, el comercio minorista y etc.
Integración continua (y, en menor medida, implementación continua)
La integración continua (integración continua) no apareció en los últimos 10 años, pero fue durante la última década que se
extendió hasta tal punto que se convirtió en parte del flujo de trabajo estándar (ejecute pruebas en todas las solicitudes de extracción). Convertirse en un GitHub como plataforma para desarrollar y almacenar código y, lo que es más importante, desarrollar un flujo de trabajo basado en el
flujo de GitHub significa que realizar pruebas antes de aceptar una solicitud de extracción en el maestro es el
único flujo de trabajo en desarrollo familiar para los ingenieros que comenzaron sus carreras en últimos diez años
La implementación continua (implementación continua; la implementación de cada confirmación tal como es y cuando ingresa al maestro) no está tan extendida como la integración continua. Sin embargo, con muchas API diferentes para la implementación basadas en la nube, la creciente popularidad de plataformas como Kubernetes (que proporciona una API estandarizada para implementaciones) y la aparición de herramientas multiplataforma y multiplataforma como Spinnaker (construido sobre estas API estandarizadas), los procesos de implementación se han vuelto más automatizados, optimizados y optimizados. Generalmente más seguro.
Contenedores
Los contenedores, tal vez, pueden llamarse la tecnología más publicitada, discutida, publicitada e incomprendida de la década de 2010. Por otro lado, esta es una de las innovaciones más importantes de la década anterior. Parte de la razón de toda esta cacofonía radica en las señales mixtas que recibimos en casi todas partes. Ahora que la exageración se ha calmado un poco, algunos momentos han adquirido tonos más distintos.
Los contenedores se han vuelto populares no porque sean la mejor manera de ejecutar una aplicación que satisfaga las necesidades de la comunidad global de desarrolladores. Los contenedores se hicieron populares porque se ajustaban con éxito a una solicitud de marketing de una herramienta que resuelve un problema completamente diferente. Docker resultó ser una herramienta de desarrollo
fantástica para resolver el urgente problema de compatibilidad ("funciona en mi máquina").
Más precisamente, la
imagen de Docker hizo una revolución, ya que resolvió el problema de la paridad entre entornos y aseguró la verdadera portabilidad no solo del archivo de la aplicación, sino también de todo su software y dependencias operativas. El hecho de que esta herramienta haya estimulado de alguna manera la popularidad de los "contenedores", que de hecho constituyen un detalle de implementación de muy bajo nivel, sigue siendo para mí quizás el misterio principal de la última década.
Sin servidor
Apuesto a que la apariencia de la informática "sin servidor" es aún más importante que los contenedores, porque realmente le permite realizar el sueño de la informática a
pedido . En los últimos cinco años, he observado la expansión gradual del alcance del enfoque sin servidor (agregando soporte para nuevos idiomas y tiempos de ejecución). La aparición de productos como Azure Durable Functions parece ser un paso seguro hacia la implementación de funciones con estado (al mismo tiempo que resuelve
algunos problemas relacionados con las restricciones de FaaS). Observaré con interés cómo se desarrollará este nuevo paradigma en los próximos años.
Automatización
Quizás la comunidad de ingenieros operativos se haya beneficiado más de esta tendencia, ya que fue él quien permitió la implementación de conceptos como "infraestructura como código" (IaC). Además, la pasión por la automatización coincidió con el crecimiento de la "cultura SRE", cuyo objetivo es un enfoque de operación más orientado a los programas.
API universal
Otra característica curiosa de la última década ha sido la API de varias tareas de desarrollo. Las API buenas y flexibles permiten a los desarrolladores crear flujos de trabajo innovadores y herramientas que, a su vez, ayudan con el mantenimiento y aumentan la usabilidad.
Además, la ficción API es el primer paso para la ficción SaaS de alguna funcionalidad o herramienta. Esta tendencia también coincidió con la creciente popularidad de los microservicios: SaaS era solo otro servicio con el que puede trabajar utilizando la API. Actualmente hay muchas herramientas SaaS y FOSS en áreas como monitoreo, pagos, equilibrio de carga, integración continua, alertas,
marcado de características , CDN, ingeniería de tráfico (por ejemplo, DNS), etc. quien floreció en la última década.
Observabilidad
Vale la pena señalar que hoy tenemos herramientas
mucho más avanzadas disponibles para monitorear y diagnosticar el comportamiento de las aplicaciones que nunca antes. El sistema de monitoreo Prometheus, que recibió el estado de Código Abierto en 2015, puede llamarse quizás el
mejor sistema de monitoreo de aquellos con los que he trabajado. No es perfecto, pero un número significativo de cosas se implementan de manera completamente correcta (por ejemplo, soporte para
dimensiones en el caso de métricas).
El rastreo distribuido fue otra tecnología que entró en la corriente principal en la década de 2010 gracias a iniciativas como OpenTracing (y su sucesor, OpenTelemetry). Aunque el rastreo sigue siendo bastante difícil de usar, algunos de los últimos desarrollos nos permiten esperar que en la década de 2020 revelemos su verdadero potencial.
(Nota perev.: Lea también en nuestro blog la traducción del artículo "Rastreo distribuido: hicimos todo mal " por el mismo autor).Mirando hacia el futuro
Por desgracia, hay muchos puntos débiles que esperan ser resueltos en la próxima década. Aquí están mis pensamientos sobre ellos y algunas ideas potenciales sobre cómo deshacerse de ellos.
Resolviendo el problema de la ley de Moore
El fin de la ley de escala de Dennard y el retraso de la ley de Moore requieren nuevas innovaciones. John Hennessy, en
su conferencia, explica por qué
las arquitecturas
específicas del dominio, como los TPU, pueden convertirse en una de las soluciones al problema de retrasarse en la ley de Moore. Los
kits de herramientas como los
MLIR de Google ya parecen un buen paso adelante en esta dirección:
Los compiladores deben admitir nuevas aplicaciones, portar fácilmente a un nuevo hardware, vincular muchos niveles de abstracción, desde lenguajes dinámicos y controlados a aceleradores de vectores y dispositivos de almacenamiento controlados por programas, al mismo tiempo que proporcionan conmutadores de alto nivel para el autoajuste, proporcionando funcionalidad justo -tiempo, diagnostica y distribuye información de depuración sobre el funcionamiento y el rendimiento de los sistemas en todo el stack, y en la mayoría de los casos proporciona zvoditelnost suficientemente cerca del ensamblador escrito a mano. Tenemos la intención de compartir nuestra visión, progreso y planes con respecto al desarrollo y la disponibilidad pública de dicha infraestructura de compilación.
CI / CD
Aunque la creciente popularidad de CI se ha convertido en una de las principales tendencias de la década de 2010, Jenkins sigue siendo el estándar de oro de CI.
Este espacio tiene una gran necesidad de innovación en las siguientes áreas:
- interfaz de usuario (DSL para codificar especificaciones de prueba);
- detalles de implementación que lo harán verdaderamente escalable y rápido;
- integración con diversos entornos (puesta en escena, producción, etc.) para la implementación de formas de prueba más avanzadas;
- validación continua y despliegue.
Herramientas para desarrolladores
Como industria, comenzamos a crear software cada vez más complejo e impresionante. Sin embargo, cuando se trata de nuestras propias herramientas, podemos decir que la situación podría ser mucho mejor.
La edición conjunta y remota (a través de ssh) ha ganado cierta popularidad, pero aún no se ha convertido en el nuevo método de desarrollo estándar. Si usted, como yo, rechaza la idea de la
necesidad de una conexión permanente a Internet para poder programar, entonces es poco probable que trabajar a través de ssh en una máquina remota.
Los entornos de desarrollo local, especialmente para ingenieros que trabajan en grandes arquitecturas orientadas a servicios, siguen siendo un problema. Algunos proyectos están tratando de resolverlo, y me interesaría saber cuál será el UX más ergonómico para este caso de uso.
También sería interesante desarrollar el concepto de "entornos portátiles" en otras áreas de desarrollo, como los errores de reproducción (o
pruebas escamosas ) que se encuentran en ciertas condiciones o con ciertas configuraciones.
También me gustaría ver más innovaciones en áreas como la búsqueda de código semántico y sensible al contexto, herramientas que permiten correlacionar incidentes de producción con partes específicas de la base de código, etc.
Cálculos (futuro PaaS)
En medio de la exageración general sobre contenedores y sin servidores en la década de 2010, la gama de soluciones en la nube pública se ha expandido significativamente en los últimos años.
En este sentido, surgen varias preguntas interesantes. En primer lugar, la lista de opciones disponibles en la nube pública crece constantemente. Los proveedores de servicios en la nube tienen personal y recursos para mantenerse al día con los últimos avances en el mundo de código abierto y lanzar productos como pods sin servidor (sospecho que simplemente haciendo que sus propios tiempos de ejecución FaaS sean compatibles con OCI) u otros cosas elegantes similares.
Aquellos que usan estas soluciones en la nube solo pueden ser envidiados. En teoría, las ofertas en la nube de Kubernetes (GKE, EKS, EKS en Fargate, etc.) proporcionan API de proveedores independientes de la nube para ejecutar cargas de trabajo. Si utiliza productos similares (ECS, Fargate, Google Cloud Run, etc.), es probable que maximice el uso de las funciones más interesantes que ofrece el proveedor de servicios. Además, con la llegada de nuevos productos o paradigmas informáticos, es probable que la migración sea simple y sin preocupaciones.
Considerando lo rápido que se está desarrollando el rango de tales soluciones (estoy muy sorprendido si un par de nuevas opciones no aparecen en el futuro cercano), pequeños equipos de "plataforma" (equipos relacionados con la infraestructura y responsables de crear plataformas locales para lanzar cargas de trabajo en las empresas) será increíblemente difícil competir en términos de funcionalidad, facilidad de uso y confiabilidad general. Los años 2010 fueron marcados por Kubernetes como una herramienta para crear PaaS (plataforma como servicio), por lo que parece completamente inútil crear una plataforma interna basada en Kubernetes que ofrezca la misma opción, simplicidad y libertad disponibles en un espacio público en la nube. El concepto de PaaS basado en contenedores como una estrategia de Kubernetes equivale a abandonar intencionalmente las funciones de nube más innovadoras.
Si observa las capacidades informáticas disponibles en la
actualidad , resulta obvio que crear su propio PaaS únicamente sobre la base de Kubernetes equivale a arrinconarse (no es un enfoque con visión de futuro, ¿verdad?). Incluso si alguien decide crear PaaS en contenedor basado en Kubernetes hoy, en un par de años se verá anticuado en comparación con las capacidades de la nube. Aunque Kubernetes comenzó su existencia como un proyecto de código abierto, su progenitor e inspirador ideológico es la herramienta interna de Google correspondiente. Sin embargo, se desarrolló originalmente a principios / mediados de la década de 2000, cuando el panorama informático era completamente diferente.
Además, en un sentido muy amplio, las empresas no deberían convertirse en expertos en trabajar con el clúster de Kubernetes, ni deberían crear y mantener sus propios centros de datos. Proporcionar una base informática confiable es el objetivo principal de
los proveedores de servicios en la nube .
Finalmente, tengo la sensación de que hemos retrocedido un poco como industria en términos de
experiencia de interacción (
UX ). Heroku se lanzó en 2007 y sigue siendo una de las plataformas
más fáciles de usar . Sin duda, Kubernetes tiene mucho más poder, extensibilidad y programabilidad, pero extraño lo fácil que es comenzar y desplegar en Heroku. Para usar esta plataforma, solo conozca a Git.
Todo esto me lleva a la siguiente conclusión: para el trabajo, necesitamos mejores abstracciones de nivel superior (esto es especialmente cierto para las
abstracciones del nivel más alto ).
La API correcta al más alto nivel
Docker es un gran ejemplo de la necesidad de una mejor separación de tareas junto con la
implementación correcta del API de más alto nivel .
El problema de Docker es que (al menos) los objetivos del proyecto se establecieron demasiado globales: todo en aras de resolver el problema de compatibilidad ("funciona en mi máquina") utilizando tecnología de contenedores. Docker era a la vez un formato de imagen y un tiempo de ejecución con su propia red virtual, y una herramienta CLI, y un demonio raíz, y mucho más. En cualquier caso, la mensajería fue
más confusa, sin mencionar las "máquinas virtuales ligeras", los grupos de control, los espacios de nombres, los numerosos problemas de seguridad y las características combinadas con la llamada de marketing "crear, entregar, ejecutar cualquier aplicación en cualquier lugar".
Al igual que con todas las buenas abstracciones, lleva tiempo (así como experiencia y dolor) descomponer los diversos problemas en capas lógicas que se pueden combinar entre sí. Por desgracia, antes de que Docker lograra tal madurez, Kubernetes entró en la pelea. Él monopolizó tanto el ciclo de exageración que ahora todos intentaron mantenerse al día con los cambios en el ecosistema de Kubernetes, y el ecosistema contenedor adquirió un estado secundario.
Kubernetes comparte de muchas maneras los mismos problemas que Docker. A pesar de todo lo que se habla sobre abstracción genial y composable, la
separación de diferentes tareas en capas no
está demasiado encapsulada. Básicamente, es una orquesta de contenedores que lanza contenedores en un grupo de máquinas diferentes. Esta es una tarea de nivel bastante bajo, aplicable solo a los ingenieros que operan el clúster. Kubernetes, por otro lado, también es una
abstracción del más alto nivel , una herramienta CLI con la que los usuarios interactúan a través de YAML.
Docker fue (y sigue siendo) una herramienta de desarrollo
genial , a pesar de todas sus deficiencias. En un intento de mantenerse al día con todas las "liebres" de inmediato, sus desarrolladores lograron implementar correctamente la
abstracción del más alto nivel .
Por abstracción del nivel más alto, me refiero a un subconjunto de la funcionalidad en la que el público objetivo estaba realmente interesado (en este caso, los desarrolladores que pasaron la mayor parte de su tiempo en sus entornos de desarrollo local) y que funcionó perfectamente "fuera de la caja" .
Dockerfile y la utilidad CLI de
docker deberían ser un ejemplo de creación de una buena "interfaz de usuario de nivel superior". Un desarrollador ordinario puede comenzar a trabajar con Docker sin saber nada sobre las complejidades de la
implementación, que contribuyen a la experiencia operativa , como espacios de nombres, grupos de control, limitaciones de memoria y CPU, etc. En última instancia, escribir un Dockerfile no es muy diferente a escribir un script de shell.
Kubernetes está diseñado para varios grupos objetivo:
- Administradores de clúster
- ingenieros de software involucrados en problemas de infraestructura, ampliando las capacidades de Kubernetes y creando plataformas basadas en él;
- usuarios finales que interactúan con Kubernetes a través de
kubectl .
El enfoque de "una API para todos" de Kubernetes es una "montaña de complejidad" subencapsulada sin una indicación de cómo escalarlo. Todo esto lleva a un camino de aprendizaje irrazonablemente largo. Según Adam Jacob, "Docker trajo a los usuarios una experiencia transformadora que aún no ha sido superada. Pregúntele a cualquiera que use K8 si le gustaría que funcionara como su primer
docker run . La respuesta será "sí":
Diría que la mayor parte de la tecnología de infraestructura actual es de nivel demasiado bajo (y, por lo tanto, se considera "demasiado complejo"). Kubernetes se implementa a un nivel bastante bajo. El rastreo distribuido en su
forma actual (muchos tramos cosidos para formar una vista de rastreo) también se implementa a un nivel demasiado bajo. Las herramientas para desarrolladores que implementan "abstracciones del más alto nivel", como regla, son las más exitosas. Esta conclusión es cierta en un sorprendente número de casos (si la tecnología es demasiado compleja o difícil de usar, entonces el "nivel más alto de API / UI" para esta tecnología aún no se ha abierto).
En este momento, el ecosistema nativo de la nube está avergonzado por su enfoque en los niveles bajos. Como industria, debemos innovar, experimentar y enseñar cómo se ve el nivel correcto de "máxima, máxima abstracción".
Comercio minorista
En la década de 2010, la experiencia minorista digital apenas cambió. Por un lado, la facilidad de las compras en línea debería haber afectado a las tiendas minoristas clásicas y, por otro, las compras en línea apenas han cambiado en una década.
Aunque no tengo pensamientos concretos sobre el desarrollo de esta industria en la próxima década, estaré muy decepcionado si en 2030 hacemos compras de la misma manera que en 2020.
Periodismo
Cada vez estoy más decepcionado con el estado del periodismo mundial. Cada vez es más difícil encontrar recursos informativos imparciales que transmitan de manera objetiva y meticulosa. Muy a menudo, se borra el límite entre las noticias en sí y la opinión al respecto. Como regla, la información está sesgada. Esto es especialmente cierto en el caso de algunos países donde históricamente no hubo separación entre noticias y opiniones al respecto. En un artículo reciente publicado después de las últimas elecciones generales en el Reino Unido, Alan Rusbridger, ex editor de The Guardian,
escribe :
La idea principal es que durante muchos años miré los periódicos estadounidenses y sentí lástima por los colegas de allí que eran los únicos responsables de las noticias, haciendo comentarios sobre personas completamente diferentes. Sin embargo, con el tiempo, la pena se convirtió en envidia. Ahora creo que todos los periódicos nacionales británicos deberían separar la responsabilidad de las noticias de la responsabilidad de los comentarios. Por desgracia, el lector promedio, especialmente el lector en línea, es demasiado difícil de distinguir.
Dada la dudosa reputación de Silicon Valley cuando se trata de ética, en ningún caso confiaría en la tecnología para "revolucionar" el periodismo. Al mismo tiempo, yo (y muchos de mis amigos) me alegraría que apareciera un recurso de noticias imparcial, desinteresado y confiable. Si bien no puedo imaginar cómo se vería una plataforma de este tipo, estoy seguro de que en una era en la que la verdad es cada vez más difícil de discernir, la necesidad de un periodismo honesto es mayor que nunca.
Redes sociales
Las redes sociales y las plataformas de noticias colectivas son la principal fuente de información para muchas personas en diferentes partes del mundo, y la falta de precisión y la renuencia de algunas plataformas para realizar al menos una verificación básica de hechos básicos conducen a consecuencias tan graves como el genocidio, la interferencia en las elecciones, etc.
Las redes sociales también son la herramienta de medios más poderosa que haya existido. Cambiaron radicalmente la práctica política. Cambiaron los anuncios. Cambiaron la cultura pop (por ejemplo, son las redes sociales las que hacen la principal contribución al desarrollo de la llamada cultura de cancelación
[ redes sociales del
Ostracismo - aprox. Transl.] ). Los críticos argumentan que las redes sociales resultaron ser un terreno fértil para cambios rápidos y "caprichosos" en los valores morales, pero también brindaron a los representantes de los grupos marginados la oportunidad de unirse (nunca antes habían tenido esa oportunidad). En esencia, las redes sociales han cambiado la forma en que las personas se comunican y cómo se expresan en el siglo XXI.
Sin embargo, también estoy convencido de que las redes sociales contribuyen a la manifestación de los peores impulsos humanos. La atención y la consideración a menudo se descuidan en aras de la popularidad, y se vuelve casi imposible expresar un desacuerdo razonado con ciertas opiniones y posiciones. La polarización a menudo se sale de control, como resultado, el público simplemente no escucha opiniones separadas, mientras que los absolutistas controlan los problemas de etiqueta y aceptabilidad en línea.
Me pregunto, ¿es posible crear una plataforma "mejor" que pueda ayudar a mejorar la calidad de las discusiones? Después de todo, es precisamente lo que impulsa el "compromiso" lo que a menudo trae el beneficio principal a estas plataformas. Como Kara Swisher
escribe en el New York Times:
El compromiso digital puede desarrollarse sin provocar odio e intolerancia. La razón por la cual la mayoría de las redes sociales parecen tan tóxicas es porque fueron creadas para la velocidad, la viralidad y la atención, no para el contenido y la precisión.
Sería realmente lamentable que, en un par de décadas, el único legado de las redes sociales fuera la erosión de los matices y la adecuación del discurso público.
PD del traductor
Lea también en nuestro blog: