[kwlug-disc] Second context in system-level languages

[Mikalai Birukou]

How big is each language's "Hello world" when delivered to user (in 
production)?
(1) C, Rust, compiled to native languages -> size of the binary. And 
binary will be talking to device's OS to actually display something 
somewhere.
(2) Java, Python, Perl, JavaScript (on Node, Deno), scripts and 
non-native machine forms -> size of proverbial "print 'Hello world'", 
plus many megabytes of something installed in device OS that will take 
short instruction and do something and talk to this device's OS to 
actually display something somewhere.

On one hand, this observation gives us a real tool to compare size, when 
one is drawn into such comparisons.

On another hand, we may notice that the first group produces/compiles 
the whole world/context in which developer codes.
- In Java (and others from 2) you have a golden cage, from which you 
can't escape, with the positive side of not worrying about setting up a 
playground in which your code is executed.
- In C++ and Rust you make choices of how you set up playground, and 
then you play in it. And sometimes during a play, you realize that 
current golden cage is limiting, and you adjust it. This ability to 
adjust environment for code is the power of group (1) languages. But it 
is a hindrance in teaching of coding, as one has to create world before 
doing it.

Is environment for your fibonacci calculation a single thread, 
multi-threads, async jobs that run on one thread?
In Java(s) you have no choice of what you have. In Java(s) you may only 
target which version of system your code should be used with.
In C++, I hope, there should be types that help construct environment, 
and compiler guiding you, following types' info.
In C, I don't see how they do this ergonomically.
In Rust, all that info about environment of your play ground is 
reflected in all those pointer types, lifetimes.

An explicit recognition is missing that there are two context to deal 
with in group (1):
(a) setting up your play ground (that itself sits atop device's OS), and
(b) coding/playing itself.

In Rust, choose a tokio (async) runtime on a single thread, with 
respective pointer types. And you get yourself JavaScrypt/Go - like 
playground. Message pass to copy of such environment, and its like 
Worker in browser/v8, or other thread in Go.
Make quick choice, and run with it. Then look back, and, if 
needed/wanted, you may optimize result by bending playground itself. 
Compiler will ensure that such bending of the world stays consistent.

Magic is when you don't know how thing works.
- C pointers look same. They are magic.
- Rust pointer's typing expressly tells you how magic works, how your 
current environment works. This info about playground may seem 
distracting from focusing on play itself. But it is demystifying to the 
point of compiler being able to guide you really-really well.

May be, for Rust, we should create a boilerplate of cages that one can 
quickly choose from to quickly start. With tutorials about playground 
elements in each. And tutorials about bending boundaries, transitioning 
whole-sum,  or mixing environments.
(by the way, does this exist, or is now Rust_stable_enough to write 
something like this?)