chore: improve berlin slides

Signed-off-by: moul <[email protected]>

presentations/2024-06-17--gophercon-berlin--manfred/presentation.slide

@@ -22,14 +22,16 @@ func main() {
 }
 ```
 
+: "Hello, GopherCon EU! My name is Manfred Touron, and I'm the VP of Engineering at Gno.land. Today, I'm excited to share with you a high-level concept of an all-in Go machine. This talk will be brief, but feel free to visit our booth or join us at future events for more in-depth discussions."
+
 ## Intro
 
 - **Goal**: Introduce the concept of an **all-in Go machine**.
-- **Current State**: Go development splits focus between **Go logic** and
-  **non-Go glueing/bridging** (UI/CLI, TCP, HTTP, gRPC, API, db/SQL, FS/Storage,
-  ...).
+- **Current State**: Go development splits focus between **Go logic** and **non-Go glueing/bridging** (UI/CLI, TCP, HTTP, gRPC, API, db/SQL, FS/Storage, ...).
 - **Vision**: Remove **everything** that isn't Go.
 
+: "The goal of this talk is to introduce the concept of an all-in Go machine. Currently, Go development often splits focus between writing Go logic and bridging with non-Go components like UI, CLI, APIs, and databases. Our vision is to remove everything that isn't Go, creating a more streamlined and efficient development process."
+
 ## What Would a Go Computer Be Like?
 
 Imagine a machine where Go is the only paradigm for all levels of computing:
@@ -40,9 +42,9 @@ Imagine a machine where Go is the only paradigm for all levels of computing:
 - **Storage**: Go memory is the storage.
 - ...
 
-*Disclaimer: These slides present a mental exercise of what such a computer
-could look like. This is not a critique of current practices, but an exploration
-of using Go everywhere.*
+*Disclaimer: These slides present a mental exercise of what such a computer could look like. This is not a critique of current practices, but an exploration of using Go everywhere.*
+
+: "Imagine a machine where Go is the only paradigm for all levels of computing. The CLI syntax is Go, programs and tools are Go packages, deployment uses unique import paths, the kernel is a Go runtime, and Go memory serves as storage. This is a mental exercise to explore the possibilities of using Go everywhere, not a critique of current practices."
 
 ## Key Concepts
 
@@ -52,15 +54,18 @@ of using Go everywhere.*
 - **No FileSystem/Databases**
 - **No main(), no exit**
 
+: "Here are the key concepts we'll cover: No Marshaling, No Flag Parsing, No Compilation, No FileSystem/Databases, and No main(), no exit."
+
 ## No Marshaling
 
-- **Current State**: Marshaling data between Go and other formats (JSON,
-  Protobuf, etc.).
+- **Current State**: Marshaling data between Go and other formats (JSON, Protobuf, etc.).
 - **New Approach**: Work with Go types directly.
 
 .code code/no-marshaling-before.go
 .code code/no-marshaling-after.go
 
+: "Currently, we marshal data between Go and other formats like JSON and Protobuf. The new approach is to work with Go types directly, eliminating the need for marshaling."
+
 ## No Flag Parsing
 
 - **Current State**: Parsing flags for command-line arguments (a.k.a., shell).
@@ -69,25 +74,28 @@ of using Go everywhere.*
 .code code/no-flag-before.go
 .code code/no-flag-after.go
 
+: "Currently, we parse flags for command-line arguments. The new approach is to use Go imports and interact with dependencies in pure Go."
+
 ## No Compilation
 
-- **Current State**: Separate compilation (source) and execution phases
-  (binaries), relying on the OS to run your apps.
-- **New Approach**: Directly call exported methods from other apps or via your
-  CLI. A single shared VM runtime.
+- **Current State**: Separate compilation (source) and execution phases (binaries), relying on the OS to run your apps.
+- **New Approach**: Directly call exported methods from other apps or via your CLI. A single shared VM runtime.
 
 .code code/no-compile-before.go
 .code code/no-compile-after.go
 
+: "Currently, we have separate compilation and execution phases, relying on the OS to run apps. The new approach is to directly call exported methods from other apps or via your CLI, using a single shared VM runtime."
+
 ## No FileSystem/Databases
 
-- **Current State**: Using file systems and databases with marshaling, and
-  potential failures.
+- **Current State**: Using file systems and databases with marshaling, and potential failures.
 - **New Approach**: Memory is the storage, and it is automatically persisted.
 
 .code code/no-fs-before.go
 .code code/no-fs-after.go
 
+: "Currently, we use file systems and databases with marshaling, which can lead to potential failures. The new approach is to use memory as storage, which is automatically persisted."
+
 ## No main(), no exit
 
 - **Current State**: Programs have a main() function and can exit. **Start/Stop**.
@@ -96,6 +104,8 @@ of using Go everywhere.*
 .code code/no-main-before.go
 .code code/no-main-after.go
 
+: "Currently, programs have a main() function and can exit, following a start/stop model. The new approach is to pause and resume programs, using an imperative language to write reactive apps."
+
 ## Conclusion
 
 - **100% Go**: Eliminate intermediary layers. Focus purely on structs and functions.
@@ -104,9 +114,13 @@ of using Go everywhere.*
 
 > Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- _Antoine de Saint-Exupéry_
 
+: "In conclusion, an all-in Go ecosystem eliminates intermediary layers, allowing us to focus purely on structs and functions. It offers high composability, enabling seamless writing, importing, and execution of Go code. Our inspiration comes from applying Go to all computing levels, similar to how Chuck Moore did with Forth and the Plan 9 team with their OS. As Antoine de Saint-Exupéry said, 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.'"
+
 ## What We're Doing at Gno.land
 
 - **GnoVM**: A new VM to run interpreted Go code, with automatic memory persistence allowing the composition of apps by importing them in Go.
 - **Gno.land**: Using GnoVM and a decentralized transaction system to provide a permissionless multiuser virtual Go computer.
   - Explore more: [github.com/gnolang/gno](https://github.com/gnolang/gno)
 - **Join Us at GopherCon US**: Attend our talk and workshop in July.
+
+: "At Gno.land, we're developing GnoVM, a new virtual machine to run interpreted Go code with automatic memory persistence. This allows us to compose apps by importing them in Go. We're also using GnoVM and a decentralized transaction system to provide a permissionless multiuser virtual Go computer. To learn more, visit our GitHub page at github.com/gnolang/gno. And don't forget to join us at GopherCon US for our talk and workshop in July."