Forem: Camilo

Separación de Responsabilidades de los Dispositivos

Camilo — Sat, 24 Jan 2026 17:49:45 +0000

La verdad yo creo que mi vida era mucho más ordenada y simple cuando mi celular solo podía conectarse a internet a páginas WAP usando Symbian en un Nokia por allá en el 2007 y solo lo utilizaba para descargar ringtones midi.

Creo que más de 10 años usando iPhone y otros "smartphones" ha mermado mi capacidad de concentración y restado a mi calidad de vida en general. Ha llegado el momento de replantear la relación que yo tengo con la tecnología, sobre todo la que es muy enganchante como las redes sociales.

Siendo un Ingeniero en Software es necesario evaluar estos temas por que la tecnología informática siempre ha sido de mi predilección frente a otras áreas del conocimiento humano. Una vez que se masificaron los smartphones y las redes sociales, poco a poco el tiempo que dedicaba a leer libros, hacer artesanías u simplemente disfrutar el día se ha disminuido notablemente, sobre todo durante y luego de la pandemia. Dedicando un tiempo poco saludable a mirar una pantalla pequeña. Las redes sociales y las constantes notificaciones se han vuelto un sifón de atención y energía que debo controlar.

¿Es ser un Ludista?

No creo que la solución sea eliminar la tecnología actual de nuestras vidas. No abogo ser un seguidor de Ned Ludd. Pero pienso que las tecnologías actuales sin un orden y control adecuado se han convertido en herramientas de servidumbre del humano hacia la máquina y no como era antes donde la máquina servía al humano.

Tecnología Kosher/Halal

Los miembros de la religión Judía utilizan el término "Kosher" para significar que algo "esta bien" y "aprobado" para que un judío utilice un alimento u otro elemento por que está dentro de lo permitido en su religión. Los miembros de la religión Musulmana utilizan el término "Halal" para el mismo fin.

Dentro de ésta tecnología "Kosher" existen los celulares que no permiten acceso a internet o reproductores de mp3 sin acceso a la radio FM, entre otras restricciones. La idea es evitar acceder a contenido que pudiera ser perjudicial para alguien que siga las normas de la religión.

¿Qué opciones hay?

Como Ingeniero en Software es vital estar actualizado en el avance tecnológico y estar capacitado en las tecnologías del estado del arte en la industria que uno desee participar. Pero eso no significa estar conectado 24/7 a la marea de información disponible cada segundo.

Por lo tanto creo que es pertinente poner algunas reglas que permitan dar orden a todo el caos generado por los "smartphones" y redes sociales.

Espacio Dedicado

En la época de los cibercafes pre 2010. La mayoría de las personas tenían un lugar dedicado en la casa para uso del computador. Por que eran comunes las pantallas CRT grandes y equipos pesados. Los notebook si bien existían, tenían precios elevados que no todas las familias podían permitir alcanzar.

Hoy es más probable tener un notebook que un computador de escritorio, ya que los computadores de escritorio se asocian más con streaming, videojuegos y situaciones de alta exigencia de recursos por que hay mayor flexibilidad de cambiar componentes.

Los notebook son más asociados a contextos de trabajo general y navegación de internet, por lo menos las opciones económicas.

Considero que se debe rescatar esa tradición de tener un lugar dedicado para la computación por que permitía ordenar los espacios y tener un mise en place de la computación.

https://es.wikipedia.org/wiki/Mise_en_place#/media/Archivo:Mise_en_place_for_hot_station.jpg

Tener un Celular Simple

Un celular simple se puede encontrar como "Senior Phones" o "Nonnophone". Hoy todavía se pueden encontrar teléfonos con Symbian o similar que son compatibles. La red 2G ya no es funcional en Chile, por lo que muchos celulares del 2010 o anterior ya no sirven. Pero se pueden encontrar algunos reemplazos bastante buenos.

Por ejemplo el Teléfono Móvil Senior 3g Nonnophone 3.0 Green-e.
Este celular no tiene acceso a internet, pero si tiene un cargador moderno, bluetooth, radio FM y posibilidad de sacar fotos a la vieja escuela con una cámara 2GP y guardarlas en una tarjeta sd.

La verdad pienso de que es sumamente útil por que no tiene notificaciones constantes. Los únicos mensajes que llegarán serán por SMS y las llamadas serán de personas que conozcan nuestro número (omitiendo el SPAM de algunas empresas o estafadores). Además no puedes tener instagram, whatsapp, facebook, email, slack, x (ex twitter) o teams instalado.

Herramientas de Trabajo

¿No más smartphone?. En mi experiencia es mejor tener ambos tanto un celular simple como uno smart, algunas de las apps necesitan ser usadas y solo funcionan en un celular smartphone como Instagram o a veces piden las empresas usar aplicaciones de OTP para hacer login a la VPN. Por lo que es necesario tener un smartphone para el mundo laboral actual. Sin embargo creo que es necesario ver el smartphone como una herramienta de trabajo más que como una herramienta de "uso en todos los contextos".

Si no puedo tener esas apps en mi celular ¿Donde las uso?. Pues las herramientas de comunicación como slack, email y amigos son esenciales para cualquier trabajo, pero no deberían ser tan esenciales como para estar conectadas a ella todo el día e incluso en nuestros momentos privados en el baño.

La estrategia es tener un smartphone para las apps obligatorias del trabajo y comunicaciones como Whatsapp. Pero no usarlo ni tenerlo cerca si no es necesario, quizás guardarlo en un cajón y no tenerlo a la vista.

Cambiar el chip para llamadas telefónicas y sms al teléfono simple. De esta forma el smartphone solo se convierte en un puente a la tecnología moderna y conservamos la comunicación esencial en un teléfono simple.

Muchas de las aplicaciones de trabajo funcionan perfectamente en un computador tradicional y se puede hacer todas las tareas que tiene un smartphone, en su gran mayoría.

Por lo que esta estrategia también en más barata a largo plazo, no se necesita un smartphone nuevo cada año y no se necesita usarlo mucho por lo que su tiempo de vida es mayor.

Conclusiones

Creo que es saludable volver a un mundo donde tenemos control de la tecnología y no al revés. Usemos un celular simple para llamar y enviar sms, usemos una cámara de fotos para sacar fotos y un reproductor de música sin internet para escuchar canciones que no puedan ser borradas de un servidor.

El smartphone debe ser catalogado como una herramienta de trabajo, más no convertirse en una aspiradora de nuestro tiempo y energía. Si simplemente lo usamos para las tareas esenciales y obligatorias. Dejando al computador como la herramienta principal de acceso a internet, trabajo y comunicación.

Rescatemos lo mejor de la década del 2000 y aprendamos las buenas prácticas y separación de responsabilidades de cada dispositivo para que no se vuelvan nuestros gobernantes.

Portada: https://commons.wikimedia.org/wiki/File:Telmac_1800.JPG

[Boost]

Camilo — Wed, 17 Sep 2025 00:21:46 +0000

Masatoshi Nishiguchi

Sep 2 '25

Getting Started with AtomVM: Setup with Prebuilt Firmware (ESP32-S3, September 2025)

#atomvm #elixir #esp32 #iot

Comments

6 min read

Odin for Alchemists

Camilo — Thu, 14 Nov 2024 13:03:00 +0000

Modules

Elixir

Elixir has the concept of modules. Which can be inside a single file or can be subdivided in multiple files. Directories are not important for the compiler since all the modules will only differentiate by their name My.Module.

directory/
- module_1.ex
- module_2.ex
- module_3_and_4.ex

Odin

In Odin we have the concept of packages. A package is a directory that contains different files. Directories are important to Odin. Package names must be unique and be a valid identifier. Example My_Package.

package/
- file1.odin
- file2.odin

Is like the compiler concatenates all the files in a single file for a package.

Similar to this:

$ cat cat/paws.odin cat/meows.odin > cat/amalgamated_package.odin

All the files in the same package will share the package name in the file.

Example

cat/paws.odin: package Cat.
cat/meows.odin: package Cat.

For using the public procedures, constants, structs, unions from a package we have to import it. Keep in mind that we import the directory as a whole and not a single file.

import "lib/cat"

We can make an alias by using another name before the route.

import Cat "../cat"

Cat.meow()
Cat.sleep()

Aliases are needed if your package has an invalid identifier. For example if you store a library inside a version number.

0.4/
  - mylib.odin

If we would like to import it we need an alias.

import mylib "0.4"

Collections

Odin has the concept of collections that are predefined paths that can be used in imports.

core: The most common collection that contains useful libraries from Odin core like fmt or strings.

You can define your own collection at build time

The following will define the collection project and put the path at the current directory.

$ odin run . -collection:project=.

Public by Default

Odin Exported Names are public by default (anything you declare in a file is public and can be accesed by other packages). If you don't want to export something you have to use @(private) before declaration.

@(private)
my_variable: int // cannot be accessed outside this package

@(private) is equivalent to @(private="package").

You can make the declarations private by file, only available within the file where was declared.

@(private="file")
my_variable: int // cannot be accessed outside this file

Another option is using the #+private or #+private file general attributes before the package name. That makes all the file private by default and only available to the package itself.

private_by_default.odin

#+private
package Package1

// This procedure will only be available to the package
// impossible to make it public unless is stored in another file
// without the #+private directive
private_proc :: proc() -> int {
  return 42
}

By using this alternative we can have a file that is only for storing private procedures and other data structures.

Being private by default is a benefit because it requires you to explicitly expose things to be part of your libraries API, improving the organization of your package.

my_package/
  - api.odin
  - api.priv.odin

We can store all the private declarations in a single private file and not clutter with @(private) in every symbol.

Maps

Elixir

%{
 "this": "is my map",
 "answer": 42
}

Odin

In Odin we have to be more specific with types. If we would like multiple types we may think is a good idea to use any.

map[string]any {
  "this" = "is my map", 
  "answer" = 42, 
}

WARNING

This is just an example use of any type. Literally the use of any is dangerous. Is best to never use it unless you know EXACTLY how it works. The type any is just a pointer and a typeid. When you assign a value to an any you are in fact taking the address of the value. This means if you make a pointer to a variable inside a procedure, this will crash the program if you use it outside the procedure.

insert_values := proc(m: ^map[string]any) {
  a := "hello"
  b := 42

  m["a"] = a
  m["b"] = b
}

main :: proc() {
  m := make(map[string]any)
  defer delete(m)

  insert_values(&m)

  log.info(m["a"], m["b"]) // crashes here
}

Structs

In Elixir we can create a struct like this:

defmodule MyStruct do
  defstruct [:name, :email]
  def new(name, email) do
    %MyStruct{name: name, email: email}
  end
end

MyStruct.new("Camilo", "email@example.com")
|> IO.inspect

In Odin we can use the following

package Project

import "core:fmt"

MyStruct :: struct {
    name : string,
    email : string,
}

main :: proc() {
    fmt.println(MyStruct{name = "Camilo", email = "email@example.com"})
}

Unions

So how we can make a map that takes both ints and strings without the use of any. For more specific type validation Odin has Unions.

A union in Odin is a discriminated union, also known as a tagged union or sum type. The zero value of a union is nil.

AvailableMapValueTypes :: union {
  int,
  string,
}

map[string]AvailableMapValueTypes {
  "this" = "is my map", 
  "answer" = 42, 
}

We can make it a little bit shorter. Also ensure that we manage the memory allocated with maps.

mymap := map[string](union{int, string}) {
    "this" = "is my map", 
    "answer" = 42, 
}

defer delete(mymap)

