chat VS theBeamBook

TUIs over ssh/telnet can be a lot of fun. Especially in cases where multiple people can interact with each other on the server. It simplifies the programming model as you only have one state on the backend that you render to multiple connections. Syncing up everyone becomes trivial. You can also use some React concepts, like rendering a virtual TUI and sending just the right set of minimal escape sequences back to the user to bring their display up to date.

A few months ago I implemented a telnet chat server[0] for fun and it was surprisingly easy to do so. Even by using a wasm vm that I was still working on at the same time.

[0]: https://github.com/lunatic-solutions/chat

We are investing a lot of effort into making Lunatic feel native to the particular language and ecosystem. If you look at the Rust chat server we built in Lunatic (https://github.com/lunatic-solutions/chat), it fully integrates with cargo. You just run your typical “cargo run” command, it will compile the app to wasm and use lunatic to run it. If you want to run your test, you can just do “cargo test”.

wasm-bindgen is necessary only because it’s really hard right now to merge the wasm world and the JS one in the browser. We have the advantage here of staying out of the browser.

It took me around a week to build it with Rust + Lunatic and you can check out the code here. If you would like to try it out you can connect to it with:

Recently I implemented a command line chat server in Rust using an actor framework. I model each TCP connection as an actor.

Hi HN,

I'm working on an Erlang inspired WebAssembly runtime for the backend[0]. Recently I added TCP support and was looking for apps I could build with it. I ended up building a telnet line chat app. It was a great dogfooding experience and has a nice retro feel to it.

You can access the US server with:

> telnet lunatic.chat

or the EU one with:

> telnet eu.lunatic.chat

Pick the one closer to you, as all the rendering is done on the backend and lower latency will mean better UX.

The server is open source[1] and written in Rust. The Rust code is then compiled to WebAssembly and runs on top of Lunatic. Each connection runs in a separate (lightweight) process, has it's own state and sends just a diff of esc-sequences back to the terminal to bring it up to date with the current render buffer. Everything is deployed to an ARM Linux box.

[0]: https://github.com/lunatic-solutions/lunatic

[1]: https://github.com/lunatic-solutions/chat

The server is open source and written in Rust. The Rust code is then compiled to WebAssembly and runs on top of Lunatic. Each connection runs in a separate (lightweight) process, has it's own state and sends just a diff of esc-sequences back to the terminal to bring it up to date with the current render buffer. Everything is deployed to an ARM Linux box.

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visualizations show you the timeline of thread moving between different running states.

The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!)

It has world-class introspection built in that gives you the power to observe and manipulate your running application through a REPL.

The BEAM has hundreds of features like this, because the BEAM is more of an OS than and VM.

I get it, you're a JVM expert, but the BEAM is more than a check list of optimizations that on paper the JVM can do.

I strongly suggest, before the next time you comment on an BEAM VM vs.JVM debate, please consider watching https://www.youtube.com/watch?v=JvBT4XBdoUE, "The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019"

and reading https://github.com/happi/theBeamBook " an attempt to document the internals of the Erlang runtime system and the Erlang virtual machine known as the BEAM."

Best of luck!

it does. values are immutable in the BEAM, not at language level.

The impact of bugs is minimized by compartmentalization. This is done from the lowest level where each data structure is separate and immutable [1]

But you can simulate mutability with stateful processes.

Directly from Joe Armstrong: https://joearms.github.io/published/2013-11-21-My-favorite-e...

[1] https://github.com/happi/theBeamBook/blob/3971e8e2d09e367670...

theBeamBook repo

On a side-note, if you're really interested in grokking the BEAM itself, https://github.com/happi/theBeamBook is a very good resource that delves deeper into the internal working of BEAM. Regardless of whether you use it, it's a fun read!

Check the https://github.com/happi/theBeamBook/blob/master/chapters/scheduling.asciidoc

Did you find this? As far as I know, it is the best resource: https://github.com/happi/theBeamBook