Informática, desarrollo, sistemas...

Hoy un compañero de trabajo me preguntó ¿qué opinas de los threads? Lo he explicado muchas veces, pero no tengo inconveniente en repetirlo y tratar de ser lo más claro posible. Así que le contesté lo siguiente... To thread or not to thread… And the winner is… NO. Pero sólo para empezar. “NO” es una palabrita muy suave, muy flojita, breve, pequeña, insignificante en ocasiones. La respuesta se merece un poco más de atención, un poco más de elocuencia y contundencia que un simple, raquítico y triste “NO”. Trataré de completar un poco la respuesta. Este NO, no significa un rechazo a la concurrencia o al paralelismo (está de moda decir que concurrencia no es paralelismo, pero creo que con concurrencia nos entenderemos lo suficiente). Espero poder dejar eso claro en la siguiente explicación. En el origen de los tiempos, los sistemas ejecutaban una cosa, y bastante merito tenían (algunos). Hacer varias cosas simultáneamente fue una gran idea y una gran neces

Para ser  telnet friendly  recibiremos y enviaremos texto separado por retornos de carro. El programa se limitará a responder lo mismo que reciba. Para trocear los mensajes en líneas separadas por retorno de carro, leeremos byte a byte y los meteremos en un buffer. Sí, hay otra forma de hacerlo más sencillo, pero hacerlo a mano es más didáctico. Al final también indicaremos la forma  erlangish ¿Es mejor que el buffer sea un  binary  o una  lista ? iex> {microsecs, :ok} = :timer.tc fn -> (1..1000 |> Enum.each fn _ -> (1..1000 |> (Enum.reduce [], &( [rem(&1, 10)+48|&2])) |> Enum.reverse |> to_string) end) end; IO.puts microsecs/1000000.0 3.493395 iex> {microsecs, :ok} = :timer.tc fn->(1..1000 |> Enum.each fn _ -> (1..1000 |> Enum.reduce "", &(&2 <> (<<rem(&1, 10)+48>>))) end) end; IO.puts microsecs/1000000.0 7.098454 La respuesta es una lista. Crearemos un  socket t