In memory, Unions are just a special variant of Structs.

struct {
    payload: [size_of(Largest_Variant_Type)]byte,
    tag: byte,
}

They store exactly one of their possibly variants at any given moment, and the tag is used to know which one is currently being stored at any given moment. They can also be empty, in which case the tag == 0, and the_union_value == nil.

Lists

Elixir

["1", 2]

Odin

In Odin we have to be more strict with the types.

Array of strings

[]string{"1", "2"}

Can also be added dynamic to be more explicit. Be careful because comparations will notice the type difference between [] and [dynamic]. Normally [dynamic] are called slices.

[dynamic]string{"1", "2"}

Array of numbers

[]int{1, 2}

List of items

[]any{"1", 2}

Fixed size list of items

[2]any{"1", 2}

Automatic fixed size list of items
This will calculate and replace ? with 2
at compilation time.

[?]any{"1", 2}
// same as [2]any{"1", 2}

Array Programming

Odin’s fixed length arrays support array programming.

Vector3 :: [3]f32
a := Vector3{1, 4, 9}
b := Vector3{2, 4, 8}
c := a + b  // {3, 8, 17}
d := a * b  // {2, 16, 72}
e := c != d // true

Enum.map

Elixir

In Elixir we use Enum.map.

# [2, 3, 4]
Enum.map([1, 2, 3], fn x -> x + 1  end)

Odin

In Odin we use slice.mapper.

// [2, 3, 4]
slice.mapper([]int{1, 2, 3}, proc(element : int) -> int {
  return element + 1
})

Enum.filter

Elixir

In Elixir we use Enum.filter.

# [2]
Enum.filter([1, 2, 3], fn x -> rem(x, 2) == 0 end)

Odin

In Odin we use slice.filter

slice.filter([]int{1, 2, 3}, proc(element : int) -> bool {
    return element % 2 == 0
})

Enum.reduce

Elixir

In Elixir we use Enum.reduce

# 24
Enum.reduce([1, 2, 3, 4], fn x, acc -> x * acc end)

Odin

In Odin we use slice.reduce

slice.reduce([]int{1, 2, 3, 4}, 1, proc(accumulator: int, element : int) -> int {
    return element * accumulator
})

About Map, Reduce, Filter and other "functional" like procedures

Keep in mind that procedures like map, filter and reduce are super handy and work superb with functional languages such as Elixir. In procedural languages, and specially in system level languages such as Odin, they need to be picked like a grain of salt.

Consider the procedural approach when traversing an array. Maybe it would make more sense to the reader.

items := []string{"one", "two"}
for item in items {
    if item != "two" { continue }
}

When it comes to real code, though, don't overcomplicate it. Odin doesn't play well with typical functional approaches to problems, nor does it intend to, so try not to lean too heavily on them. Also, as a point of design, if you feel friction, it's Odin telling you "No".

Let procedural languages be procedural languages. And let functional languages be functional languages. Stop trying to force incompatible ideas into the other paradigm.
--- GingerBill

// Detect dark theme var iframe = document.getElementById('tweet-1856080709821124817-988'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1856080709821124817&theme=dark" }

String concatenation

Elixir

"My String" <> " is good"

Output

My String is good

Odin

import "core:strings"

// items := []string{"My String", " is good"}
// strings.concatenate(items)
strings.concatenate({"My String", " is good"}) 
// Odin can infer the argument type

Output

My String is good

String interpolation

Elixir

"Hello this is 4 + 2 = #{4 + 2}"

Output

Hello this is 4 + 2 = 6

Odin

In Odin we currently don't have string interpolation. But we can use the sprintf C style using fmt.tprintf procedure.

import "core:fmt"

fmt.tprintf("Hello this is 4 + 2 = %d", 4 + 2)

Output

Hello this is 4 + 2 = 6

Note

If you call fmt.tprintf without using the result, the compiler will be mad with Error: 'fmt.tprintf' requires that its results must be handled.

This means we must handle the result in someway.

// Do nothing with the result
_ = fmt.tprintf("Hello this is 4 + 2 = %d", 4 + 2)

// Store it in a variable
result = fmt.tprintf("Hello this is 4 + 2 = %d", 4 + 2)

// Wrap in a procedure that does not throws error
my_print :: proc() -> string {
  return fmt.tprintf("Hello this is 4 + 2 = %d", 4 + 2)
}

// print the result string
fmt.println(fmt.tprintf("Hello this is 4 + 2 = %d", 4 + 2))

So called interpolated strings are really just expressions in disguise, consisting of string concatenation of the various parts of the string content, alternating string literal fragments with interpolated subexpressions converted to string values.

The interpolated string

"Hello #{name}!"

is equivalent to

concatenate(concatenate("Hello", to_string(name)) , "!")

String interpolation in C

Function Overloading

Let's say you need a count procedure that you pass a list and returns "numbers" or "words" depending on the input type.

Elixir

This is the example code in Elixir to achieve this.

defmodule Counter do
  def count([first | _rest] = items) when is_number(first), do: "#{Enum.count(items)} numbers"
  def count(items), do: "#{Enum.count(items)} words"
end

Counter.count([1, 2, 3])
|> IO.inspect

Counter.count(["one", "two", "three"])
|> IO.inspect

Output:

"3 numbers"
"3 words"

Odin

In Odin we have Explicit Procedure Overloading. The design goals of Odin were explicitness and simplicity.

// odin run counter.odin -file
package Counter

import "core:fmt"

count_numbers :: proc(items: []int) -> string {
  return fmt.tprintf("%d numbers", len(items))
}

count_words :: proc(items: []string) -> string {
  return fmt.tprintf("%d words", len(items))
}

// Explicit Procedure Overloading
// Notice this is a procedure without parenthesis after `proc`
count :: proc {
  count_words,
  count_numbers
}

main :: proc() {
  numbers := []int{1, 2, 3}
  fmt.println(count(numbers))

  words := []string{"one", "two", "three"}
  fmt.println(count(words))
}

Output:

"3 numbers"
"3 words"

Explicit overloading has many advantages:

Explicitness of what is overloaded
Able to refer to the specific procedure if needed
Clear which scope the entity name belongs to
Ability to specialize parametric polymorphic procedures if necessary, which have the same parameter but different bounds (see where clauses, where clauses are similar to Elixir Guards)

Anonymous Functions

Elixir

In Elixir we can use Anonymous Functions, also called Lambdas or Fat Arrow functions in other programming languages.

add = fn a, b -> a + b end
add.(1, 2)

Output

Odin

In Odin we store a procedure pointer and pass it around. Odin can define procedures within procedures.

subtract :: proc(a: int, b: int) -> int {
  return a - b
}

main :: proc() {
  add := proc(a: int, b: int) -> int {
        return a + b
  }

  subtract_pointer := subtract

  subtract_pointer(6,add(1, 2))
}

Output

Named Arguments

Elixir

In Elixir we use Keyword lists to have named arguments

defmodule Hello do
  def get([name: name, shows: shows]) do
    IO.inspect shows, label: name
  end
end

Hello.get(name: "Camilo", shows: 2)

Output

Camilo: 2

Odin

In Odin is supported named arguments.

hello := proc(name: string, shows: int) {
    fmt.printfln("%s: %d", name, shows)
}

hello(name = "Camilo", shows = 2)

Output

Camilo: 2

Parametric polymorphism

Elixir

In Elixir since you can pass any type as param (unless properly restricted and pattern matched), there is inherent parametric polymorphism.

Odin

Commonly referred to as “generics”, allow the user to create a procedure or data that can be written generically so it can handle values in the same manner.

https://odin-lang.org/docs/overview/#parametric-polymorphism

Let's do a little exercise trying to implement filter and map for slices. These are already implemented in the core at slice.filter and slice.mapper.

The following code is just an example of parametric polymorphism. A better implementation is available with slice.filter and slice.mapper.

The idea is to have a type definition with $ that can be used instead of a specific type like string. Normally is defined as $T, but can be named anything like $MyGenericType. Once is defined it can be used for any other param or declaration in the procedure scope. You can reuse a type in multiple places as a way of saying that they're the same.

filter

Filters the enumerable, i.e. returns only those elements for which proc returns a truthy value.

filter :: proc(enumerable: []$T, callback: proc(element: T) -> bool) -> [dynamic]T {
    results : [dynamic]T
    for item in enumerable {
        if (callback(item)) {
            append(&results, item)
        }
    }
    return results
}

Notice how we can pass proc as parameters. It's the full declaration, but without its implementation.

callback: proc(element: T) -> bool

Usage

string slice

items := []string{"one", "two"}

filtered := filter(items, proc (element: string) -> bool {
    return element == "two"
})
// ["two"]
fmt.println(filtered)

int slice

filtered_int := filter([]int{1, 2, 3}, proc (element: int) -> bool {
        return element == 2
})

// [2]
fmt.println(filtered)

map (mapper)

Returns a slice where each element is the result of invoking proc on each corresponding element of enumerable.

mapper :: proc(enumerable: []$T, callback: proc(element: T) -> T) -> [dynamic]T {
    results : [dynamic]T
    for item in enumerable {
        append(&results, callback(item))
    }
    return results
}

Usage

string slice

items := []string{"one", "two"}

mapped := mapper(items, proc(element: string) -> string {
   if element == "one" {
      return "three"
   }

   return "four"
})

// ["three", "four"]
fmt.println(mapped)

int slice

items := []int{1, 2, 3}

mapped_int := mapper(items, proc(element: int) -> int {
   if element == 1 {
      return 2
   }

   return 4
})

// [2, 4, 4]
fmt.println(mapped_int)

Error Handling

Elixir

In Elixir we can handle errors by returning a tuple {:error, reason} and {:ok, result} if the result is ok. Also we can have exceptions (try, catch, rescue).

defmodule PositiveSum do
  def sum(a, b) when is_number(a) and is_number(b) do
     case (a + b) do
          result when result > 0 -> {:ok, result}
          result when result < 0 -> {:error, "Only positive results allowed"}
          _ -> {:error, "Zero is neither positive or negative"}
     end
  end
end

PositiveSum.sum(1, 2)
|> IO.inspect

PositiveSum.sum(1, -4)
|> IO.inspect

PositiveSum.sum(0, 0)
|> IO.inspect

try do
  PositiveSum.sum(1, "b")
rescue
  _error -> {:error,"Params are not numbers"}
end
|> IO.inspect

Output

{:ok, 3}
{:error, "Only positive results allowed"}
{:error, "Zero is neither positive or negative"}
{:error, "Params are not numbers"}

Odin

In Odin we can handle the errors using different strategies by returning multiple results from a procedure. Since Odin is a typed language, is a lot harder to send wrong typed params to a procedure. It won't compile.

Strategy 1: `ok` booleans

The first strategy is to return a bool at the last return parameter. This strategy will only give a ok or !ok status.

sum := proc(a : int, b : int) -> (result: int, ok: bool) {
    result = a + b
    if result > 0 {
        return result, true
    }

    if result < 0 {
        return result, false
    }
    return result, false
}

fmt.println(sum(1, 2)) // 3, true
fmt.println(sum(1, -4)) // -3, false
fmt.println(sum(0, 0)) // 0, false

fmt.println(sum(0, "b")) // won't compile

But if we use the result, we would need to store it in several variables. Or we would get a compilation error similar to: Error: Assignment count mismatch '1' = '2'.

result := sum(1, -4) // Won' compile.

This means we must store the success (ok) status somewhere.

// -3, false
result, ok := sum(1, -4)
if !ok {
  fmt.printfln("%d, %s", result, "There were problems in the Sum")
}

