Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of erlang_js #65

Open
nickelization opened this issue Oct 14, 2016 · 7 comments
Open

The future of erlang_js #65

nickelization opened this issue Oct 14, 2016 · 7 comments

Comments

@nickelization
Copy link

We're working on figuring out the best future for the erlang_js project. If I've tagged you, it's because you've either made a contribution or expressed an interest in the project somewhere on GitHub. (Apologies if I've missed anyone, these are just the names that I've seen from scrolling through open pull requests.)

@marianoguerra @lemenkov @tisba @zackehh @sebastian @superstructor

So first off, thanks for all the contributions and for your interest in the project! I'm very sorry that we haven't been more responsive: there are multiple pull requests that have been sitting untouched for a long time, and that's a shame. Basho has not been so great about working with the OSS community lately, but we're working hard to rectify the situation.

That said, the erlang_js project is especially tricky, because Basho has no real reasons for updating it anymore. The only thing it's used for in Riak is for submitting JS MapReduce functions, but that functionality has been deprecated for years (since the Riak 2.0 release). We've been using the same 1.3.0 tag of erlang_js for numerous releases in a row, and eventually we may just remove erlang_js from Riak altogether.

Since there is clearly interest from the outside community, I don't want to just let this project rot, but we also don't necessarily have the resources to maintain it and deal with outside contributions. For example, updating the javascript engine would be great, but it would require a lot of testing to put that into a new release of Riak, and it's very hard to justify doing that work for a little-used, deprecated feature.

So, would any of you potentially be interested in taking over as a maintainer? In the past, we've successfully spun out popular Erlang OSS projects into their own external organizations (webmachine being perhaps the best example of this). If any of you who are using this project would like to see it continue to grow and evolve, I think this may be our best bet for allowing that to happen.

Thanks again, and let me know what you all think! I'm very open to any suggestions anyone might have on this matter, so feel free to speak your minds :)

@lemenkov
Copy link
Contributor

lemenkov commented Feb 8, 2018

We need to restart this discussion, since the master project (Riak) finally got some traction :)

@tisba
Copy link

tisba commented Feb 8, 2018

From time to time I take a look around what options are available to run JavaScript (or Lua) efficiently in Erlang environment.

I'm not sure if erlang_js's base is still the "right" way to go, versus e.g. using V8. But I'd still like to see some improvement in this area.

@russelldb
Copy link
Member

I'd like to remove erlang_js from Riak, is that contentious at all? I think the idea of passing the repo over the the community and cutting it free from Basho and Riak has merit.

@jaredmorrow
Copy link
Contributor

Having spent time both in the erlang_js codebase fixing bugs and dealing with building the EXTREMELY old spidermonkey code it contains, I'd 100% vote to remove erlang_js completely. It provides very little useful functionality and has a huge potential for bugs.

@lemenkov
Copy link
Contributor

lemenkov commented Feb 8, 2018

@jaredmorrow just for the record - I've managed to build it against more recent mozjs24.

https://github.com/lemenkov/erlang_js/tree/test-mozjs24

@lemenkov
Copy link
Contributor

Hello All!
Sorry for the resurrecting this but I'd like to mention that I've updated erlang_js to build against latest SpiderMonkey 52 and switched it to NIF. I've just finished it so I consider it as still in w.i.p stage (not ready for production). I've maintained compatibility as much as possible but still had to make some changes related to error handling.

For those who interested - https://github.com/lemenkov/erlang_js/tree/fedora-1.4.0-mosjz52-nif

I think it's time to discuss idea about the separate GitHub project since if anyone else but me is interested in developing it further :)

@russelldb
Copy link
Member

I commented on #68 but for the sake of fully circular coverage…I think an erlang_js org that maintains the future erlang_js is a great idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants