How do you mean run Erlang in the browser?
Ha! Sorry this was the wrong thread. This message ended up here by accident. To clarify: currently most of the heavy lifting are done in the node by the fsm and the compiler. As a user, you might not want to trust the node as it could trick you to something you do didn’t want. Therefore we need a more trustless way, client side. One way would be to reengineer the FSM and other parts in for example Javascript so users can run and verify it client side. Or, this was my message all about, we manage to use the Erlang code somehow.
@jsnewby presented a few ideas here. I think @botanicalcarebot.chain can comment too.
@nikitafuchs.chain maybe you can add a few things here too.
1 Like
I think it is mostly because it was the first smart contract language (based on the popular Javascript) → developed a large dev community (network) → many code libraries became available (for copy/paste-ing into your own project) → devs got used to it. I am not sure if they like it.
2 Likes
Correct, this topic doesn’t seem to be related to the original discussion 
Anyway, @emin.chain referred to the discussion on how to get the Aeternity node (and implicitely the State Channels component) on mobile devices. One approach which has been proposed by and is being prototyped at the momentby @jsnewby (afaik) is using Lumen to cross-compile the node as is for WASM. @nikitafuchs.chain planned to get a working group going on the topic to get a better idea of the requirements and possible approaches.
2 Likes
I really like those efforts and think it is the right way to go.
Before we try to write a VM in Javascript and having it maintained and updated whenever something updates in the core protocol, we should check out whats possible with WASM/Lumen and so on.
Would you agree?
PS: i think its still relevant for this threat even though we talk about alternate contract languages.
1 Like
Agree, especially because our VM is orders of magnitude more complex than the EVM. Regarding another language: I havn’t seen any signs of necessity so far, to be honest. Where we would truly need your expertise @rvirding is to somehow get the FSM or a stripped-down-for-payments-only version of it running on - at least - android. This would put us ahead of other protocols by far, and could empower mass adoption of aeternity for the means of payment in poorer countries.
2 Likes
I think trying out the WASM/Lumen path is something which will yield good insight into some of the cross-platform breaking points. However, I don’t think it will be a solution, mostly because Lumen is young, incomplete and untested and therefore it shouldn’t be used for such critical use-cases.
Another option for the WASM approach would be to actually go via the Erlang HiPE LLVM backend. While this will still require a lot of effort, the parts which are in place are well-tested and solid. @Happi is the person to talk to in that regard.
1 Like
The state channels team has started creating a quickcheck model of the FSM. Once that is done it will be a lot easier to create sub-models for a subset of functionality which in turn would be a great help for creating alternative smaller FSMs. We should get started on gathering requirements though soon.
1 Like
OK, so I find both options that have been discussed here, an alternate contract language or implement Sophia in the browser, very interesting. But they require a very different level of work so in one way it is difficult to compare them.
For an alternate contract language you already have everything in the node already implemented and accessible through the FATE vm. You “just” need to put a new layer on top of it and if you are a little cunning it shouldn’t be too hard to interface.
Implementing Sophia in a browser is a completely different thing and much more complex. One way to do it would be to implement the Erlang vm in the browser with say Web assembly or javascript. This would (hopefully) allow you to run most of the aeternity node, or at least those bits you need. It would also be something interesting for not just aeternity nodes but running general erlang stuff in the browser.
Implementing Sophia directly in the browser with just limited node functionality would/could perhaps be easier but more restricted.
I personally think that doing either would be a lot of fun, but they are completely different levels so someone has to decide how to go forwards.
4 Likes
I totally agree on everything. I also really like that Sophia and the æ VMs limit mutations to the state record. I think that trying to manage state correctly is the thing that causes most bugs in any application. While Haskell Mondas are probably the cleanest and most powerful solution for this, they seem to be too complex or too alien for most people to hook on.
Vue, React and Flux on the other hand also use confined-state updates (though only by convention, not enforceable in JS), and are hugely popular.
I think the language of my dreams would combine LISP syntax with static type inference and checks (maybe similar to Typed Clojure) and confined state updates.
1 Like
Why not implement WASM and do not create new language a’la Sofia.
Yes, research is going into that direction, it has nothing to do with (another) Language though, its rather a VM and compiler topic.
2 Likes
Predictable cost is huge. I thought Sophia was on the way there at any rate tbh.
My 2 cents, Erlang sounds more powerful but on the face of it Sophia, being so much smaller, should be a magnitude or two easier to implement a-new / in the browser than Erlang unless you manage to think Erlang apart from OTP and parallelism but does that really make so much sense?
It looks so big a task that at any rate, the easier route should be chosen, i.e. Sophia directly, not Erlang underneath.
I think it would be incredibly useful, bringing more security and performance to the browser. Of course the way to do it is to write a C or Rust (or Lisp) stand-alone Sophia VM/interpreter and compile it to WASM to have it run in the browser.
Yanis introduced indentation into Sophia, not Ulf, and he fully stands by it. I think it dots the optics. I thought that should not stop you from proposing a dialect without relevance in indentation. If that is what irks you - I sympathize - you might without that find Sophia as beautiful as it really is.
A solution I found for Lexon (https://lexon.tech) additionally to indentation, brackets or END keywords is to restrict nesting levels. In functional languages you are supposed to write short functions at any rate. They serve like blocks in spaghetti code. it’s brutal in a sense but seems to work very well. This way you might be able to define a Sophia syntax that looks just like it does now but can ignore whitespace.
We are in touch with Lexon, they also presented at aeternity universe conference
There has been progress in this area: GitHub - GetFirefly/firefly: An alternative BEAM implementation, designed for WebAssembly
1 Like
Wow! Thanks.
That’s coming from the Elixir ecosystem.
"The primary motivator for Lumen’s development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development. It is also possible to use Lumen to target other platforms as well, by producing self-contained executables on platforms such as x86.
Lumen is different than BEAM in the following ways:
- It is an ahead-of-time compiler, rather than a virtual machine that operates on bytecode
- It has some additional restrictions to allow more powerful optimizations to take place, in particular hot code reloading is not supported
- The runtime library provided by Lumen is written in Rust, and while very similar, differs in mostly transparent ways. One of the goals is to provide a better foundation for learning how the runtime is implemented, and to take advantage of Rust’s more powerful static analysis to catch bugs early.
- It has support for targeting WebAssembly
The result of compiling a BEAM application via Lumen is a static executable. This differs significantly from how deployment on the BEAM works today (i.e. via OTP releases). While we sacrifice the ability to perform hot upgrades/downgrades, we make huge gains in cross-platform compatibility, and ease of use. Simply drop the executable on a compatible platform, and run it, no tools required, or special considerations during builds. This works the same way that building Rust or Go applications works today."
(from the README)
If the codebase is any good that could be an awesome win-win joining that effort.
We are in touch with them and waiting for some stable releases to test this.
1 Like