-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathpresentation.slide
126 lines (83 loc) · 6.4 KB
/
presentation.slide
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
# Envisioning a Go-Powered Ecosystem: The Ultimate Go Computer
20 Jun 2024
Tags: golang, gnolang
Summary: TODO
Manfred Touron
VP Eng., Gno.land
https://gno.land/
https://github.com/gnolang
@moul
## Bonjour, GopherCon EU!
```go
// hello-its-manfred.txt
package main
import "fmt"
func main() {
fmt.Println("Hello, GopherCon EU! It's Manfred.")
}
```
: "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, ...).
- **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:
- **Interface**: The CLI syntax is Go.
- **Components**: Programs, libraries, and tools are Go packages.
- **Deployment**: Go packages have unique identifiers, their import paths.
- **Orchestration**: The kernel is a Go runtime.
- **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.*
: "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
- **No Marshaling**
- **No Flag Parsing**
- **No Compilation**
- **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.).
- **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).
- **New Approach**: Use Go imports and interact with dependencies in pure Go.
.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.
.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.
- **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**.
- **New Approach**: Programs are paused and resumed. An imperative language to write reactive apps. **Resume/Pause**.
.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.
- **High Composability**: Seamlessly write, import, and execute Go code.
- **Inspiration**: Apply Go to all computing levels, like Chuck Moore with Forth and the Plan 9 team with their OS.
> 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."