We could ommit the variable using the special _ character (rune).

// -3, false
result, _ := sum(1, -4)
fmt.printfln("%d", result)

We can add #optional_ok tag to the procedure declaration so we can omit the final boolean.

Important

#optional_ok requires exactly 2 return params. Only accepts the last param as a boolean.

sum := proc(a : int, b : int) -> (result: int, ok: bool) #optional_ok {...}

// -3, false
result := sum(1, -4)
fmt.printfln("%d", result)

There is also the #optional_allocation_error that can be used instead of #optional_ok and its meant for procedures that could return an allocation error.

Strategy 2: Error messages

We can return the message. However there is no way to tag the declaration to be optional the same way a boolean can.

sum :: proc(a : int, b : int) -> (result: int, err: string) {
    result = a + b
    if result > 0 {
        return result, ""
    }

    if result < 0 {
        return result, "Only positive results allowed"
    }

    return result, "Zero is neither positive or negative"
}

result, err := sum(5, -6)
if err != "" {
    fmt.printfln("%d, %s", result, err)
}

Strategy 3: Int returns

This can be used when dealing with C libraries or system processes that returns a number to indicate status. We have to combine them with arrays or enums so we can have an error message.

error_strings := [?]string{
  "ok", 
  "Only positive results allowed", 
  "Zero is neither positive or negative"
}

sum :: proc(a : int, b : int) -> (result: int, err: int) {
    result = a + b
    if result > 0 {
        return result, 0
    }

    if result < 0 {
        return result, 1
    }

    return result, 2
}

result, status := sum(5, -6)
fmt.printfln("%d, %s", result, error_strings[status])

Strategy 4: Enum Errors

This strategy provides a little more standarization of error codes and messages, by using enum. In the following code we use a procedure to return the message for the enum.

PositiveSumError :: enum {
    None,
    Negative_Result,
    Zero_Result,
}

positive_sum_error_message :: proc(err : PositiveSumError) -> (message: string) {
    switch err {
    case .None:
        message = ""
    case .Negative_Result:
        message = "Only positive results allowed"
    case .Zero_Result:
        message = "Zero is neither positive or negative"
    }
    return message
}

sum :: proc(a : int, b : int) -> (result: int, err: PositiveSumError) {
    result = a + b
    if result > 0 {
        return result, .None
    }

    if result < 0 {
        return result, .Negative_Result
    }

    return result, .Zero_Result
}

result, status := sum(5, -6)

fmt.printfln("%d, %v", result, positive_sum_error_message(status))

This can also be simplified to

PositiveSumError :: enum {
    None,
    Negative_Result,
    Zero_Result,
}

// usage: error_strings[.Negative_Result]
error_strings := [PositiveSumError]string{
  .None = "ok", 
  .Negative_Result = "Only positive results allowed", 
  .Zero_Result = "Zero is neither positive or negative"
}

You can use unions to join different enums. We can see an example in net/common.odin.

General_Error :: enum u32 {
    None = 0,
    Unable_To_Enumerate_Network_Interfaces = 1,
}

DNS_Error :: enum u32 {
    Invalid_Hostname_Error = 1,
    Invalid_Hosts_Config_Error,
    Invalid_Resolv_Config_Error,
    Connection_Error,
    Server_Error,
    System_Error,
}

Network_Error :: union #shared_nil {
    General_Error,
    DNS_Error,
    // ... //
}

Strategy 5: Struct Errors

In this strategy we use structs to save the message. Optionally we combine it with enums for easier comparison later.

PositiveSumErrorCode :: enum {
    None,
    Negative_Result,
    Zero_Result,
}

PositiveSumError :: struct {
    message: string,
    code : PositiveSumErrorCode,
}

sum :: proc(a : int, b : int) -> (result: int, err: PositiveSumError) {
    result = a + b
    if result > 0 {
        return result, PositiveSumError{code = .None}
    }

    if result < 0 {
        return result,  PositiveSumError{
            message = "Only positive results allowed",
            code = .Negative_Result,
        }
    }

    return result,  PositiveSumError{
        message = "Zero is neither positive or negative",
        code = .Zero_Result,
    }
}

result, err := sum(5, 6)
fmt.printfln("%d, %s", result, err.message)

Strategy 6: Struct + Ok

In this strategy we combine both the struct errors and ok boolean. This is the most similar to Elixir and other programming languages that uses exceptions.

PositiveSumErrorCode :: enum {
    None,
    Negative_Result,
    Zero_Result,
}

PositiveSumError :: struct {
    message: string,
    code : PositiveSumErrorCode,
}

PositiveSumResult :: struct {
    value : int,
    error : PositiveSumError,
}

sum :: proc(a : int, b : int) -> (result: PositiveSumResult, ok : bool) #optional_ok {
    value := a + b
    if value > 0 {
        return PositiveSumResult{
            value = value, 
            error = PositiveSumError{code = .None},
        }, true
    }

    if value < 0 {
        return PositiveSumResult{
            value = value, 
            error = PositiveSumError{
                message = "Only positive results allowed",
                code = .Negative_Result,
            },
        }, false
    }

    return PositiveSumResult{
        value = value, 
        error = PositiveSumError{
            message = "Zero is neither positive or negative",
            code = .Zero_Result,
        },
    }, false
}

result, ok := sum(5, -6)
// -1, Only positive results allowed, ok? false
fmt.printfln("%d, %s, ok? %v", result.value, result.error.message, ok)

Final thoughts

It is OK to make stuff just for the sake of it, to explore how stuff works. Just be careful not to overcomplicate things.

Thanks to Odin forum members Barinzaya, Tetralux, Vicix, Jesse and GingerBill for the guidance and corrections.

Image from: https://commons.wikimedia.org/wiki/File:Celum_philosophorum_1527_Title_page_AQ8_(detail).jpg

Odin's Elixir

Camilo — Sun, 10 Nov 2024 12:25:49 +0000

Also available at: https://ninjas.cl/blog/odin-s-elixir/

What is Odin?

Odin is a system level language that is a direct alternative to Rust, Zig or C. Creating an alternative to C language is nearly an impossible task, because more than 40 years of history of C. But at least a new programming language can be an alternative to C in modern systems and architectures, as the website says "Odin is the C alternative for the Joy of Programming". The official implementation of Odin currently supports: amd64, arm64/aarch64 (Rapsberry Pi), and wasm32/wasm64p32. The language borrows heavily from: Pascal, C, Go, Oberon-2, Newsqueak, GLSL.

What are the guiding principles behind the design of Odin?

Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming.

Simplicity and readability.
Minimal: there ought to be one way to write something.
Striving for orthogonality.
Programs are about transforming data into other forms of data.
Code is about expressing algorithms—not the type system.
There is embedded knowledge and wisdom in older programming languages.
The entire language specification should be possible to be memorized by a mere mortal.

Hello World in Odin

package main

import "core:fmt"

main :: proc() {
    fmt.println("Hellope!")
}

Fibonacci

fibonacci :: proc(n: int) -> int {
    switch {
        case n < 1:
            return 0
        case n == 1:
            return 1
    }
    return fibonacci(n-1) + fibonacci(n-2)
}

fmt.println(fibonacci(3)) // 2

Odin's Elixir?

Odin and Elixir is a match made in Valhalla. With Elixir we can create robust and reliable systems and with Odin we can create powerful and secure low level extensions with FFI, or self contained terminal applications and libraries that can be shared with other programming languages, instead of using alternatives such as C, Rust, Zig or Go.

This is a video how to integrate Odin and Elixir:

Elixir (2011) and Odin (2016), despite the fact that they are very modern languages, are quite small. You can read through the language guide in a few hours and have a pretty good grasp on the core concepts. This leads to much quicker mastery.

Treasure Hunt

Let's do a simple exercise with CRC (Constructors, Reducers and Converters) a principle of code organization made by Bruce Tate.

Constructors: Are procedures (or functions) that creates and sets data structures that will be passed down to Reducers and Converters. This data structure is known as the accumulator or token.
Reducers: These procedures take the accumulator and "reduce it", applying a pipeline of different operations and procedures until it reaches a state ready for the Converter.
Converter: Takes the accumulator and "convert it" to a final format, that is ready for displaying to the user or pass it to another pipeline of CRC. Example would be a procedure that takes a json data structure and convert it to string, this string will be passed down to the pipeline for saving the contents to a file in disk.

Thanks to this form of organization, we can see our code in a coherent and unified way. By having a common data structure with several procedures (or functions), we can perform operations and express ourselves with greater readability. Our systems will be easier to understand and maintain in the future. Consistency is an important quality factor in our systems and using CRC is a great tool to achieve that. The really valuable idea in this principle is that it's extremely handy if you can clearly separate procedures that change state from those that don't. This is because you can use creators procedures in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with reducers and converters.

Elixir Version

defmodule Treasure do
  # Creator
  def new(x, y), do: {x, y}
  def new, do: new(0, 0)

  # Reducers
  def north({x, y}), do: {x, y - 1}
  def south({x, y}), do: {x, y + 1}

  def east({x, y}), do: {x - 1, y}
  def west({x, y}), do: {x + 1, y}

  # Converter
  def show({x, y}), do: "The treasure is located at (#{x},#{y})"
end


Treasure.new()
|> north()
|> north()
|> north()
|> north()
|> west()
|> west()
|> west()
|> south()
|> east()
|> east()
|> east()
|> show() # The treasure is located at (0,-3)

Odin Version 1

package CRC

import "core:fmt"

Treasure :: struct {
    x: int,
    y: int
}

// Constructors
new :: proc(x: int, y: int) -> Treasure {
    treasure : Treasure
    treasure.x = x
    treasure.y = y
    return treasure
}

empty :: proc() -> Treasure {
    return new(0, 0)
}

// Reducers
north :: proc(treasure : Treasure) -> Treasure {
    return new(treasure.x, treasure.y - 1)
}

south :: proc(treasure : Treasure) -> Treasure {
    return new(treasure.x, treasure.y + 1)
}

east :: proc(treasure : Treasure) -> Treasure {
    return new(treasure.x - 1, treasure.y)
}

west :: proc(treasure : Treasure) -> Treasure {
    return new(treasure.x + 1, treasure.y)
}

// Converter
show :: proc (treasure : Treasure) -> (string, int, int) {
    return "The treasure is located at (%d, %d)", treasure.x, treasure.y
}

// Pipeline
main :: proc() {
    treasure := empty() // (0, 0)
    treasure = north(treasure) // (0, -1)
    treasure = north(treasure) // (0, -2)
    treasure = north(treasure) // (0, -3)
    treasure = north(treasure) // (0, -4)
    treasure = west(treasure)  // (1, -4)
    treasure = west(treasure)  // (2, -4)
    treasure = west(treasure)  // (3, -4)
    treasure = south(treasure) // (3, -3)
    treasure = east(treasure)  // (2, -3)
    treasure = east(treasure)  // (1, -3)
    treasure = east(treasure)  // (0, -3)
    out, x, y := show(treasure)
    fmt.printfln(out, x, y) // The treasure is at (0, -3)
}

Odin Version 2

Odin provides another interesting way of approaching this challenge. This is using Array programming techniques where basic operations (+, -, *, etc.) on two fixed-size arrays of the same length are done element-wise. One of the goodies of Odin.

Treasure :: [2]int

NORTH :: Treasure{ 0, -1}
SOUTH :: Treasure{ 0, +1}
EAST  :: Treasure{-1,  0}
WEST  :: Treasure{+1,  0}

