Social virtual spaces with Elixir at Mozilla | Hacker News Reader

Social virtual spaces with Elixir at Mozilla

elixir-lang.org

I started dabbling with elixir in 2017. The platform is phenomenal in terms of performance and the preciseness you can write code with.

The pains I've seen are

- thinking everything in a "functional" way

- ide support

- the library ecosystem, though rich in selection, could use some more help.

Functional thinking becomes easier the more time you spend on it. I've recently solved the ide part with VSCode and ElixirLS. I use Docker and I'm able to get all interpretation and dynamic compiling along with suggestions, warnings using the VSCode Remote Containers plug in.

Overall, the platform seems to be growing and it is great to see big players taking some steps here.

Do you have a reference or repo somewhere for your Docker setup, please? Sounds excellent.

I can upload it to github and share it with you! Let me ping back later in the day

Did you happen to upload this?

Sorry, I will share it with you tonight! thanks!

Thinking in a “functional way” is an upside and preferred by some and often a best practice by many (functional core, imperative shell crowd, much of the JS community post-React, etc.). It’s definitely a skill to have.

These frequent posts about Elixir are tempting me to give it another shot...

But the last time I tried (weeks ago), it was a total pain. I could barely find documentation for the authentication packages I was trying for Phoenix and the docs I did find were usually outdated. Packages were unmaintained left and right and there's no official libraries for things like Stripe.

It was a real shame because I seriously align with the ideology behind it. It just slows me downvand for that reason I can't use it.

What auth packages were you trying? Documentation in the Elixir ecosystem is often excellent. The recommended auth library with Phoenix is now phx_gen_auth if it helps.

As for Stripe, this looks pretty mature to me https://github.com/code-corps/stripity_stripe

Definitely not a lot of "official" libs/clients in Elixir, companies aren't gonna spend a lot of resources maintaining that.

My experience with phx_gen_auth was like this:

1. Install Phoenix, expect the command to be available because everyone is raving about it.

2. Missing command.

3. Dig through docs.

4. Pull the development branch of Phoenix because phx_gen_auth is only available there.

5. Run the generator within the Phoenix git repo because it won't allow me to run it elsewhere using a development version.

6. Use the generator.

7. Never figure things out because the phx_gen_auth command is barely documented and now I've got files everywhere that I don't understand.

I tried implementing API authentication as well and while I got it working, it was less pleasant than my usual Django stack.

Another example. The colossal amount of docs referring to a missing Phoenix plugin for Guardian that got removed in a random update made me scratch my head and spend an hour digging through their changelog and commits to figure out why my code wasn't working. The change was not documented at all.

All in all, there were roadblocks every step of the way with poor docs and big undocumented breaking changes in libraries like Guardian. I want to love this thing but it made me so unproductive in the first couple weeks of using it for basic web/api development that I simply noped out.

I feel your pain. I personally felt like the learning curve was on Elixir was quite steep, partially because I lacked a strong foundation in software engineering when I started. Fortunately I had the luxury of learning on the job & was given enough time to ramp up. Now I really like it.

Damn, did you try it 6 months ago while it was still experimental? I started like 4 projects in the past 2 months with it and this does not at all mirror my milage.

And I like it much better than a library because the code is just plain phoenix/ecto that is can customize easily.

No, a month ago.

Yeah, unfortunately there are still some sharp edges. Was there a particular reason you decided to use the unreleased version of Phoenix 1.6 instead of using the current version of phx_gen_auth (from https://github.com/aaronrenner/phx_gen_auth/)? There's a decent bit of documentation there too.

I haven't used guardian (not a fan of JWT) so I can't comment on it.

Yeah, phx_gen_auth hasn't landed in main phoenix yet. As another poster mentioned, you should try https://github.com/aaronrenner/phx_gen_auth if you're going to use a generator. You might however get more mileage out of Programming Phoenix[1] where you'd learn what all of the files are for and how to build auth yourself. Plug and Ecto make it quite easy to do password auth. Guardian was popular in the past, but isn't widely used these days. You could use joken, or just roll it yourself.

Generally the docs for Elixir libraries are very good, but you have indeed found some poorly documented things. I might suggest scraping together something simple and then trying out parts of the ecosystem that offer something new, like channels, live_view, broadway, or something else that takes advantage of OTP. Otherwise you're only going to see the gaps compared to Django and none of the benefits.

[1] https://pragprog.com/titles/phoenix14/programming-phoenix-1-...

Will do :)

