87 lines
2.8 KiB
Markdown
87 lines
2.8 KiB
Markdown
|
## Nickel y Nushell — sí, pero con cuidado
|
||
|
|
|
||
|
|
Primero el diagnóstico honesto:
|
||
|
|
|
||
|
|
```
|
||
|
|
Rust → la audiencia es Rust — terreno seguro
|
||
|
|
Nickel → muy pocos en la sala lo conocerán
|
||
|
|
Nushell → algunos lo conocen, mayoría no
|
||
|
|
```
|
||
|
|
|
||
|
|
El riesgo es que suenen como stack personal en lugar de solución general. La oportunidad es exactamente esa rareza — **tú los usas en producción cuando casi nadie lo hace todavía**.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Lo que cambiaría en el slide de Nickel
|
||
|
|
|
||
|
|
Ahora dice:
|
||
|
|
|
||
|
|
> *"YAML rejected. TOML rejected. Reason: no type safety."*
|
||
|
|
|
||
|
|
Eso es defensivo. Empieza por la solución, no por el rechazo:
|
||
|
|
|
||
|
|
```
|
||
|
|
Antes: "YAML rejected. TOML rejected."
|
||
|
|
(suena a preferencia personal)
|
||
|
|
|
||
|
|
Después: "Config is code. If it's code,
|
||
|
|
it deserves a type system."
|
||
|
|
(suena a principio)
|
||
|
|
```
|
||
|
|
|
||
|
|
Y añadir una línea que conecte con el DAG:
|
||
|
|
|
||
|
|
> *"Nickel is where the DAG is defined. Rust is where it runs. The compiler validates both."*
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Nushell — actualmente casi invisible
|
||
|
|
|
||
|
|
La charla lo menciona en los PDFs de tu proyecto pero no aparece como concepto en los slides. Eso es una pérdida porque Nushell es **el puente** — el lugar donde el DAG definido en Nickel se convierte en ejecución Rust. Sin ese puente, la historia tiene un agujero.
|
||
|
|
|
||
|
|
Un slide corto o una adición al slide de Nickel:
|
||
|
|
|
||
|
|
```
|
||
|
|
Nickel → defines what is valid (compile time)
|
||
|
|
Nushell → orchestrates what happens (the bridge)
|
||
|
|
Rust → executes with guarantees (runtime)
|
||
|
|
|
||
|
|
Three layers. Each catches what the previous can't.
|
||
|
|
```
|
||
|
|
|
||
|
|
Eso no necesita explicar qué es Nushell en detalle. Solo su rol en la cadena.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## La optimización más importante de todas
|
||
|
|
|
||
|
|
Ninguna de estas. Es esta:
|
||
|
|
|
||
|
|
**El slide de los metros — 🛡 😴 🔥 — aparece por primera vez en Stage 1 pero nunca se explica.**
|
||
|
|
|
||
|
|
Si lo explicas en 10 segundos al inicio:
|
||
|
|
|
||
|
|
> *"Three metrics. Security. Sleep. Fire-fighting. Watch them move."*
|
||
|
|
|
||
|
|
Y luego dejas que evolucionen solos a lo largo de la charla, tienes un hilo visual que hace todo el trabajo emocional sin palabras. El momento donde 🔥 baja de ●●●●● a ●○○○○ después de Rust es el momento más poderoso de la charla — pero solo si la audiencia sabe desde el principio lo que están viendo.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Prioridad de cambios
|
||
|
|
|
||
|
|
```
|
||
|
|
Impacto alto, esfuerzo mínimo:
|
||
|
|
1. Explicar los metros al inicio — 10 segundos
|
||
|
|
2. DAG — tres menciones quirúrgicas ya descritas
|
||
|
|
3. Nickel: cambiar "rejected" por el principio
|
||
|
|
|
||
|
|
Impacto medio, algo de trabajo:
|
||
|
|
4. Nushell visible como puente — añadir al slide de Nickel
|
||
|
|
5. "More years" con la segunda mitad
|
||
|
|
|
||
|
|
Dejar como está:
|
||
|
|
6. Todo lo demás — no tocar lo que funciona
|
||
|
|
```
|
||
|
|
|
||
|
|
> El mayor riesgo de una charla buena no es mejorarla — es sobre-editarla. Estos cinco cambios tienen retorno claro. Más allá de aquí, el rendimiento decreciente aplica.
|