treasure := \
    NORTH + // (0, -1)
    NORTH + // (0, -2)
    NORTH + // (0, -3)
    NORTH + // (0, -4)
    WEST +  // (1, -4)
    WEST +  // (2, -4)
    WEST +  // (3, -4)
    SOUTH + // (3, -3)
    EAST +  // (2, -3)
    EAST +  // (1, -3)
    EAST    // (0, -3)

This have the strong advantage that if something like a string is used instead of numbers to generate the treasure map, it won't compile. The validation is then at compiler level instead of at runtime.

Final Thoughts

Odin and Elixir provides powerful tools to create robust systems, low level, bindings and perfomant code. Any Elixir developer would benefit learning Odin and any Odin developer would benefit learning Elixir.

Odin and Elixir is truly a match made in Valhalla.

Image from: https://commons.wikimedia.org/wiki/File:Odin_und_Saga.jpg

¿Trabajo Remoto o Híbrido?

Camilo — Wed, 03 Jul 2024 16:42:00 +0000

Este es un pequeño artículo sobre reflexiones sobre los llamados trabajos "Híbridos" y la necesidad de establecer una definición adecuada para no confundir.

Trabajo Presencial

Primero tendremos el trabajo presencial, el cual estás obligado a ir a una oficina o lugar específico para ejercer tus labores. En la pandemia del 2020 vimos un cambio hacia lo remoto. Los primeros años de la década del 2020 demostraron que si se puede trabajar remotamente para gran parte de las labores tech.

Trabajo Híbrido

Luego de la pandemia comenzaron a surgir los llamados trabajos "híbridos". Hay una clara mal interpretación de lo que es trabajo Híbrido. Se puede asumir de que "Algunos días remoto y algunos días presencial", pero esto causa confusión.

La definición que propongo híbrido es lo siguiente:

Se trabaja en un horario y zona horaria específica.
Se tiene a disposición una oficina pero es opcional asistir.
Es obligación estar dentro de un territorio (Por ejemplo dentro de Chile, por temas legales, tributarios y otros).

En términos simples, si te obligan a ir presencial entonces es un trabajo presencial y no híbrido.

Trabajo Remoto

El trabajo remoto es similar al híbrido con la salvedad de que puede ser en cualquier parte del mundo o zona horaria, no tienes la obligación de estar en el mismo país donde esta el trabajo.

Es más pensado para ofertas laborales en el extranjero donde tu debas pagar tus propias cotizaciones, previsión de salud y pagar los costes de transferencias.

¿Por qué es importante?

Muchas personas dicen que les gusta ir a la oficina por diversos motivos. Se confunde muchas veces trabajar remotamente con trabajar desde casa. Lo cual es erróneo. Trabajar remoto simplemente significa que tienes la libertad de trabajar donde sea más cómodo. Puede incluso ser una oficina, pero la clave es la libertad de elección donde se trabaja. Es por esto que muchos defienden el ir presencial a una oficina y privilegian por sobre la opción remota. El drama es que no debería ser obligatorio ir a la oficina en un trabajo híbrido, es opcional y no habría problemas si deseas trabajar fuera de ella todo el tiempo. La oficina se transforma en un espacio de cowork opcional más que un lugar de sometimiento y esclavitud a horarios y expectativas de calentar sillas.

Piensa todas las horas de vida que pierdes solo por ir a un lugar obligado, costos en salud mental, costos de alimentación y transporte. Costos que asumes personalmente y no la empresa.

Que tu relación laboral sea de mutuo beneficio y no unilateral para la empresa.

Como profesionales de la tecnología está en nuestro poder exigir este beneficio a las empresas. Si nos sometemos el ir presencial obligadamente, afectaremos tanto a nuestra salud mental como a los seres queridos que tenemos y principalmente afectamos a la industria en general haciendo más fome las condiciones laborales para todos los miembros del oficio.

Conclusión

Prioriza tu vida y tu salud mental y financiera, prefiere siempre trabajos donde sea opcional ir presencial.

Imagen: https://commons.wikimedia.org/wiki/File:Remote_work_Telelavoro_1.jpg

Super Club Net: Libro de Introducción a HTML, CSS y JS

Camilo — Tue, 25 Jun 2024 16:12:00 +0000

Con motivo de dar honor a la revista Club Nintendo y su mini curso de HTML.

La revista Club Nintendo y su curso de HTML

Camilo for JavaScript Chile ・ Jun 8 '24

#html #clubnintendo #principiante #chile

He elaborado este pequeño libro actualizando y ampliando los conceptos vistos en esa revista.

Un libro gratuito que puede ser leído en los siguientes sitios web:

Contenidos

HTML y CSS básico.
JavaScript básico.
Manipulación de DOM.
Formularios y validación.
Tips y recomendaciones.

Una escritura amena y con ejemplos basados en juegos de Nintendo 64. Incluye un proyecto para ejercitar con temática de Mario Kart 64.

Pensado para personas que recién inician en el mundo HTML y quizás para alguien que quiera refrescar conceptos.

Hecho con mucho amor por Ninjas.cl para todo aquel con curiosidad y paciencia de aprender HTML, CSS y JS para desarrollo web :)

Desafío de Nombres y Apellidos

Camilo — Tue, 11 Jun 2024 19:29:00 +0000

El siguiente es un pequeño ejercicio encontrado en el curso de Haskell
disponible en la Universidad de Helsinki.

Desafío

Dado una lista de nombres y apellidos:

Nombres: ["Eva", "Mike"]
Apellidos: ["Smith", "Wood", "Odd"]

Retornar una lista cuyos elementos sean solo de personas con largo par.

Ejemplo de Retorno

["EvaSmith", "EvaOdd", "MikeWood"]

Solución en Haskell

Haskell permite pattern matching y list comprehensions.

[whole | first <- ["Eva", "Mike"],
         last <- ["Smith", "Wood", "Odd"],
         let whole = first ++ last,
         even (length whole)]

Solución en Elixir

Si bien la solución en Elixir no es tan corta como en Haskell
es igual de elegante.

require Integer

for first <- ~w[Eva Mike],
  last <- ~w[Smith Wood Odd],
  name <- [first <> last],
  name
  |> String.length()
  |> Integer.is_even(), do: name

Para esto utilizamos las características de for comprehensions.

https://elixirschool.com/en/lessons/basics/comprehensions

Solución en Javascript

David de Javascript Chile nos escribe una solución en versión
imperativa y declarativa utilizando Javascript.

Imperativa

const nombres = ["Eva", "Mike"];
const apellidos = ["Smith", "Wood", "Odd"];

const output = [];

for(let i = 0; i < nombres.length; i++){
    for(let j = 0; j < apellidos.length; j++){
        const fullName = `${nombres[i]}${apellidos[j]}`;
        if(fullName.length % 2 == 0){
            output.push(fullName);
        }
    }
}

Declarativa

const nombres = ["Eva", "Mike"];
const apellidos = ["Smith", "Wood", "Odd"];

const output = nombres.flatMap(n =>
        apellidos.map(a => `${n}${a}`)
    )
    .filter(fullName => fullName.length % 2 == 0);

Elixir

La versión declarativa de Javascript la podríamos emular en Elixir de la siguiente
forma:

~w[Eva Mike]
|> Enum.flat_map(fn first ->
  ~w[Smith Wood Odd]
  |> Enum.map(fn last ->
    first <> last
  end)
end)
|> Enum.filter(&
    &1
    |> String.length()
    |> Integer.is_even()
)

Aunque no es tan elegante como usar for comprehensions.

¿En qué otros lenguajes puedes solucionar el desafío?

La revista Club Nintendo y su curso de HTML

Camilo — Sat, 08 Jun 2024 17:47:00 +0000

Quiero compartir el curso que inicio mi interés por la informática.
El curso de HTML de la revista Club Nintendo. Encontré los escaneos de la versión
mexicana, aunque yo leí la edición chilena. El contenido es el mismo.

Primera Parte

https://archive.org/embed/club-nintendo-ano-06-no-05-mexico

Página 44. Introducción al HTML.
Etiquetas básicas como <h1>, <img> y los colores hexadecimales. Tablas y listas.

Conceptos

Segunda Parte

https://archive.org/embed/club-nintendo-ano-06-no-10-mexico

Página 44. Mapas de imagenes. Frames, enlaces.

Conceptos

Tercera Parte (final)

https://archive.org/embed/club-nintendo-ano-06-no-11-mexico

Página 52. Formularios y un poquito de Javascript.

Conceptos

Experiencia personal

Personalmente yo tenía 8 años y estaba en segundo básico (Mayo de 1997), no hace mucho había aprendido a leer y escribir. Mi padre trajo a la casa un viejo computador con Windows 3.1 que habían dado de baja en su trabajo y me sirvió para practicar las cosas de la revista, aunque principalmente lo usaba para jugar juegos de DOS
y aprender a escribir con el teclado, con eso también aprendí los comandos básicos de terminal como crear carpetas, copiar y borrar archivos y esas cosas del DOS.

Mi padre era más de Excel y Word, así que tuve que aprender todas esas cosas viendo y experimentando por mi cuenta.

Aunque no tuvimos internet en la casa como hasta el 2004, pude ir a su trabajo y descargar cosas y más tutoriales.

Luego de eso también me trajo un libro fotocopiado de Visual Basic 6, donde también aprendí armar programas de escritorio, aunque super básicos.

Terminaré este pequeño post con las mismas palabras del curso de HTML de la revista Club Nintendo:

Ojalá que estos 3 cursos de HTML. te sirvan y que despierten tu interés por aprender más. Si es así, existen libros muy buenos de programación de otros lenguajes para usarse en Internet.

Historia de la BeamVM

Camilo — Thu, 06 Jun 2024 16:00:00 +0000

¿Qué es Erlang?

Erlang es un lenguaje de programación funcional. Esto quiere decir que se basa en los principios de funciones con transparencia referencial e inmutabilidad. La transparencia referencial quiere decir que una función con los mismos parámetros debería retornar el mismo resultado. La inmutabilidad quiere decir que no puedo alterar el valor de una variable una vez que se ha asignado, por ejemplo si digo que x es 5, no es lógico que también sea 6 (sería deshonesto). Sin embargo existen casos donde una función puede retornar otro resultado con los mismos parámetros (por ejemplo una función de la fecha actual). Erlang usa un enfoque pragmático: Obedecer los principios de la programación funcional (inmutabilidad, transparencia referencial) y romperlos cuando aparecen conflictos del mundo real.

Además del lenguaje de programación, Erlang tiene todo un ecosistema de herramientas. En primer lugar se encuentra su máquina virtual (BEAM VM), la cual ejecuta código compilado con un bytecode específico, muy similar a la JVM de Java. Por lo que el código puede ser ejecutado en cualquier sistema para la cual la BEAM VM sea compatible. También proporciona herramientas de desarrollo como compiladores, debuggers, herramientas para análisis de rendimiento y pruebas. El framework OTP, servidores web, generadores de analizadores de código fuente (parsers), una base de datos distribuida llamada mnesia, entre otras herramientas. La máquina virtual y sus bibliotecas permiten actualizar el código en caliente (hot reload), lo que significa cambiar el código durante la ejecución del programa sin interrupción del servicio y también permitir la ejecución del código de forma distribuida en varias computadoras, manejando los errores y fallos de una forma simple y poderosa.

Todas estas características permiten una habilidad de Erlang para la resiliencia frente a errores y organización del código en procesos y mensajes concurrentes.

Origen de Erlang