Yeah, all the different files in different directories in a Phoenix project is pretty overwhelming. I would recommend going through the official Phoenix guides before messing with some of the generators or libraries, that helped me a lot. Also, if you're interested in it, the Phoenix LiveView guides are also excellent.

Coming from the Ruby and Node eco-systems I know what you mean, but I've also found it to be not that bad to roll my own depending on the complexity of the service. In some cases I'm finding I like it better that way because it's less "magic." For example, I can open the module anytime and see how the HTTP request is being made to the K8s API.

Definitely not for everyone or everything, just thought I'd share the thought.

Someone shared a boilerplate template on the Elixir subreddit the other day, might help out. Can't really recommend anything for Stripe, though. From what I've seen people usually use Stripity Stripe.

- https://alex-min.fr/open-sourcing-my-phoenix-boilerplate/ - https://hex.pm/packages/stripity_stripe

I'm the author of the boilerplate mentioned here if people have any question about it, thanks for sharing! I've had the same struggles personally when building my web app so that's why I backported some my code into this repo, the defaults with Phoenix are great but there's a long way to make it kind of usable for real users.

Shamless plug for our Elixir boilerplate we’ve been maintaining for three years :) https://github.com/mirego/elixir-boilerplate

I have had a completely opposite experience during the last 5+ years as full-time Elixir dev, but I can empathize with running into a few scenarios where some library wasn't implemented in Elixir, or the library you want to use is no longer supported.

If you're looking for an "every feature I will ever need to implement has a library for it" experience a la Rails or JS, you might not be happy with Elixir (although we shall see what 5 more years does to the ecosystem).

I don't have problems wrapping a service's API and creating my own library every once in a while, if it means I don't have to trade off slapping together a 5+ service behemoth just to get a good concurrent queue working. This is where Elixir/OTP shines: the hard stuff is easy.

Can you elaborate a bit more how the hard stuff is easy?

The code writes itself!

Paralellizing data processing is trivial, it's literally 2-5 more lines of code in many scenarios.

I've tried -- and failed -- to replicate what Elixir does in this regard, in several other programming languages. Age those tries incurred hundreds of coding lines. Only Rust came close, although it's a bit verbose, but the code still did the job.

What do you think about Golang's concurrency patterns?

They are mostly okay but I find their caveats tiring to mentally keep track of.

As a fairly experienced dev I prefer the technology to slap me hard on the cheek and not make me triple check things.

But Golang's concurrency is definitely a big step up from all the naked multithreading we had to endure and groom for decades -- that is unequivocally true!

I still find Erlang/Elixir's message passing paradigm superior though. Plus every "process" there (a fiber / green thread basically) is being transparently parallelized on another CPU core without you thinking about it at all.

As a personal scoreboard:

1. Erlang/Elixir's messages.

2. OCaml's "domain" effects (mutable shared state managed by multiple threads in a safe manner).

3. Golang's channels and messages.

I'll add - the synchronous by default, typed nature of Golang creates a massive amount of bookkeeping, as well as some fault tolerance issues you can walk into trying to build a robust service. It's definitely better than handling raw threads, but Erlang/Elixir beat it hands down.

> Paralellizing data processing is trivial, it's literally 2-5 more lines of code in many scenarios. I've tried -- and failed -- to replicate what Elixir does in this regard, in several other programming languages.

Scala's parallel collections handled this cleanly. I believe they've been removed from the built in libraries (still available as a JAR though), but the idea was that you'd just add a .par call in your data processing chain and it would use a parallel collection instead of a regular sequential one.

