
Asterius – Haskell to WebAssembly Compiler - entelechy
https://github.com/tweag/asterius
======
danharaj
See also webghc which has an alternative strategy to writing a new RTS and
code generator. They are cross compiling to wasm via llvm.
[https://webghc.github.io/2019/01/18/state-of-webghc-
january-...](https://webghc.github.io/2019/01/18/state-of-webghc-
january-2019.html)

~~~
hardwaresofton
I expect that relying on LLVM going forward will be the popular approach for
Haskell and other languages (there's so much momentum behind LLVM and it's
made to be built upon), it's fantastic to see people entering this space.

Despite the amount of derision Javascript and the web-as-a-platform idea is
met with, the amount of innovation is undeniable. I personally think the web
is the best platform (at the very least, it's the devil almost everyone knows)
-- it's already ubiquitous, has more-than-good-enough solutions for most
things and is supported by very huge companies and open source naturally. One
of the main hangups for those who dislike the web-as-a-platform idea spreading
usually call out the terribleness of Javascript the language -- and though I
think transpiled solutions like Typescript[0] and Elm[1]/Purescript[2] fix
this issue, the introduction of WASM will finally completely obliterate this
long-standing hangup. You want to write some other language for your JS
frontend? Soon you'll be able to.

JavaFX/QT/GTK/WxWidgets/etc people you had your chance (in the last decade or
two) to create simple, cross-platform yet sufficiently feature full
implementations and people are choosing bundling an entire browser to get away
from the tools you're giving them. If someone develops a sufficient stripped
down browser rendering interface or if projects like ion[3] take off, even
more people (with relatively simple apps to write) will use the web platform I
think.

As WASM gets better, the "native UI & speed" island is going to continue to
shrink, in my estimation. Of course you've also got approaches like Flutter
out there trying to render every single pixel (!), with enough weight to
actually make it happen and provide full sets of widgets and even work on a
desktop embedder[4] (shame about the only viable language being dart
though...).

[0]: [https://www.typescriptlang.org/](https://www.typescriptlang.org/)

[1]: [http://elm-lang.org/](http://elm-lang.org/)

[2]: [http://www.purescript.org/](http://www.purescript.org/)

[3]:
[https://github.com/justinmichaud/ion](https://github.com/justinmichaud/ion)

[4]: [https://github.com/Drakirus/go-flutter-desktop-
embedder](https://github.com/Drakirus/go-flutter-desktop-embedder)

~~~
nvrspyx
I'll add a fifth link since Google is actually working on a desktop embedder
for Flutter themselves.

[5]: [https://github.com/google/flutter-desktop-
embedding](https://github.com/google/flutter-desktop-embedding)

~~~
detaro
More precisely, _someone who works at Google_ is working on that:

 _This is not an officially supported Google product. This is an exploratory
effort, and is not part of the Flutter project._

It being under the _google_ GitHub organization doesn't mean much about the
backing, since Google demands copyright for all kinds of things their
employees do.

------
boramalper
Surprised to see that no one has mentioned GHCJS
<[https://github.com/ghcjs/ghcjs>](https://github.com/ghcjs/ghcjs>) still.

I have used it[0] a year ago and despite my shallow understanding of Haskell,
I have managed to port my CLI app to Haskell fairly easily!

[0]:
[https://github.com/boramalper/boolexman](https://github.com/boramalper/boolexman)

~~~
Mikeb85
It's not the same though. GHCJS is a Haskell to JS source compiler
(transpiler?). Webassembly is a lower level altogether.

~~~
dllthomas
It's not the same. It's certainly relevant.

------
pushtheenvelope
I'm curious how they solve garbage-collection, since last time I checked
WebAssembly doesn't yet support that?

~~~
terrorjack
Hi, asterius main dev here. Garbage collection support is near; we're working
actively on it, and after a few regressions are fixed it'll be available on
master.

It'll be a copying GC, with builtin support to automatically free unused
JavaScript references in the Haskell heap. It's also possible to plug in more
fancy gc algorithms later (e.g. generational, or concurrent ones with read
barriers).

~~~
tom_mellior
To be clear, this will be your own GC bundled with each application, not an
interface to the host browser's GC?

~~~
terrorjack
Indeed it's not an interface to the browser's gc.

There does exist a wasm anyref proposal which enables manipulating opaque
references in wasm and a gc proposal for further allocating/using such garbage
collected objects. However, basing our gc on those is currently less pragmatic
than rolling our own :)

------
paultopia
Client-side pandoc would actually be reaaaal interesting

~~~
guiraldelli
As far as I'm concerned, it already exists in two forms:

1\. [https://try.pandoc.org/](https://try.pandoc.org/)

2\. [http://markup.rocks/](http://markup.rocks/)

~~~
ghayes
Are those sites using Emscripten or just passing your docs to a server to
process?

~~~
PowerfulWizard
Markup.rocks says it is client side and appears to be using ghcjs:
[https://github.com/osener/markup.rocks/blob/master/Makefile#...](https://github.com/osener/markup.rocks/blob/master/Makefile#L47)

~~~
paultopia
Cool! Right now I run a docker container with pandoc on heroku in order to do
stuff like make decent PDFs from my iPad... hmm...

------
allenleein
Another 'Haskell to WebAssembly' project:

[https://github.com/dfinity/dhc](https://github.com/dfinity/dhc)

