juntao

Maybe you can try https://flows.network/, which supports environment variables when creating an app. You can also manage the environment variables later with their UI. Click on https://flows.network/flow/createByTemplate/Telegram-ChatGPT, you can see you could set up system_prompt.

I'm wondering what will happen if we let ChatGPT review these PRs created by ChatGPT.

Yes, We made a small tool to help developer review their PR. Seems a great supplement for Sweep AI.

Build your own PR review bot in 3 minutes here: https://github.com/flows-network/github-pr-summary

Actually, That's why I got your post so quickly.

We made a tool to Hacker News Posts with ChatGPT. You can customize which topic you're concerned about, then ask ChatGPT to give you a TLDR of the posts. Welcome to give it a try!

Discord version: https://github.com/flows-network/hacker-news-alert-chatgpt-d...

Slack version: https://github.com/flows-network/hacker-news-alert-chatgpt-s...

The Telegram version is on the way.

Github as the conversational UI.

Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI.

For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.

I can think of a few:

* Lightweight (no GC, under 2MB) * Designed to be a secure sandbox (not just a language runtime) * Modular (add host functions as needed — eg support for Tensorflow) * Multiple languages (esp compiled languages like Rust) * Works with container tools (Docker, k8s etc)

Personally, I believe v8 is and always will be primarily focused on the browser use case. It’s support for wasi, container tooling will always take a back seat compared with priorities in the browser.

Today, there are a large set of Rust apps that can run in WasmEdge, wasmtime, Fermyon spin, wasmCloud etc, but would not run on v8’s embedded Wasm engine …

However, I do agree that v8 excels in JavaScript.

We are hoping to get WasmEdge running on as many IoT devices as possible …

We would love to see more containerization on the edge:

https://www.cncf.io/blog/2021/11/11/containerization-on-the-...

Disclaimer: I am a maintainer at WasmEdge.

One of the benefits of running JS in Wasm (specifically the QuickJS approach) is that you can create JS APIs in Rust. That allows you to move a lot of compute intensive operations into Rust while still giving your developers a clean and nice JS API. WasmEdge does this with its JS Tensorflow API:

https://wasmedge.org/book/en/write_wasm/js/tensorflow.html

In fact, we are using Rust to support the entire Node.JS API in WasmEdge. :)

Will improve! Thanks!

One of the challenges is that Wasm supports multiple languages. So, we will have to decide to start from a Rust app or a JS app or something else. Would love your suggestions.

Disclaimer: I am a maintainer of WasmEdge. WASI-NN allows Wasm to be a wrapper of native tensor frameworks — very much the same way Python is a wrapper for Tensorflow and PyTorch.

The benefit of using Wasm as a wrapper is its high performance (Use Rust to prepare data) and multi language support (inference in JS!)

WasmEdge supports Tensorflow, PyTorch, and OpenVINO as wasi-NN backends.

I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons:

1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V.

2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view.

It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program.

Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)

They are all outside of traditional mega data centers. :)

I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers.

The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains.

All of the above are “edge” use cases in the sense that they are typically outside of mega data centers. :)

Running PHP in WebAssembly is so cool!

Great articles!

> the unification of Docker and Wasm containers will happen at the orchestration layer. In fact, it happens now. The integration with WasmEdge and K8s toolings has been done. Developers could use crun, CRI-O, containerd, KubeEdge, KIND, OpenYurt and K8s to start, manage, and orchestrate WasmEdge Apps. See more here: https://wasmedge.org/book/en/kubernetes.html

WebAssembly will run side by side with Docker using the same orchestration tools.

he WasmEdge Runtime (formerly SSVM) is a lightweight and high-performance WebAssembly (WASM) VM optimized for edge computing. It is widely used in scenarios ranging from cloud serverless functions, SaaS, blockchain smart contracts, IoT, to automotive real time applications.

Yes. Because WebAssembly provides a higher level of abstraction (safety, isolation, portability, manageability etc — you know, the “enterprise” stuff) over native code. See here: https://www.secondstate.io/articles/why-webassembly-server/

We took that experts at IBM and MIT would be honest about their performance findings. :) But, it appears that actual performance numbers are of great interest to the community. We will create repeatable benchmarks and open source them. Stay tuned!

Thanks, updated.

The speed differences between Python, JS, and C++/Rust are well documented. https://www.secondstate.io/articles/performance-rust-wasm/

But, of course, they are not universal and tend to have a large effect in areas where JS is rarely used — a selection bias one might say.

This is the same reason why people write Java but not C++ Apache extensions on the server side. It is safer and more portable to run bytecode inside containers.

Raw performance (the lack of) is always a contentious point for JavaScript, especially in our post-Moore era of computing. Node.js gets around this issue through extensive of use of native libraries and modules written in C, including the V8 JS engine itself.

But as application developers, how do YOU create high performance functions? Write in C and run as a NAPI module? Write in Rust and run as a V8 wasm? Well, there is another (better and faster) way now!

The SSVM is a fully featured WebAssembly VM (https://www.secondstate.io/ssvm/) that is optimized for server-side applications.

You can write functions in Rust, compile to WebAssembly and run in SSVM, and access it as if they are JS functions in Node.js. Easy as pie. Give it a try! (https://www.secondstate.io/articles/getting-started-with-rus...)

By rewriting computationally intensive functions from JavaScript to Rust, developers could achieve 10x to 100x times performance (https://www.secondstate.io/articles/performance-rust-wasm/) gain in terms of startup and/or execution speed.

BTW, Why not just use v8? For starters, SSVM runs much faster than V8 (https://www.secondstate.io/articles/ssvm-performance/) and it also supports more server-friendly extensions than just WASI.

Any issued and feedback are welcome. Checkout the GitHub link: https://github.com/second-state/SSVM

V8 wasm has memory size limitation because it is fundamentally limited by the chrome browser.

But other server-side WebAssembly don't have this question, for example, SSVM never had any arbitrary memory limit.