These examples from the documentation (https://docs.scala-lang.org/overviews/parallel-collections/o...) show how to turn a regular sequential computation:

  val list = (1 to 10000).toList
  list.map(_ + 42)

Into a parallel one

  list.par.map(_ + 42)

Oftentimes, for data processing, being able to parallelize parts of the computation makes it fast enough that one does not need to go beyond a single machine. Spark's RDDs are basically a distributed version of Scala's collection library.

One of the areas where Elixir and Erlang shine is distributed applications.

For anyone who has written socket code, the ability to easily send regular Elixir data structures as messages to processes that may run locally or remotely is pretty awesome. And once you realize that you can also send closures over the network (ie. one node can send a snippet of code to another node and it'll be executed there), mind blown.

Very glad that Scala offers this!

Do you have any insight on the underlying thread pool? Can you control the size? Is it automatically determined?

Erlang/Elixir default to CPU threads but the number of parallel thread schedulers can be manually changed as well.

This talks about how to configure it: https://docs.scala-lang.org/overviews/parallel-collections/c...

> What do you think about Golang's concurrency patterns?

I’d like to ask the same question about observables in JS (e.g. RxJS)

It's true that some library coverage is definitely the weak point of Elixir. Authentication in particular is a gaping hole although efforts like `Pow` and `phx.gen.auth` do help to no small extent.

The community is excellent though. You'll rarely find such a welcoming and ready-to-help community as ElixirForum (although the occasional exceptions do happen like everywhere else).

Elixir is not about the syntax or anything. It's about (a) the underlying runtime, (b) the very powerful metaprogramming facilities and (c) Phoenix / Absinthe / a few others.

Agreed on the community! They have been nothing but supportive on forums and chats. The brightest point of Elixir is their warm and friendly folks.

I haven't tried this yet - but I just recently saw this rolled up version of Phoenix - with a bunch of defaults.

https://legendaryframework.org/

Looks great, thank you.

Thanks, the only "starter kit" I could find was "last commit 5 years ago".

In my experience the documentation around Elixir has been ideal. People are modeling the absolute best of behavior, generally. The popular auth libraries (like guardian) are a bit of an exception in my opnion, for some strange reason. (Pow does a good job, though)

Hello, I'm sure Mozilla folks will be here too (I no longer work on Hubs) but I am quoted a few times in this article and happy to answer any questions I can!

This might be an ill-formed question given not knowing the specifics of the source code, but do you think Phoenix LiveView can be used to manage state through websockets vs the JSON payloads described in the article?

Sorry I don’t really know enough about LiveView to give a good answer. The protocol involved here is a fairly unsophisticated game networking protocol sending delta updates of object properties and transforms at 10Hz or so, and takes the approach of ownership transfer to orchestrate which packets are authoritative. If a reader who knows LiveView understands what I just wrote, they may be able to answer :) (the library for Hubs doing this is networked-aframe)

Rock on Greg / Dom / John / all!

Awesome seeing behind the scenes on all this.

This submission is probably the first example of usage Phoenix Framework in big company that I know. I remember how many there were Elixir vs Go "battles" on HN in last three years but what I have noticed the Phoenix have worse traction and new adopters evangelizing it. That's sad, because I think Elixir and Phoenix Framework definitely is worth some attention.

There are plenty of big companies using Elixir/Phoenix. Bleacher Report, Cars.com, Pinterest and many more.

Discord uses Elixir too, I think?

They use Elixir but not Phoenix.

I have heard pagerduty deploys their elixir microservices using a (very cut down) version of Phoenix. Somewhere they have a private "miniPhoenix" template that autogenerates everything for them.

There are some big non-tech companies that you probably know that use elixir-phoenix, off the top of my head, PepsiCo, MBTA, BBC, PRX (of NPR/public radio fame).

You can roll out your own mini Phoenix with flags passed to mix phi.new

We use it at Pepsi eConmerce for multiple teams. In fact all of our newer backend projects use it.

Silly question... what is Pepsi e-commerce all about? I’ve been contacted multiple times over the years by recruiters about Pepsi, but I never interviewed there.

We do a mix of things ranging from marketing and ads automation to supply chain fulfillment. We also work with no product innovation. It’s a surprisingly great place to work.

Thanks.

> We also work with no product innovation.

What does this mean?

It was a typo. I meant to type “new product innovation”. Basically marketing, manufacturing, and the research people come up with a new idea and make a small run. Then on the tech side we help with getting it in front of customers online and then figuring out who buys it.

I can't believe this has been around since 2018 and this is the first I've heard of it. I can think of a bunch of events over the past year where this would have been awesome to use. Shame that the marketing hasn't been better.

I'd like to run Hubs Cloud on premises (my own home), but it's currently only offered as Digital Ocean droplet and Amazon https://hubs.mozilla.com/docs/hubs-cloud-intro.html

I found some repositories here and there but it's all dated. I wondered if there is a more recent reticulum docker and installation document I could re-use and found the links below. If anyone has other tips, installation flows/scripts or pointers, feel free to share.

https://sophiadigitalart.com/setup-your-own-hubs-server/

https://github.com/mozilla/hubs

https://github.com/xr3ngine-archive/mozilla-hubs-docker

https://gitlab.nautilus.optiputer.net/ar-noc/mozilla-hubs-do...

There have been several attempts to try to dockerize the stack but none successful as far as I know. I did most of the work on packaging this so I’m not totally sure what is missing, but the droplet setup was close enough that I’m surprised nobody has cracked an all in one container image yet.

Mozilla licenses almost everything under the MPL, which seems to reduce interaction with other open source organizations. I wonder if it bothers them, or they're OK with it.

I doubt that's the reason (and if it is, that's a shame, because MPL is a great license and one of my personal favorites).

