bartblast
Creator of Hologram
Hey there! ![]()
We need help completing Elixir’s browser runtime by porting some Erlang functions to JavaScript.
Hologram automatically transpiles Elixir, but the underlying Erlang functions - the building blocks of Elixir’s stdlib - must be ported manually.
No Erlang knowledge required - just basic JS/Elixir skills and pattern-following. Tasks: 15 min to a few hours. AI tools encouraged!
Each function you port unlocks multiple Elixir stdlib functions in the browser!
Read the full blog post: https://hologram.page/blog/elixir-to-javascript-porting-initiative
Trending in News & Updates
Today we’re releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper embedded in Elixir. Nope, it’s a fully operati...
New
I’ll be using this thread to share Hologram patch release announcements. Minor releases will continue to get dedicated threads with blog ...
New
This release unifies configuration for queues, repos, and services, swaps opaque timing integers for readable durations, and backports pe...
New
:heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::heart::hea...
New
Bond brings Design by Contract to Elixir: preconditions, postconditions and invariants as executable specifications, checked at runtime a...
New
Aludel 0.7.0 is released :tada:
Since 0.5.0, Aludel has grown into a much more complete LLM evaluation toolkit for Elixir and Phoenix app...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Sorc96
I have an idea for a (probably non-trivial) improvement to the test suite. While porting
:erlang.make_tuple/2, I made a mistake and wrote a test checking that making a tuple with size 0 raises an error. This is not true, an empty tuple is returned instead, but the test passed, since my implementation raised an error.Would it be possible to compare the result of the JS implementation with the result of the actual Erlang function? I assume this would require implementing at least one of
term_to_binaryandbinary_to_term. Does this seem too difficult to be worth the effort?Most Liked
bartblast
Quick update: I’ve gone through all the remaining TODO Erlang functions and reviewed them. With far fewer left now, this was much more manageable!
I’ve pushed some functions to phase 2 after analyzing which Elixir stdlib functions depend on them. These deferred functions are primarily used by process-related Elixir stdlib functions, which aren’t targets for phase 1. Most of the deferred functions were ETS-related, commonly used by modules like
PartitionSupervisorandRegistry.This is your last chance to contribute – only 40 functions left to port for phase 1!
Thanks for all your contributions so far!
tenkiller
@bartblast I’m curious on your thoughts of what the return value of
re.versionshould be, considering there is not a single version tied to JavaScript Regex capabilities?I simply return an empty bitstring for now, bit this test will always fail.
bartblast
Since JavaScript regexes aren’t compatible with the PCRE standard (which Elixir uses), Hologram will eventually transpile them to maintain compatibility.
For now, please hardcode the JavaScript implementation to return
"8.44 2020-02-12". In both your JavaScript tests and Elixir consistency tests, use this regex pattern to verify the result format:~r/^\d+\.\d+\s+\d{4}-\d{2}-\d{2}$/(this should work in both Elixir and JS)This way both test suites validate the version string format rather than an exact value, which keeps things consistent.
Eventually,
:re.version/0will fetch the PCRE version from the Hologram client-runtime, which will receive it from the server in the initial request. Initially we’ll be targeting a specific PCRE version to ensure consistency across the client-side regex behavior.Thanks for flagging this!
Last Post!
bartblast
Update on time-related functions
While reviewing the PRs for Erlang time functions (
:os.system_time,:erlang.monotonic_time,:erlang.system_time,:erlang.time_offset,:erlang.convert_time_unit,:erlang.localtime), I realized they’re more interconnected than I initially thought.In Erlang’s time system:
Erlang System Time = Erlang Monotonic Time + Time OffsetThis means these functions should delegate to each other rather than each independently calling JS APIs. I’ve documented a unified porting strategy to ensure consistency:
Erlang Time Functions Porting Strategy
Happy to discuss if you have questions or alternative suggestions!