Erlang comenzó como una biblioteca de Prolog, luego como un dialecto de Prolog, para finalmente ser un lenguaje de programación por si mismo. El objetivo fue resolver el problema de construir sistemas distribuidos robustos y confiables. Desarrollado originalmente en la empresa de telecomunicaciones Ericsson para sus switch telefónicos. Desde un inicio se enfrentaron a desafíos de escala mundial como cientos de milllones de usuarios y condiciones de servicio muy estrictas. Fue liberado al público en 1998 como un proyecto Open Source. Hoy en día, según Cisco, el 90% del tráfico de internet es orquestado por nodos programados en Erlang.

// Detect dark theme var iframe = document.getElementById('tweet-1002494428748140544-407'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1002494428748140544&theme=dark" }

Erlang y la BEAM VM han evolucionado a lo largo de más de 30 años para otros casos de uso como la robótica, machine learning, aplicaciones web, entre otros. Uno de sus creadores principales Joe Armstrong lo detalla de la siguiente forma:

Erlang fue diseñado para escribir programas concurrentes que se ejecutasen eternamente. Erlang usa procesos concurrentes para estructurar el programa. Estos procesos no tienen memoria compartida y se comunican por paso de mensajes asíncronos. Los procesos de Erlang son ligeros y pertenecen al lenguaje, no al sistema operativo. Erlang tiene mecanismos que permiten que los programas cambien on-the-fly (en vivo) así, esos programas pueden evolucionar y cambiar sin detener su ejecución. Estos mecanismos simplifican la construcción de software implementando sistemas non-stop (que no se detienen).

El desarrollo inicial de Erlang tuvo lugar en 1986 en el Laboratorio de Computación de Ericsson. Erlang fue diseñado con un objetivo específico en mente: proporcionar una mejor forma de programar aplicaciones de telefonía. En ese momento, las aplicaciones de telefonía eran atípicas del tipo de problemas que podían resolver los lenguajes de programación convencionales. Las aplicaciones de telefonía son, por su naturaleza, altamente concurrentes: un simple switch debe manejar decenas o cientos de miles de transacciones simultáneas. Tales transacciones son intrínsecamente distribuidas y el software se espera que sea altamente tolerante a fallos. Cuando el software que controla los teléfonos falla, sale en los periódicos, algo que no ocurre cuando fallan las aplicaciones de escritorio. El software de telefonía debe también cambiar on-the-fly, esto es, sin perder el servicio mientras se realiza una actualización del código. El software de telefonía debe también operar en tiempo real, con ajustados requisitos de tiempo para algunas operaciones, y más relajado tiempo en otras clases de operaciones.

¿Por qué Erlang es Bueno?

Joe Armstrong, fijó los requisitos de Erlang en solucionar los problemas de un entorno altamente concurrente, que no puede permitirse caer y que debe de actualizarse sin pérdida de servicio. Actualmente, esta definición calza con casi la mayor parte de servicios en Internet.

Sin embargo pensar de que Erlang solamente es para casos de uso de procesos y mensajes livianos y concurrentes es insuficiente para describirlo. En su tésis de doctorado Joe Armstrong detalla componentes genéricos llamados "behaviours" (comportamientos) en Erlang. Estos "behaviours" son similares a las interfaces en otros lenguajes de programación y permiten el polimorfismo, es decir, que los programas puedan trabajar con múltiples formas.

Joe Armstrong detalló seis distintos behaviours gen_server, gen_event, gen_fsm (gen_statem), supervisor, application y release. Definió que estos seis behaviours eran suficientes para crear sistemas distribuidos confiables y robustos.

Los behaviours son escritos por expertos y están basados en años de experiencia y representan las "mejores prácticas". Permiten que los programadores de la aplicación se enfoquen en la "lógica de negocios", mientras que la infraestructura es proporcionada automáticamente por el behaviour. El código es escrito de forma secuencial y toda la concurrencia es realizada por el behaviour "por debajo". Esto facilita que nuevos miembros del equipo aprendan la lógica de negocios, ya que es secuencial y es similar a cómo operan otros lenguajes de programación.

La siguiente lista es una breve descripción de cada behaviour.

gen_server: Un servidor genérico. Permite crear un servicio que puede recibir llamadas.
gen_event: Un gestor de eventos. Permite enviar mensajes cuando ocurren eventos definidos.
gen_statem: Una máquina de estados, anteriormente conocida como gen_fsm. Permite validar estados de los datos.
supervisor: Un supervisor es un proceso cuya tarea es que otros procesos (hijos) esten vivos y realizando su labor. Con múltiples estrategias para reiniciarlos si estos fallan. Un supervisor puede ser padre de otros supervisores.
application: Una aplicación es un conjunto de componentes gen_server, gen_event, gen_statem y supervisor utilizados para un fin. Se le llama "árbol de supervisión" (supervision tree).
release: Un sistema puede contener una o múltiples application, lo que se considera un release. Además proporciona herramientas para actualizar el código y volver a un estado anterior (rollback) si la actualización falla.

Si se tiene en cuenta que un supervisor puede supervisar a otros supervisores (los cuales pueden estar ejecutándose en otro computador), nos da una idea de lo poderoso que pueden ser los behaviour. Se podría hacer un paralelo con Kubernetes, pero la principal diferencia es que estos behaviours son ejecutados a nivel del proceso/hilo a diferencia de Kubernetes que se ejecuta a nivel del contenedor Docker.

Las ideas de los supervisores y las estrategias de reinicio vienen de la observación de que usualmente es más simple reiniciar un servicio para solucionar un problema. ¿Has probado apagar y prender un equipo para solucionar un problema?. Esto se puede explicar con un ejemplo: Si estoy siguiendo la ruta de un mapa y me pierdo, es más simple partir del punto inicial que desde donde me perdí para llegar a la meta, es decir, en vez de encontrar el error y repararlo sobre la marcha, es más rápido y correcto registrar el error y volver al inicio para intentarlo de nuevo.

Saber que los procesos pueden fallar y serán reiniciados por un supervisor nos permite fallar temprano y rápido (Siguiendo las recomendaciones de Jim Gray). Un proceso produce un resultado correcto según la especificación o envía una señal de fallo y se detiene su operación. "Let it crash!" (Déjalo caer) es una frase acuñada por Joe Armstrong para denominar este comportamiento de "camino feliz", donde si ocurre algo fuera del "camino feliz", el proceso debe detenerse y no tratar de solucionar el problema sobre la marcha (potencialmente empeorando la situación), dejando que otro componente dentro del árbol de supervisión maneje el error.

Los supervisores y la filosofía de "Let it Crash!" de Erlang le permiten producir sistemas robustos y confiables. Se puede ejemplificar con la máquina Ericsson AXD301, la cual alcanzó nueve nueves (99.9999999%) de fiabilidad en sus sistemas. Para poner en perspectiva la fiabilidad de cinco nueves (99.999%) se considera bueno (5.26 minutos de servicio caido por año). En grandes compañias se estima que existe 1.6 horas de servicio caido por semana. Nueve nueves de fiabilidad es como un parpadeo al año de servicio caido (31.56 milisegundos al año). Si bien los nueve nueves fueron alcanzados en una situación específica y no hay claridad total de cómo se obtuvieron dichos datos, se puede afirmar que la tecnología de Erlang da una fiabilidad y robustes muy grande.

El modelo de Actores

Se ha definido Erlang y su ecosistema, pero para tener una noción más íntegra se debe explicar lo que es concurrencia. En muchos lugares se puede considerar concurrencia y paralelismo como el mismo concepto. En Erlang son dos ideas separadas. La concurrencia se refiere a la idea de actores ejecutandose de forma independiente, pero no necesariamente al mismo tiempo. El paralelismo es tener actores independientes ejecutandose al mismo tiempo. Si lo vemos a nivel de procesador, concurrencia es que cada proceso tiene su tiempo de ejecución en un único procesador, similar a como funcionaban los sistemas antes de la existencia de múltiples núcleos en los procesadores. El paralelismo ha estado disponible desde el inicio de Erlang, simplemente era necesario un computador anexo y conectado al computador principal. En la actualidad los procesadores con múltiples núcleos permiten paralelismo en un único computador (en contextos industriales llegando a docenas de núcleos por procesador) y Erlang permite aprovechar estas características completamente (desde aproximadamente el año 2009 con la implementación del multiprocesamiento simétrico).

Para lograr la concurrencia Erlang utiliza el modelo de actores. Cada actor es un proceso separado (función) y aislado en la máquina virtual y se comunican utilizando mensajes. Cada proceso (actor) es totalmente independiente y no comparte ninguna información con otros procesos, solamente utilizan mensajes entre ellos para comunicar datos. Son livianos (no son procesos del sistema operativo). Toda la comunicación es explícita, segura y con alta trazabilidad. Si un proceso falla, no afectará a los otros procesos, ya que son totalmente independientes entre si.

Una cosa importante a considerar en relación a las habilidades de escalamiento de Erlang y sus procesos ligeros. Es cierto que pueden tener cientos de miles de procesos existentes al mismo tiempo, pero no significa abusar de ellos. Por ejemplo crear un videojuego de disparos en los que cada bala sea su propio actor es algo excesivo. Ya que hay un pequeño costo en enviar mensajes entre actores, si se dividen las tareas demasiado puede incluso perjudicar el rendimiento.

Se puede pensar de que la programación paralela es directamente proporcional a la cantidad de núcleos de un procesador, lo que se conoce como escalamiento lineal. Pero es importante recordar de que no existe algo perfecto y libre de costos asociados. El paralelismo no es la respuesta a cada problema, en algunos casos incluso puede afectar la velocidad de la aplicación, por ejemplo cuando existen tareas redundantes o el código es 100% secuencial pero intenta utilizar procesos paralelos. Un programa en paralelo va tan rápido como su parte secuencial más lenta. Esto significa que usar paralelismo para todos los problemas no garantiza que sea más rápido. Simplemente es una herramienta que puede ser muy útil, pero no siempre es la adecuada.

Conclusión

Quizás se ha encontrado con una situación similar a la siguiente: Mi sistema es local y no necesito de las capacidades de concurrencia que Erlang proporciona. Jamás llegaré a los niveles de exigencia en mis sistemas que justifiquen utilizar dichas capacidades.

Se podría pensar de que al tener sistemas de nicho nunca tendremos la necesidad de usar las bondades de la BEAM VM. ¿Pero qué pasa si tenemos una cantidad de datos enorme que debe ser procesada?.

Esto sucedió en una empresa donde debían migrar una base de datos de usuarios a un nuevo sistema. Se debían procesar las tablas y ajustarlas al formato del nuevo sistema, es decir, se debía crear un pequeño script ETL (Extract Transform Load) para extraer, transformar y cargar datos. En un inicio un programador que solamente conocía Python intentó realizar la migración, pero debido a la cantidad de datos la operación tomaba más de una semana en completar. Luego la tarea pasó a un equipo que conocía Elixir y la operación tardó menos de un día en ser completada, gracias a las bondades de concurrencia y paralelismo de la Beam VM.
Se puede argumentar de que tal ves era inexperiencia en Python o no se usaron las herramientas adecuadas en dicho lenguaje. Pero eso nos habla de que realizar concurrencia y paralelismo en otros lenguajes no es tan simple como en el ecosistema de Erlang.

Si bien todas estas herramientas e ideas podrían ser implementadas y desarrolladas en otros lenguajes de programación y ecosistemas (y viceversa). No es una tarea sencilla y tampoco se contaría con más de 30 años de evolución funcionando en sistemas productivos de clase mundial. Por lo que la máquina virtual de Erlang (BEAM VM) es una tecnología robusta, confiable y acertada para ser usada en las soluciones de software actuales. Se debe evaluar cada problema y seleccionar las herramientas adecuadas según su contexto.