Most of Mozilla's code is on their internal mercurial server rather than GitHub. That feels like a larger reason.

I can't speak for Phoenix (yet), but today, I wrote my first macro for Elixir. I think I know what I like about Elixir. At its heart, it is a very simple language. It's not afraid to have an API that manipulates its own AST. 3 element tuple for every kind of AST node. That fricking simple. It makes it super easy to reason about the code and rewrite/restructure it programatically.

It's like an abstraction of the RISC vs CISC debates. A language built from a few simple consistent building blocks, or a massive amalgamation of corner case optimizations designed ad hoc for each situation as it arises?

Years ago, I was a full on Smalltalk enthusiast/ninja. One of the coolest tools that ever existed in the Smalltalk world was the Refactoring Browser written by John Brant and Don Roberts. It blazed the trail and wrote the book in IDE driven code refactoring. In all of the IDEs I've used since outside of Smalltalk, I haven't seen a refactoring they didn't implement, and there were quite a few I've never seen outside of that environment. Which was interesting, because Smalltalk has no manifest typing (it's run time typed rather than compile time).

I once asked John and Don if they were going to do the same tooling for for Java in Eclipse. It would have been the bomb in those days, and probably a great money maker. I theorized that some of the "fuzzier" parts of refactoring Smalltalk code would be easier because of Java's manifest typing. Don replied that he had thought that as well, and they had looked at it. But what they had found was that if there was a gain in having the types available, it was dramatically overpowered by the complexity of the Java AST (this was in the early days of Java too). The corner cases of trying to transmogrify code in a behavior retaining way just blew up combinatorially with all of the different corner cases. They looked at doing the same for Ruby eventually when it began gaining in popularity. Ruby, like Smalltalk, has no manifest types. But they found the same thing. At the time, there were 90+ different node types for a Ruby AST. And it was much more difficult.

So all of this tale is just a long way of saying, I'm liking Elixir so far. It's fundamentals are strange and paradigm challenging for me. That will take some patience to surpass. But I believe that platforms built on fewer scalable parts, rather than lots of syntactic sugar and variant execution models (I'm looking at all you "hybrid" languages), are better in the long run and way more empowering.

Why floating torsos without limbs? Could they have designed something less creepy to talk to?

Limbs can be tricky to animate correctly in VR… I still get nightmares from some of the abominations I’ve seen in VR Chat.

Usually all you have is head position and hand position. You don't have torso tracking separate from head tracking and because of that doing elbow IK can be really hard. This style keeps you out of the uncanny valley.

Although, the realistic torso shape might go a bit too far.

Worth noting Hubs is more like Wordpress for social VR - the content is largely up to the user (to either adopt or create) - so the avatars in screenshots say less about some kind of universal art design choices than whatever specific setup the user was in.

How's Jel going, Greg?

Figuring out what to do with it! :)

https://twitter.com/gfodor/status/1400670444533936128

Believe me, not creepy is harder than it seems, especially in VR.

Have you done much vr? Badly animated limbs are much worse than floating head, hands and torso.

I really want to try elixir, but I need an IDE based debugger!

I tried the IntelliJ plugin, but it did not work (would work once the disconnect when the first BP was hit)

JetBrains if you're listening, please make an official app / plug-in! Pretty please

My other gripe is the state of abandoned packages

You probably don’t need a debugger in elixir, based on my experience. You can drop into a process with iex.pry() or use the repl and get a lot of insight that way. You’re generally not dealing with state outside or GenServers which you can inspect if needed.

I used that debugger three years ago and it worked fine. Remember I had to do something special to set it up though. Made a career change after that so can't help you now.

Reply on news.ycombinator.com