About me:

Agenda:

# Server Side

## <img src="./imgs/WebAssembly_Logo.svg" style="height: 15%; width: 15%;"></img>

- **Polyglot** with a lot of programming languages support
            - **Embeddable** in a lot of host runtimes
            - **Secure** allows to run untrusted code
            - **Standard** as part of the W3C

Note:

- Wasm has properties and charateristics that makes it a perfect execution environment on the server
            - first off it's Polyglot and we can compile from an increasing number of compatible programming languages,
              we don't need to decide upfront what language to support
            - it's built to be embedded in a host runtime, similarly to what happens in the browsers with JavaScript
              we can rely on standard interaction mechanisms that make it easy to be used in different environments
            - it's secure and the sandboxing mechanism can be leveraged on the server side to enable untrusted code execution
            - and again, is a W3C standard, is not going away anytime soon and more is going to be built on it

- **Ruby** UX
            - **C** foundation
            
            Note:

Ruby is some kind of an iceberg, C interoperability is a first class building block.
            Just like Python those days where the language is used for numeric computation as some kind of
            "DSL" on top of low-level C/C++.
            Ruby has always been optimized by rewriting fundamental libraries in C.

This is already a friction point on JRuby where people need to port the "Ruby bits" of a library to Java
            and subsequently bind to the underlying C code with all the pain and struggle of using JNI and the risks
            of running code outside the JVM.

Photo by <a href="https://unsplash.com/@simonppt?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">SIMON LEE</a> on <a href="https://unsplash.com/photos/a-large-iceberg-floating-in-the-water-qjs2R1lMMcw?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

[How to parse Ruby](https://programmingisterrible.com/post/42432568185/how-to-parse-ruby)

```ruby
            (lambda { |x| x.send((x > 0 ? :succ : :pred).to_s.to_sym) }).call((rand(2) == 1 ? -1 : 1) * (1..10).to_a.sample)
            ```

> slowly lose your sanity, gazing into the abyss that is **parse.y**
            
            Note:

Ruby syntax is complex, as it tries to feel natural to humans, and, well, humans are complex creatures ...
            The first step any interpreter/compiler should pass is parsing the syntax and doing something down the line
            with it.
            Given the complexity of the task multiple Ruby parsers emerged, and the situation has been a bit chaotic.

Photo by <a href="https://unsplash.com/@fotograw?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Dmitriy Demidov</a> on <a href="https://unsplash.com/photos/a-group-of-wrenches-arranged-in-a-circle-iuuJC_pjLU0?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

[Throughput :](https://github.com/andreaTP/wasm-bench/tree/bench-prism)

| Interpreter | AOT |
            |---|---|
            | 1127 ops/s | 35259 ops/s |
            
            Note:

We found out that WASM binary format and Java bytecode are very, very similar, so we developed
            an experimental AOT(Ahead Of Time) compiler/translator that takes WASM and emits pure Java bytecode,
            again, with zero dependencies outside Chicory itself.
            With it you can get pure Java bytecode out of a WASM module and it will run fast on any, stock, JVM.
            We have a basic "Hello world" application compiled from Go code, and those are the numbers in operations
            per second, of comparing the Chicory interpreter with the "AOT compiled" pure Java bytecode.