Referencias

Introducción a Elixir

Camilo — Wed, 22 May 2024 16:21:00 +0000

¿Se han preguntado que és lo que hace genial a un lenguaje de programación?. Una de las razones por la que Elixir es genial es su consistencia. José Valim tomó ideas de otros lenguajes de programación como Ruby y Erlang, ideas que han sido desarrolladas por más de 30 años y las hizo mucho más consistentes. 30 años de ideas pensadas para diferentes propósitos por diferentes personas condensadas en una serie de bibliotecas mucho más rápidas de usar y entender.

Elixir se ejecuta en la máquina virtual BEAM, una VM realmente antigua, ya que fue creada por Ericsson en 1986 para el lenguaje Erlang (Más antigua que Java). Estas tecnologías fueron las principales protagonistas de las aplicaciones en un entorno de telecomunicaciones que manejan innumerables solicitudes por segundo de una manera confiable y eficiente.

Unas décadas más tarde, esta VM fue considerada por José Valim, quien creó el lenguaje Elixir a mediados de 2011 para utilizar todo el poder de BEAM en un lenguaje moderno y enfocado en la experiencia de desarrollo. Este lenguaje también fue responsable de la popularización de la máquina virtual de Erlang.

Un pequeño vistazo de Elixir

booleano = true || false
numero = 123_456
string = "Un binario" <> "Concatenada" <> "Interpolación #{numero}"
char = ?A
atomo = :un_atomo
funcion = fn _ -> "Hola" end
mapa = %{valor: "hola"}
tupla = {:ok, 1234}
lista = [1, "dos", :tres]
keyword_list = [valor: "hola"]
IO.inspect("Imprimir en Terminal")
# Comentario
_ # variable placeholder
_var # variable omitida

defmodule MiModulo do

  @atributo "Un atributo del módulo"

  # Retorno el resultado de la última expresion
  def mi_funcion_publica(parametro \\ true) do
    "Función Pública con #{parametro}"
  end

  # Pattern matching selecciona cual ejecutar según la firma de la función
  def mi_funcion_publica() do
    "Función Pública Sin parámetros"
  end

  defp mi_funcion_privada() do
    "Función Privada"
  end
end

MiModulo.mi_funcion_publica()

¿Qué significa Consistencia?

La palabra consistencia se puede definir según la RAE como:

f. Duración, estabilidad, solidez.
f. Trabazón, coherencia entre las partículas de una masa o los elementos de un conjunto.

Adicionalmente definiremos coherencia:

f. Conexión, relación o unión de unas cosas con otras.

Así como cohesión:

f. Fís. Fuerza de atracción que mantiene unidas las moléculas de un cuerpo.

En el desarrollo de software los componentes que utilizamos para elaborar el sistema idealmente deben ser consistentes, coherentes y cohesivos, es decir, que tengan una armonía y sean una base sólida para facilitar la mantención e implementación de los requisitos del sistema.

Ejemplos de Inconsistencias

En otras tecnologías podemos encontrar inconsistencias.

Inconsistencias en la API

PHP es un gran ejemplo de inconsistencias en su biblioteca oficial de funciones.
Por ejemplo notemos como las diferencias entre las funciones str_replace y strpos. Ambas funciones para trabajar con strings.

El nombre es inconsistente, la primera utiliza guión bajo para separar str_ y la otra no.
El nombre de los parámetros es incosistente. $search y $haystack son equivalentes.

 str_replace(
    mixed $search,
    mixed $replace,
    mixed $subject,
    int &$count = ?
): mixed

strpos(string $haystack, string $needle, int $offset = 0): int|false

Además la función strpos puede retornar un valor que sea un entero, pero podría ser considerado falso (0).
Por lo que debería usar el operador === para verificar el real valor de retorno.

En Elixir se podría utilizar un retorno de tuplas {:ok, pos} y {:error, motivo}
y utilizar pattern matching, simplificando las validaciones.

Inconsistencias en los Datos

En otros lenguajes de programación una fuente de inconsistencias es la mutabilidad de sus estructuras de datos. Elixir al ser un lenguaje funcional trabaja con estructuras inmutables que permiten una consistencia en los datos.

El siguiente ejemplo escrito en Python, nos muestra los problemas de inconsistencias en lenguajes de programación con estructuras de datos mutables.

mapa = {
  'lista': [1,2,3],
  'numero': 10
}

lista = mapa['lista']
numero = mapa['numero']

lista += [4]
numero += 10

print(lista)
# [1, 2, 3, 4]

print(numero)
# 20

print(mapa)
# {'lista': [1, 2, 3, 4], 'numero': 10}

Hemos modificado la variable lista y numero, pero sin embargo la variable mapa fue afectada. Esto es debido a que lista fue accedido por referencia y numero accedido por valor.

En Elixir eso no pasa, gracias a su inmutabilidad. Podemos trabajar con las variables lista y numero sin miedo a alterar el valor de la variable mapa.

mapa = %{
  lista: [1, 2, 3],
  numero: 10
}

lista = mapa.lista
numero = mapa.numero

lista = lista ++ [4]
numero = numero + 10

IO.inspect(lista)
# [1, 2, 3, 4]

IO.inspect(numero)
# 20

IO.inspect(mapa)
# %{lista: [1, 2, 3], numero: 10}

https://en.wikipedia.org/wiki/Functional_programming

Las diferencias con lenguajes OOP

Acoplamiento en la OOP

Los objetos son el acomplamiento de tres componentes: Comportamiento, Estado y Mutabilidad (cambios en el tiempo). Cada vez que se crea un objeto se obtiene una entidad que acopla esos tres componentes. Este acoplamiento causa muchas veces problemas, ¿Cómo puedo solamente utilizar uno de los componentes?.

Una de las mayores fuentes de problemas es la herencia entre objetos. Si por ejemplo tenemos un objeto que tiene acoplado estado y comportamientos, luego deseo añadir más comportamientos, debo recurrir a la herencia. Los objetos por definición existen para encapsular un estado, para modificar el estado debo interactuar con el objeto. Al utilizar herencia se tiene un mecanismo que permite adulterar el estado directamente, invalidando al objeto. Es así como algunos lenguajes de programación incluyen operadores como protected, final, entre otros para controlar la visibilidad de lo que se supone no debería tener acceso.

Básicamente existe un problema cuya solución crea otros problemas, sin incluir cosas como la herencia múltiple. Todo esto debido al acomplamiento inherente de la orientación a objetos.

La Programación Orientada a Objetos (POO) no se trata de crear una taxonomía gigante con una compleja jerarquía de objetos. El uso desmedido de la sintaxis del punto (objeto.metodo()) es una consecuencia de esa mala interpretación. La POO se trata de tener objetos que parpean como un pato, pero no necesariamente son un pato (quack like a duck, but is not a duck). Hay una gran confusión acerca de que en la POO solo existen métodos y no funciones. Hasta Smalltalk (padre de la POO) hay funciones (escondidas bajo una sintaxis especial).

En el conocido libro del Design Patterns: Elements of Reusable Object-Oriented Software mencionan: "Preferir la composición por sobre la herencia".

Los lenguajes funcionales como Haskell, Lisp y Elixir han estado resolviendo problemas complejos sin recurrir a la herencia. Mientras que los lenguajes orientados a objetos pueden utilizar la composición gracias a las interfaces. Ya que las interfaces son un mecanismo de polimorfismo, es decir, que nos permiten trabajar con múltiples formas a través de un contrato pre-establecido.

Los Componentes de Elixir

En Elixir existe comportamiento (Módulos), estado (Datos) y una visión de mutabilidad (Procesos), pero no están acoplados. Lo que nos permite elaborar software utilizando solamente el componente requerido, sin incurrir en los problemas ocasionados por el acoplamiento de la POO. Elixir dispone de tres dimensiones para realizar sistemas, a diferencia de la POO que solamente cuenta con una. Por lo que puede tener un polimorfismo distinto en cada componente (Behaviours, Protocols, Messages).

En el libro Concepts, Techniques, and Models of Computer Programming mencionan la regla de lo menos expresivo. "Cuando se programa un componente, el modelo computacional correcto para lograr un programa natural es el menos expresivo posible". Lo que se puede simplificar como "utilizar la abstracción más simple posible para resolver el problema".

Ejemplo de Acoplamiento

Vamos por un ejemplo simple comparando la forma de contar caracteres en un string.

El siguiente es un ejemplo en Ruby.

"Hola".length
# 4

En Elixir la misma operación sería:

String.length("Hola")
# 4

En Ruby el string "Hola" es un objeto que además de tener
la estructura de datos, tiene una serie de comportamientos asociados.
Esta altamente acoplado.

En cambio en Elixir el string "Hola" solamente es un dato
que no tiene comportamientos. Para poder realizar operaciones
debemos utilizar las funciones del módulo String. Existe
un desacople entre datos y comportamientos.

¿Por qué es importante este desacople?

Veamos un ejemplo. Si asignamos una variable a "Hola",
con el tiempo podemos cambiar el contenido de la variable
y ya no podremos utilizar el método asociado a los tipos string.

variable = "Hola"
variable.length
# 4

variable = 1
variable.length
# (irb):4:in `<main>': undefined method `length' for an instance of Integer (NoMethodError)

Esto puede ser un problema, sobre todo si existe una jerarquía de herencias y combinado con la mutabilidad del lenguaje, es una receta para el caos y soluciones poco elegantes si no se maneja adecuadamente los riesgos.

En Elixir al estar totalmente desacoplados dato, comportamiento y cambios de estado, se puede asegurar productos de software libres de problemas asociados a jerarquías de herencias y mutabilidad.

Pattern Matching

Esta técnica propia de los lenguajes funcionales, se utiliza para buscar patrones y decidir qué hacer en cada momento. Debemos pensar en el operador = no como un signo igual típico de otros lenguajes, sino como el que nos encontramos en una función matemática del tipo x = a + 1. Es decir que estamos diciendo que x y a + 1 tienen el mismo valor.

# a = 1
# b = "elixir"
# c = "ninjas"
{a, b, c} = {1, "elixir", "ninjas"}

https://joyofelixir.com/6-pattern-matching

El Operador Pipe

Los sistemas operativos inspirados por Unix vienen usando Pipelines desde sus inicios.
En este ejemplo, listamos el contenido del directorio, filtramos solo las líneas que contienen "archivo.txt", y redirigimos la salida a un archivo llamado resultado.txt.

ls -l | grep "archivo.txt" > resultado.txt

https://www.swhosting.com/es/comunidad/manual/uso-de-pipes-en-sistemas-unix

En el caso de Elixir, el operador pipe (tubería) |> es una hermosa herramienta que nos permite expresar una cadena de funciones como una secuencia de acciones.

Aún si no has usado Elixir podrías entender la lógica del siguiente código.

parametros_formulario
|> validar_formulario()
|> insertar_usuario()
|> crear_reporte()
|> mostrar_resultado()

Utilizar una serie de operadores pipe se conoce como un pipeline. Es simple de leer y comprender lo que ocurre. Pero por su simpleza también tiene algunas limitaciones. Debido a que las funciones están encadenadas, dependen del resultado anterior. Si alguna de las funciones falla quebraría el flujo completo. No se puede hacer mucho frente a esto a menos que se maneje los casos de error en cada función.

https://blog.appsignal.com/2022/07/19/writing-predictable-elixir-code-with-reducers.html

