Compile to WASM - The Emscripten Toolchain

Emscripten is an open-source compiler toolchain to Wasm. C/C++ (or any other LLVM-supported language) can be compiled and run on the Web, Node.js or other Wasm runtimes.

WebAssembly Not Automatically Blocked by Browsers

WebAssembly is a type of code designed to run in modern web browsers.  It is designed to run alongside JavaScript using WebAssembly JavaScript APIs - creating an option for performance critical functionality.

As WebAssembly increases the browser's attack surface, so browsers contain WASM inside the browser's sandbox and restricts system access. 

A risk maybe breaking out of the sandbox. Adobe Flash was a product sandboxed after a bunch of exploits, and after sandboxing exploits still occurred.

Transmission of WASM does not require TLS, HSTS or any other transport layer security mechanism making it susceptible to man-in-the-middle attacks.

Integrity checking is also impossible as WASM modules need not be signed by the author.

Some security-focused browser configurations can block WASM.

An Insider Look at CPython: The "Compiler-Interpreter"

A run-of-the-mill Python programmer may not necessarily think about CPython on a day-to-day basis. 

But CPython is an interesting thing to think about.

It is the reference implementation for Python, written in C and Python. C was used in theory to make portability easier - it's also more efficient (so there's no C++ or STL in there).

CPython is both a compiler and an interpreter. Python code is compiled (into bytecode) before being interpreted.  So you can think of it as a "compiler-interpreter".

One (potentially) painful feature of CPython is the Global Interpreter Lock (GIL) - and the GIL is used on each interpreter process - which means effectively only one thread can run at any one time (more explicitly, only one thread can process Python bytecode at any one time). While this simplifies the implementation, it becomes a bottleneck for CPU-intensive tasks.

Concurrency can be achieved by having multiple Python processes (which have by extension, multiple interpreter processes) and enable inter-process communication.  The Python multiprocessing module aims to make this paradigm simpler to implement.  This is however not available on mobile platforms or WebAssembly platforms.

The Same Origin Policy (SOP) on Modern Web Browsers

The Same Origin Policy (SOP) is a browser-enforced security rule that prevents scripts from one "origin" (PDP -> protocol + domain + port) from accessing resources from another origin.

The SOP prevents cookies, DOM and local storage from being read by malicious cross-site scripts.

The SOP does not just apply to web browsers. For example, Electron apps (desktop apps built with web tech) enforce SOP because they embed Chromium.

The Same Origin Policy is an "isolation model" designed to ensure "secure workflow".

Technology designed to integrate into browsers (e.g. WebAssembly) generally respect the existing SOP.

WebAssembly Debugging with DWARF Information - but what is DWARF?

DWARF is a standardized debugging data format, originally designed alongside the ELF data format.