En Elixir Todo es un Reductor (Reducer)

Primero partiremos explicando los conceptos de acumulador y reductor.

Acumulador

Un acumulador es una variable que durante la ejecución de un programa va referenciar así misma y almacenar el resultado de realizar operaciones con los valores contenidos en otras variables.

acumulador = acumulador + variable

Reductor

Un reductor es una forma de procesar una tarea grande poco a poco. Utiliza un acumulador para facilitar las operaciones intermedias y entrega un único resultado final.

La estructura común de un reductor es la siguiente.

reductor(elementos_enumerables, valor_inicial_acumulador, funcion_reductora)

elementos_enumerables: Una lista de elementos que pueden ser enumerados. Ejemplo [1, 2, 3].
valor_inicial_acumulador: El valor que tendrá nuestro acumulador en la primera ejecución de la función reductora. Ejemplo 0.
funcion_reductora: Es la función que recibe dos parámetros. El elemento en la lista y el valor actual del acumulador. Ejemplo fn elemento, acc -> acc + elemento end

El reductor ejecutará la función reductora por cada elemento y retornará el valor final del acumulador cuando cada elemento haya sido procesado.

https://redrapids.medium.com/learning-elixir-its-all-reduce-204d05f52ee7

Ejemplo

Vamos a ver un ejemplo concreto de cómo funciona un reductor. Primero definiremos una función para sumar dos valores. Utilizaremos la sintaxis simplificada con el operador de captura (&).
Lo que nos permite expresar una función de forma más corta.

La siguiente forma de expresar una función con dos parámetros

sumar = fn elemento, acc -> elemento + acc end

Puede ser simplificada utilizando el operador de captura &.

sumar = &(&1 + &2)

Sumaremos la lista de elementos [1, 3, 4] para que podamos obtener la sumatoria que es 8.

# sumar = fn elemento, acc -> elemento + acc end
sumar = &(&1 + &2)

&:erlang.+/2

Si utilizamos el módulo Enum y la función reduce obtendremos nuestro resultado

# reduce(enumerable, acumulador, funcion_reductora)
Enum.reduce([1, 3, 4], 0, sumar)

Es equivalente a llamar a la funcion sumar de forma anidada.

sumar.(4, sumar.(3, sumar.(0, 1)))

También puede ser expresada como un pipeline de la función sumar, cuyo valor incial es. 0.

0
|> sumar.(1)
|> sumar.(3)
|> sumar.(4)

Este pipeline se podría expresar como llamar a la función suma utilizando el resultado de la función anterior. En este caso se podría expresar como lo siguiente:

# 1
sumar.(0, 1)
# 4
sumar.(1, 3)
# 8
sumar.(4, 4)

CRC: Crear, Reducir y Convertir

Elixir utiliza módulos y tipos de datos, lo que permite una forma de organizar nuestro código en lo que se denomina CRC (Constructores, Reductores y Conversores). Por lo que tendremos funciones para (crear) un acumulador, funciones que realizarán operaciones (reductores) con este acumulador y finalmente funciones que transformarán el acumulador en un formato final (conversores). Ésto es algo que ha existido por largo tiempo en diferentes lenguajes de programación como Haskell o Lisp. Lo más importante que puedes hacer en un lenguaje es unir ideas utilizando composición.

La idea es crear un pipeline que reciba como primer parámetro un acumulador y realizar una serie de operaciones reduce hasta llegar al conversor final.

  entrada
  |> constructor() # crea el acumulador inicial
  |> reductor()
  |> reductor()
  |> reductor()
  |> conversor()  
  # salida de la función listo para ser utilizado por otro pipeline
  # o ser mostrado al usuario final

Por esta razón podemos considerar que todo en Elixir es un conjunto de acumuladores y reductores. Mucha de las funciones del core de Elixir pueden ser implementadas usando nada más que un acumulador y Enum.reduce.

¿Por qué es importante?

Gracias a ésta forma de organización podemos ver nuestro código de forma coherente
y unificada. Al tener una estructura de datos en común con varias funciones
podemos realizar operaciones y expresarnos con una facilidad de lectura mayor.
Nuestros sistemas serán más fáciles de entender y mantener en el futuro.

La consistencia es un factor importante de calidad en nuestros sistemas y utilizar CRC es una gran herramienta para lograr eso.

https://github.com/ElixirCL/ElixirCL/wiki/%5BTutorial%5D-CRC-y-DFTBLWB

# Creamos un nuevo mapa con nuestro acumulador
constructor = &%{acc: &1}

# Retornamos el valor del acumulador actualizado
suma = &%{acc: &1.acc + &2}

# Mostramos solamente el valor que deseamos
conversor = & &1.acc

0
|> constructor.()
|> suma.(1)
|> suma.(3)
|> suma.(4)
|> conversor.()

Ejemplo de CRC

Vamos a ejemplificar un poco utilizando un mapa del tesoro. En este mapa vamos a dar una serie de direcciones norte, sur, este y oeste. Se puede ver como tenemos una función de creación que retorna una tupla {x, y}, la cual será nuestra estructura de datos del acumulador. Luego tenemos una serie de reductores que modifican la tupla y devuelven una nueva tupla con los valores apropiados. Finalmente tenemos nuestro conversor que retorna un String con un mensaje final.

defmodule Tesoro do
  # Creador
  def nuevo(x, y), do: {x, y}
  def nuevo, do: nuevo(0, 0)

  # Reductores
  def norte({x, y}), do: {x, y - 1}
  def sur({x, y}), do: {x, y + 1}

  def este({x, y}), do: {x - 1, y}
  def oeste({x, y}), do: {x + 1, y}

  # Conversor
  def mostrar({x, y}), do: "El tesoro se encuentra en las coordenadas #{x},#{y}"
end

{:module, Tesoro, <<70, 79, 82, 49, 0, 0, 11, ...>>, {:mostrar, 1}}

import Tesoro

nuevo()
|> norte()
|> este()
|> este()
|> oeste()
|> oeste()
|> sur()
|> sur()
|> sur()
|> este()
|> este()
|> este()
|> mostrar()

"El tesoro se encuentra en las coordenadas -3,2"

Como se puede apreciar logramos generar nuestro mapa del tesoro utilizando un pipeline de funciones que aceptan una estructura de datos en común como primer parámetro (acumulador). Se realizan las operaciones a esta estructura para finalmente crear una salida con un formato específico.

Hemos logrado algo genial. Tomamos una idea compleja de distintas funciones y las unificamos como si fueran eslabones de una misma cadena. De esta forma puedes ver como las operaciones forman una cascada enviando valores. Hemos creado una composición utilizando reductores.

Las ideas de CRC (Crear, Reducir y Convertir) pueden ser encontradas a lo largo de todo el ecosistema de Elixir, por ejemplo con OTP y el estado de un GenServer o Phoenix para tomar un dato y convertir ese dato a HTML, SVG, JSON o similares.

El ver las operaciones como una cadena simplifica cómo construir, leer y probar todo el software en el ecosistema de Elixir, gracias a una excelente consistencia y decisiones de diseño.

¿Por qué usar Elixir frente a las alternativas?

Algunas razones:

Un lenguaje funcional moderno y preciosamente consistente. Permitiendo un nivel más desacoplado y consistente que con otras tecnologías.
Se ejecuta en la BEAM con más de 30 años de herramientas para sistemas robustos, escalables y concurrentes. Logrando una mayor confiabilidad y resiliencia a fallos que con otras soluciones.
Gran ecosistema de herramientas para IOT, Robótica, IA, Web, Mobile, entre otros.
Un mercado atractivo para profesionales con ofertas laborales novedosas y frescas, sin tanta competencia como en otras tecnologías. Mercado laboral en auge en USA, Alemania, Japón, entre otros.
Multitud de capacitaciones y certificaciones disponibles (Grox.io, Erlang Solutions).
Utilizado por empresas de alto calibre como Facebook, Whatsapp, Discord, Pepsico, Walmart, entre otros.

¿Qué nos depara la industria en el futuro?

La industria informática está llena de cambios. Podemos mencionar la tecnología de los 80's con las primeras computadoras personales como el Commondore o Atari. Luego en los 90's vimos los inicios de internet con HTML, JS y CSS. En los 2000's vimos el auge de las redes sociales como Facebook y plataformas como Youtube. En los 2010's se masificaron las aplicaciones y teléfonos móviles "inteligentes". ¿Qué se viene en la década del 2020's?. Lo más probable es la masificación de la IA y sistemas concurrentes. Casos donde Elixir y Erlang son idóneos, superando a otras alternativas como Python y Ruby. Los profesionales que aprendan lenguajes de la BEAM estarán preparados para las próximas décadas de la industria, debido a que cada día la concurrencia y robustez de los sistemas será mucho más necesaria.

Los lenguajes de programación que son "difíciles de contratar" siempre serán un problema. Desafortunadamente, este no es un problema que realmente puedas resolver, porque nadie conoce el futuro. Si por ejemplo elijes un lenguaje de programación popular hoy, luego a la gente deja de gustarle y no será fácil encontrar personal (VB6, Action Script Flash). ¿Qué pasa con casos como Python, donde la migración de 2.x a 3.x fue tan tortuosa, que prácticamente fue un cambio a un lenguaje distinto?. Las organizaciones que no se casan con un solo lenguaje o tecnología y adoptan estratégicamente nuevas herramientas, estarán mejor capacitadas para las variaciones del mercado e industria.

Imágen: https://commons.wikimedia.org/wiki/File:%C3%89lixir_et_liqueur.JPG

Documenta tu Evolución Profesional

Camilo — Tue, 02 Apr 2024 15:18:01 +0000

Un sitio web personal es un gran aliado para documentar nuestro camino y evolución en la industria I.T.

Github Es Insuficiente

Muchos pueden pensar de que solamente subiendo nuestro código a plataformas como Github, Gitlab, Codeberg y similares es suficiente. Pero lamentablemente tienen los siguientes problemas:

No sirven para documentar proyectos privados.
La información no está ordenada y es difícil de destacar las partes importantes.
Dependes de un tercero y no tienes autonomía al almacenar y distribuir tu contenido.

El principal problema es que cuando participas en proyectos donde no eres dueño del código. Normalmente para empresas privadas. En tu sitio web puedes por lo menos documentar que participaste en dichos proyectos (Si tu contrato lo permite).

Además muchas veces son tantos proyectos dispersos que es mejor tener un lugar centralizado que puedes poner en tu currículum vitae.

Super Tip

Si lograste algo importante en un proyecto privado puedes crear un ejemplo que no tenga los datos restringidos y que demuestre lo que aprendiste o lograste.

De esta forma puedes tener una documentación personal y tal ves en otros proyectos futuros puedas tener este código de ejemplo o cómo lograste algo en específico.

Comienza Hoy

Lo ideal es que si eres estudiante o estas aprendiendo, comiences desde ya a tener un sitio personal que documente los proyectos, ideas, eventos y otras experiencias que has vivido en tu carrera profesional. Si ya tienes algunos años te costará un poco más comenzar a documentar todo y tomará más tiempo ordenar el material que has acumulado con el paso de los años.

¿Qué tecnología usar?

Lo más importante es tener la capacidad de migración. Si algún evento causa que tu proveedor de hosting cierre, puedas encontrar otro fácilmente y migrar tu contenido. Además de poder ser almacenado en archive.org para preservación histórica.

La recomendación es utilizar sitios web estáticos con las viejas confiables tecnologías de HTML y CSS.

Usa un generador de sitios estáticos

Lo ideal es usar uno elaborado con la tecnología que más te guste, hay diversas opciones y para todos los gustos.

Acá una selección pequeña

geolessel / vox

The static site builder for Elixir lovers

Vox

The static site generator for Elixir lovers.

Quick start

There is a new site generator that is the quickest way to get started In order to use it, run

mix archive.install hex vox_new
mix vox.new blog

This will generate a simple scaffolded site that you can customize and tweak as you see fit.

There is also an example blog built with Vox that attempts to take advantage of all the features of Vox as they are built. You can look at the source code for that (and clone it and build it yourself) at geolessel/vox-example.

`vox.new` options

--esbuild - include a simple esbuild installation for asset compilation

Manual installation

The package can be installed by adding vox to your list of dependencies in mix.exs.

For now, it is recommended to install directly from GitHub. Note that the mix vox.new generator will generate the "~> 0.1.0" version instead.

…

View on GitHub

gohugoio / hugo

The world’s fastest framework for building websites.

A fast and flexible static site generator built with love by bep, spf13, and friends in Go.

Overview

Hugo is a static site generator written in Go, optimized for speed and designed for flexibility. With its advanced templating system and fast asset pipelines, Hugo renders a complete site in seconds, often less.

Due to its flexible framework, multilingual support, and powerful taxonomy system, Hugo is widely used to create:

Corporate, government, nonprofit, education, news, event, and project sites
Documentation sites
Image portfolios
Landing pages
Business, professional, and personal blogs
Resumes and CVs

Use Hugo's embedded web server during development to instantly see changes to content, structure, behavior, and presentation. Then deploy the site to your host, or push changes to your Git provider for automated builds and deployment.

Hugo's fast asset pipelines include:

Image processing…

View on GitHub

11ty / eleventy

A simpler site generator. Transforms a directory of templates (of varying types) into HTML.

eleventy 🕚⚡️🎈🐀

A simpler static site generator. An alternative to Jekyll. Written in JavaScript. Transforms a directory of templates (of varying types) into HTML.

Works with HTML, Markdown, JavaScript, Liquid, Nunjucks, with addons for WebC, Sass, Vue, Svelte, TypeScript, JSX, and many others!

➡ Documentation

Star this repo on GitHub!
Follow us on Mastodon @11ty@neighborhood.11ty.dev
Follow us on Bluesky @11ty.dev
Install from npm
Follow on GitHub
Watch us on YouTube
Chat on Discord
Latest:

Installation

npm install @11ty/eleventy --save-dev

Read our Getting Started guide.

Tests

npm test

We have a few test suites, for various reasons:

ava JavaScript test runner (assertions docs) (primary test suite in test/)
Node.js Test runner (secondary test suite in test_node/)
Vitest (in Browser Mode) (client tests in packages/client/test/)
Benchmark for Performance Regressions

These run in various environments:

Community Roadmap

Top…

View on GitHub

Crea tu propio generador de contenidos

Es una buena forma de practicar un lenguaje o tecnología, un proyecto pequeño que se adapte a tus necesidades. Aunque esta opción es solamente para quien desee dedicar mucho tiempo en detalles que ya están solucionados por los generadores disponibles.

Compra tu Dominio y Hosting

Lo ideal es tener un dominio y hosting propio. Puedes empezar con el hosting de Github Pages para empezar.

Proveedores de Dominio

https://nic.cl : Dominios de Chile
https://dyndns.com : Dominios para Ips
https://www.dynadot.com : Dominios Internacionales
https://porkbun.com/: Otro proveedor de dominios.

Proveedores de Hosting

Dependiendo de tus necesidades puedes tener algo propio en una Raspberry PI, o adquirir un hosting. La siguiente es una lista no ordenada de distintas opciones.

https://cpanelhost.cl/: Hosting Chileno Barato
https://www.silverhost.cl/: Hosting Chileno Mediano
https://pages.cloudflare.com/ : Hosting de Páginas Estáticas
https://pages.github.com/ : Hosting de Páginas Estáticas
https://codeberg.page/ : Hosting de Páginas Estáticas
https://neocities.org/ : Hosting de Páginas Estáticas
Servidor Propio (Raspberry PI)
Servidores VPS (DigitalOcean, Vultr, etc)
Servidores de Aplicaciones (Fly.io, Vercel)
Servidores de Nube (AWS, Azure, GCP)

Foto de Ilya Pavlov en Unsplash

¿Me conviene un Bootcamp Tecnológico?

Camilo — Thu, 28 Mar 2024 12:30:00 +0000

Los Bootcamps son escuelas donde te enseñan un conjunto de herramientas con el objetivo de mejorar tus habilidades y hacer más expedito tu proceso laboral en la industria de las tecnologías de información (I.T). Una pregunta habitual es ¿Me conviene un Bootcamp?. Debido a las diversas opciones, este pequeño artículo te podría ayudar a determinar si un Bootcamp es algo que quieras experimentar.

¿Cuál es tu perfil?

Lo primero en determinar es cuál es el perfil que tienes.

1. Beginner

Sin experiencia ni conocimientos previos. Vienes de otra industria o nunca has realizado ningún proyecto de informática.

Un Bootcamp te podría ayudar a definir tu camino y asesorarte en las tecnologías que puedes aprender. Además de presentarte un pequeño conjunto de proyectos que puedes hacer.

Sin embargo evalúa primero estudiar un curso específico (gratuito o de pago) de alguna tecnología para que puedas tantear el terreno antes de una inversión de tiempo y dinero significativa.

Personalmente recomendaría algún curso estatal de bajo coste como Talento Digital.

Recordar que los Bootcamps no son obligatorios para entrar en la industria o aprender las tecnologías.

2. Intermediate

Haz hecho algunos proyectos (sin usar tutoriales) pero tienes muy poca experiencia profesional en la industria.

Solo ingresa a un Bootcamp si realmente sientes que te dará un apoyo y valor relevante.

Si ya tienes algo de conocimientos, la recomendación es realizar proyectos en formato freelance o de apoyo a ONG para sacar filo y engrasar las herramientas.

El tener pequeños proyectos para clientes te dará mayores incentivos para aprender las herramientas y volverte un experto.

3. Expert

Haz estudiado una carrera de la industria o tienes experiencia laboral relevante en ella (más de dos años).

La verdad que un Bootcamp no te servirá mucho. Te conviene más cursos específicos de alguna tecnología o práctica. Realizar proyectos por tu cuenta, aumentar las habilidades blandas y mejorar tus redes de contacto serán más provechosos.

¿Tienes el Dinero?

Un Bootcamp es una inversión grande de dinero y tiempo. Por ningún motivo te endeudes (con un banco) para estudiar en uno. Ir a un Bootcamp no te da garantías de encontrar un trabajo ni tampoco comenzar recibiendo sumas millonarias de sueldo. No es una bala de plata que te da las llaves para entrar en la industria, simplemente son escuelas de capacitación.

La verdad yo recomendaría al menos dos años de estudio. Un Bootcamp ronda entre 6 a 12 meses.

Si cuentas con los recursos para costear una carrera técnica, recomendaría ir a una universidad o instituto certificado antes que un Bootcamp.

¿Cuál es su prestigio?

Muchas empresas en la actualidad tienen filtros sobre la calidad de los egresados de algunas instituciones. Procura que donde estudies tengan buena reputación en la industria y que sus egresados tengan buenas recomendaciones sobre la institución. El prestigio de donde estudiaste puede jugar a favor o en contra, sobre todo en los primeros años cuando no tienes mucha experiencia laboral que respalde tus capacidades.

¿Tienen redes de apoyo?

Un Bootcamp debería ser capaz de ayudarte en conseguir tu primer trabajo en la industria. Ya sea dándote empresas y prácticas o por último la capacidad de tener entrevistas. Si no te dan eso, no son diferentes a un curso presencial u online de alguna OTEC.

Además del conocimiento técnico un Bootcamp debería también darte asesoría en crear tu currículum y entrenar cómo hacer entrevistas laborales y redes de contacto.

Aprende los Fundamentos

Muchos Bootcamps se enfocan en tecnologías populares como Javascript y Python. Pero recordar que las tecnologías son efímeras, la industria cambia tanto como la dirección del viento, por lo que es de mucha importancia que aprendas los fundamentos que te permitirán adaptarte a cualquier tecnología o industria.

Yo personalmente recomiendo la tecnología Elixir, por su paradigma funcional, te permitirá salir de lo común y realizar proyectos en una amplia gama de contextos.

Si bien esta tecnología no es tan conocida como Javascript y Python (aún), te puede servir mucho para aprender Algoritmos, Sistemas Web, Apps Móviles, Robótica, Machine Learning y muchos otros casos de uso.

Sigue el Track de Elixir en Exercism para practicar ejercicios que te ayudarán a mejorar tus habilidades.

Podrías comenzar con tecnologías como Pascal, C y Assembler para aprender los fundamentos, altamente recomendado. Pero la verdad yo estimo que Elixir es una tecnología relevante y moderna, con un alto futuro y posibilidades de crecimiento. Personalmente lo veo como una apuesta segura.

Nada quita que una vez sepas los fundamentos puedas ir por otras tecnologías como Javascript, tener varias herramientas bajo el brazo nos dará mayor chances de destacar y tener seguridad personal de que podemos tener éxito en la maravillosa industria I.T.

Cover Foto por ThisisEngineering RAEng en Unsplash

Forem: Camilo

Separación de Responsabilidades de los Dispositivos

¿Es ser un Ludista?

Tecnología Kosher/Halal

¿Qué opciones hay?

Espacio Dedicado

Tener un Celular Simple

Herramientas de Trabajo

Conclusiones

[Boost]

Getting Started with AtomVM: Setup with Prebuilt Firmware (ESP32-S3, September 2025)

Odin for Alchemists

Modules

Maps

Lists

Array Programming

Enum.map

Enum.filter

Enum.reduce

About Map, Reduce, Filter and other "functional" like procedures

String concatenation

String interpolation

Function Overloading

Anonymous Functions

Named Arguments

Parametric polymorphism

filter

map (mapper)

Error Handling

Strategy 1: ok booleans

Strategy 2: Error messages

Strategy 3: Int returns

Strategy 4: Enum Errors

Strategy 5: Struct Errors

Strategy 6: Struct + Ok

Final thoughts

Odin's Elixir

What is Odin?

What are the guiding principles behind the design of Odin?

Odin's Elixir?

Treasure Hunt

Elixir Version

Odin Version 1

Odin Version 2

Final Thoughts

¿Trabajo Remoto o Híbrido?

Trabajo Presencial

Trabajo Híbrido

Trabajo Remoto

¿Por qué es importante?

Conclusión

Super Club Net: Libro de Introducción a HTML, CSS y JS

La revista Club Nintendo y su curso de HTML

Camilo for JavaScript Chile ・ Jun 8 '24

Contenidos

Desafío de Nombres y Apellidos

Desafío

Solución en Haskell

Solución en Elixir

Solución en Javascript

La revista Club Nintendo y su curso de HTML

Primera Parte

Conceptos

Segunda Parte

Conceptos

Tercera Parte (final)

Conceptos

Experiencia personal

Historia de la BeamVM

¿Qué es Erlang?

Origen de Erlang

¿Por qué Erlang es Bueno?

El modelo de Actores

Conclusión

Referencias

Introducción a Elixir

Un pequeño vistazo de Elixir

¿Qué significa Consistencia?

Ejemplos de Inconsistencias

Inconsistencias en la API

Strategy 1: `ok` booleans

`vox.new` options