Hacker News new | past | comments | ask | show | jobs | submit login
Livebook: A collaborative and interactive code notebook for Elixir (dashbit.co)
585 points by bcardarella on April 18, 2021 | hide | past | favorite | 85 comments

"connect to an existing node" is going to be amazing.

I imagine two interesting uses for this.

1. producing reports. Connect a livebook session to your system in prod, run a livebook (which pulls data from DB eg), then get back a report. User engagement, cloud resources consumed, p90s, or an incident report...

2. manual database intervention. Suppose you need to manually make a batch of changes to the DB. It would be very cool if you could run a livebook inside of a sandboxed checkout (a temporary transaction) and write your db changes, then write your code that verifies that the db is in a state that you want it to be in. If you mess up your code, then you just terminate the transaction without committing. Then when you're happy with your notebook, you run it once with a commit at the end, and then save your notebook immutably in your records so that you can keep track of what you've done.

I think for intervening in prod, it would be very cool if someone could figure out how to extend erlang distribution over websockets so you don't have to figure out complicated mechanisms (open up ssh port, forward encrypted epmd, e.g.) to get into your system in prod

Be careful, websockets are tricky to secure and get right. It's easy to do something like forget to check the origin and now you've opened up a whole class of cross-site websocket scripting attacks. I love the idea of easy access and nice UI to prod machines, but put it behind a secure proxy or VPN layer and not facing the public internet.

'Connect to an existing node' is likely implemented using ERTS (http://erlang.org/doc/reference_manual/distributed.html). So you're basically connecting to the runtime of the target node. The security model for ERTS isn't great, though, so your point stands. All you need is a matching secure cookie and you can connect and run any commands you want.

To put context on that - it's still TLS, the cookie is just a password.

The problem is that it's one password for the node network, and you either have it, or you don't. So there's no real administrative control over access; it's shared password.

And a browser can be tricked into sending the cookie if you accidentally misconfigure the server. You will have no indication or warning of this happening, from either the client or server side, if you get it wrong.

If u use live book to print the erlangs distribution cookie, u still would need to steal the inter nodes certificate and be on the server network to do any shenanigans

But how would u get into livenotebook in first place if u shouldn't have access to the container it and the connected nodes run on? I mean u can easily destroy a production system with couple erlang commands

>> if you accidentally misconfigure the server

Sure, but I mean...

Yep, and then the temptation to fix it is to roll your own homebrew auth over websockets... which is super risky.

I imagine that such a solution would be a public package/extension with eyes on it.

Phoenix Channels accounts for many of these attack vectors. Livebook uses Phoenix LiveView which is built on Phoenix Channels.


Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations.

The idea is that some config magic turns the 401 into a 302 redirect that walks you through a single-signon page, then you get redirected back to wherever you left off. However since you can make failed requests do just about anything you could technically reroute the request to a WebSocket server that just serves error responses or something, but that feels very... wronky.

The module does feel somewhat unwieldy to use in general as well, although this may be due to general unfamiliarity on my part with Nginx's way of doing things (which I'd summarize as "AAAAAAaaaaaaaa (aaa!)"). (The whole `if`-statements-can-SEGV thing etc.)

The module can only return 200 (allow original request through) or 401 (deny original request); any other response causes nginx to cancel the original request and return 503. (In case of 401, anything else, or error, the FastCGI server or upstream never sees a connection at all.)

It's possible to pass interesting state information such as a username or non-opaque session token from the subrequest to the main request by capturing subrequest response headers then injecting them as request headers into the main request, but this is sufficiently into the weeds (and unlike any existing system Web developers would typically have experience with) that I have a strong tendency to just go \ N O \, but considering that it is admittedly an obscure yet established corner of nginx's configuration, I figured I'd say something for completeness... for the benefit of the 2 people still reading up to this point. :D

I've incidentally been trying to figure out how to set up a simple BeyondCorp-esque system with it for a while now (for remote access to home systems, so focusing mostly focusing on brain-dead simplicity), but the giant brick wall I keep running into is how to a) make things auth-aware, b) keep the cookie properly opaque, and b) prevent everything from exploding horribly if auth_subrequest gets turned off. The only method I can think of to enable (b) (so that individual services don't have to duplicate auth logic, kind of defeats the point) is to pass headers out from the subrequest, which then breaks (c) (making it possible to access things directly).

A small microservice that handles the cookie side of things and makes HTTP requests itself starts looking like a breath of fresh air...

> Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations.

To add, something similar can be done with Traefik and forward auth plugins.

That's very reasonable.

I wish nREPL would be standardized to be non-Clojure-specific as with LSP, so you could connect to a program written in any language with an nREPL server and poke at it. This is basically the Elixir version of that.

We use Elixir at work. I attach to a running sapp all the time. It’s great!

Wow, this is great.

The fact is can connect to existing nodes also makes it can also be great for operation and administration - instead of building an awkward admin panel, you can just having a collection of scripts.

The Elixir community is insanely productive. Also, the Elixir system is impressively pretty balanced - productivity-wise like Rails, concurrent-wise like Erlang, and continuously brings novel yet practical ideas to life in a robust manner!

Awesome work! Towards the end, José hits on a couple points that Jupyter does not do well:

  - Minute 25: Saved notebook is readable (markdown)
  - Minute 23: Live collaborate on a single notebook
  - Minute 22: Visual indication that cell is stale after an upstream cell changes

I've been playing around with some of these ideas for Python notebooks.


This is a proof of concept that combines Jupytext for markdown readable notebooks with Streamlit for in-order execution+caching. More difficult to get some of the more advanced features of Pluto / Livebook due to Python state management.

Curious to hear any thoughts.

Would you be able to expand or drop a few keywords on how (and what is) "python state management" prohibit few advance features.

By in-order-execution you mean pluto's reactivity, right.

I'm pretty excited about this. I'm admit I was skeptical when I saw a similar LiveView based notebook a couple months ago, and wondered why not just make a kernel for Jupyter.

But with the idea of real-time collaboration I get it. And with the momentum of Jose and team behind it, I think there's real promise here, especially once they figure out widgets and charts, which they have an open issue for.

I program in Elixir at work, so I usually have an iex shell open, but lately I've been using a LiveBook and it's great.

And I love the new Mix.install in Elixir 1.12 demonstrated here. Using a hex package in an adhoc way was a real shortcoming in Elixir before. Shows the power of having this thing developed by the language team.

There are already Jupyter kernels, IElixir and ierl (which I wrote). The latter supports Erlang, Elixir and LFE right now and supports connecting to another node as well.


I'll admit that I was initially skeptical about Elixir for anything ML related when I first picked up the pragprog book on Elixir and Genetic Algorithms.

Since that time, things have moved quite a bit. Between the Erlang VM JIT, then Nx, and now this, it's starting to look hopeful!

I'm looking forward to digging into this.

Love how prolific the elixir community and especially José is. Also, if you are into liveview/elixir, definitely dive into the codebase. There is a small operational-transform lib built in there too.

These guys are amazingly productive, while also running a commercial company

This is software that directly helps their business, so it's not really productivity outside of their business endeavors.

Try not to sound like you're diminishing the efforts and accomplishments of others.

This is tremendous work, they're running their business and come up with generic/generalisable solutions instead of narrowing the outcome to their own benefits only.

When Facebook spends engineering effort to work on React, it's not out of the kindness of their heart, and that's ok. It's still productive and an accomplishment, it's just productive for a reason that pertains to their business. It is the same here. This tool helps the adoption of Elixir, running Elixir is their business, so yay! But the comment I was replying to implied this is somehow entirely separate from their business, which it's not.

Not really sure how it sounded like I was diminishing the accomplishments of others. How would you have phrased the point?

FB has thousands of engineers. It's not that often that a small group of people can both keep the lights running financially and also develop fully featured massive libraries. I'd say that counts as a very productive company.

Right, but again my point is that developing this fully-featured library helps keep the lights on. The two things are not separate as you keep implying.

Not disagreeing that they are productive and accomplishing a lot.

I fully agree on the analysis. I can't say I'd have done a better job at phrasing, but I would have emphasized on the balance between business and contributions, rather than (from my reading) insisting on the business implications mostly.

Readable `.livemd` format looks lovely (regular markdown without extra elements)


Is it just me or is Elixir being talked/written about more in the past couple of months?

A bunch of startups including my own bet big on elixir 2 years ago and are starting to launch and gain prominence. the first wave of early adopters are coming out with battle stories to share and the conclusion is that elixir is the real deal.

> ... the conclusion is that elixir is the real deal

This makes me even more excited to start an upcoming new position writing Elixir full-time!

It is growing and having good adoption. Not a huge language but it also has a fair share of novel features (being built on Erlang) that aren't commonly seen with other langs. So I think it might have a disproportionate visibility compared to size. Lots of work happening in the community, lots of ambitious ideas and releases.

Why do you say its growing?

It recently hit top 50 on one of the big lists of programming languages and I see more people getting into it every day. It is growing unless there's s lsrge drain hole somewhere. Might not be growing relative to other larger langs but I'm fairly certain it is growing.

And I've heard a lot of concern about it being niche so I tend to mention that it is growing. Because in my experience the biche is quite large and .. growing. I find plenty of work.

There's quite a disconnect between the amount of attention it gets on HN and the fact it's not in the top 40 languages. I mean Tiobe index has it behind Lua, Lisp and RPG (?). So yes you can definitely say it's a niche.

This is a forum composed mostly of software engineers working on web technologies in young companies or startups, which means we're usually at the bleeding edge of computing.

The TIOBE Index represents the world of computing at large, including embedded development, industrial, financial, automotive, medical, hardware, etc. This is why C and Java are at the top of the TIOBE index and I'll argue will be there for the next 40 years, and doesn't mean that any language which is not C or Java are unpopular or niche. Ours might be a small percentage of total computing, but would you argue that web technologies/the Internet as a whole is a niche?

There is a reason the embedded world still uses C, and there is a reason the web world doesn't. Using the TIOBE index as popularity contest is misguided.

I can’t reply directly to the comment below yours, so it will be as a side comment.

I don’t think anyone is arguing Elixir isn’t niche, we are just explaining why Elixir gets attention on HN even though it is top 50 on TIOBE. HN itself is focused on certain domains and tends to be early adopters.

I think a lot of Elixir devs think or want to believe Elixir is bigger than it really is. That's what I understand from the guy I made the comment to. Now I don't enjoy popping people's bubbles but I think it's better for everyone to acknowledge the truth and then think how to deal with it.

> Now I don't enjoy popping people's bubbles but I think it's better for everyone to acknowledge the truth and then think how to deal with it.

How to deal with what? That Elixir isn't as popular, so I should tell my company to drop it? I should stop enjoying programming in it?

Sorry, sounds like you don't want to accept that Elixir is on the up, for whatever reason.

Yes, it's not super popular. Yes, people are being productive with it. I don't get the point of your comment.

I won't tell you what to do with it, but the fact is Elixir is not on the up, it's very niche (nichier than even Rust is) and it's probably starting to decline already. Look at Linkedin jobs

Lisp - 142 Clojure - 700 Elixir - 828 Rust - 3160 Golang - 9205 Ruby - 24353 PHP - 68444 Java - 132606

So Elixir, at its peak, has about the amount of jobs Clojure has (never knew anyone using Clojure btw). That's quite a niche, ±800 jobs in the entire U.S is very very little. You might not care or have any action items from these facts, others may. As for companies - I would never choose something like Clojure/Elixir for my startup that's quite crazy considering the small eco system.

Sorry, where's your proof Elixir's at his peak? How can you tell from these numbers it's on the decline?

> I would never choose something like Clojure/Elixir

Then don't, nobody is making you. I still don't see why you want to stress so much Elixir is not a top language. From what I can tell, you have a bone to pick with the language and being confrontational with no discernible reason. Good day.

EDIT: checked your post history, you're definitely being a troll on purpose on most Elixir posts.

I don't think I was confrontational at all, I only listed facts on this thread. Other threads have zero relevance. Good day to you too!

You keep bringing up “Elixir has peaked” but you don’t provide any concrete evidence for that. The only mention so far is Stack Overflow, which is not used by the community, and such was explained to you on separate occasions.

Someone mentioned Elixir has just passed top 50 on TIOBE - that’s growth. It also just crossed top 20 on GitHub by number of pull requests on Q1/2021.

I am not disputing it is niche. I am not disputing the job market is tiny. But for someone who mentions acknowledging the truth, you don’t seem to be very truthful on your claims the language has peaked, especially given the last time you claimed so, you used a milestone (Top 50 on TIOBE) that has been reached since then.

The problem with Elixir is it's too small to get good data on (I'm not being mean, that's the truth). Tiobe has trends only for the top 20 languages so can't use that.

The best I've got is Stackoverflow survey (are you saying Elixir devs don't use Stackoverflow at all? I find it bizarre. Even if you use Elixir forum a modern dev has questions on many things he needs answered (css, javascript, sql etc).

So please compare https://insights.stackoverflow.com/survey/2019#most-popular-... With https://insights.stackoverflow.com/survey/2020#most-popular-... Elixir was dropped from the list. That's definitely a sign of decline. Now it could be that on absolute terms Elixir is keeping it's usage but only dropping on relative terms but I find it a bit hard to believe. I have a feeling Elixir devs who look for the next gig use other tech more often than not.

It is a data point, not definitive.

The language could be shrinking in comparison to everything an still be growing. I don't think that's the case but it wouldn't change anything for me. I don't work with a proportion of client according to trends. I work with particular companies and I'm at capacity doing Elixir as are many I know.

I believe it has a stronger trend then you believe it does. But neither of us have strong data.

Aren't clients considering migrating to different tech? I'm not trying to be annoying, genuinely interested. My current company considered it and they're a Ruby shop (luckily for them they rejected the idea). The thinking was something along the lines of Ruby is declining and how will they find developers 10 years from now. So if people can get this paranoid about Ruby I'm interested how it is on Elixir land.

So what is your action plan? To keep commenting that Elixir is niche on many threads even though most people here aren’t saying otherwise?

And even if they think that’s true, do you think being antagonistic to them on forums is what is going to change their mind?

I remember a recent comment from you saying that Elixir has probably peaked without even crossing top 50 on TIOBE... and yet here we are.

Look if you wanna shoot your career in the face go ahead stick to Elixir, the rest of us have bills to pay.

That’s only an issue if you define your career by a single programming language... I don’t.

Regarding bills, I made my biggest salary bump after I jumped to Elixir, but I appreciate the concern.

Elixir is niche. It's number 48 in Tiobe, in Redmonk it's not in the top 20, in Stackoverflow yearly surveys it dropped out of the list (too little usage). You mean to tell me a programming language not in the top 40 isn't niche? Hey I'm a Rubyist and I acknowledge the fact Ruby is niche (in some cities/countries you will have difficulty getting a Ruby job), yet even Ruby is way more popular than Elixir.

There were 300 elixir stories in 2020, an average of roughly .8 per day. In 2021 there have been 89 elixir stories for 108 days, so about the same. (Source: hnsearch)

Is it possible to tell how many of those hit the front page? I think the majority of those 300 stories in 2020 did not hit the front page. I'm curious how many there were in years prior as well.


Interesting that I'm getting down voted, I'm long on Elixir and betting my startup on it.

I didn't down vote you, but my guess is that it was because you commented a single word. Also, because of the position of your comment, I had to scroll back up in order to find the context.

All this cool Elixir news. I'm really having a hard time deciding between Elixir and Julia.

(For programs that I must have compiled to a distributable executable, I've pretty much settled on Crystal. I find it more productive and pleasent than Go or Rust.)

As someone who started on julia first and then moved to elixir:

If you're doing computational/numerical stuff, stick with julia, for now. You really can't do that elixir, not today, and maybe not for at least another year or two. It will likely never be as good as julia since computation is not first class in the vm it runs on.

If you're doing or planning or doing anything with web, or orchestration, go with elixir.

if you want to build a saas, go with elixir. Its got a great batteries included web framework thats built to scale and an emerging suit of ml and linear algebra software coming out.

If you want to experiment with ML and scientific programming where you do a lot of matrix processing, go with julia. thats literally what its made for.

Julia has a web framework too of course. https://genieframework.com/

It’s not quite the same story but https://github.com/spawnfest/bakeware builds elixir releases into distributable executables.

That one is out of date, the one it forked of is not: https://github.com/bake-bake-bake/bakeware

Would like to know how Livebook achieve collaborate-editing. Does it use algorithms like CRDT or OT ?

OT. Using quill js on the frontend and a subset of that delta format handled on the backend. From conversation with Jose on Twitter.

Super nice! It's only missing auto-complete and it'll be light-years ahead of other tools on terms of usability

There’s already a PR for it with a video of autocomplete in action :)


I'm just gobsmacked at how fast they're moving here. This is incredible.

So this is like Jupyter notebooks for Elixir?

With google docs style collaborative editing, can connect to an existing cluster to run code in it. You can run one instance of the Livebook application and have different livebook docs run for different Elixir projects you happen to be working on.

Not sure what parts are in Jupyter but I've heard collab editing isn't.

Pretty hype about trying this for some living docs and teaching. Will see if I can do anything neat with it. Already tried it some.

I used to teach my viewers of the basics of Elixir. It's in Brazilian Portuguese, but it's kinda interesting how easy is to use Livebook and show some code for people.


Yeah I think this will be really neat when paired with an example project for libraries.

If you compare the work done in both projects (github insights), you will feel the power of the Beam, Elixir, Phoenix and LiveView.

Yes - it would seem so. The support for custom run times is interesting and seems like an improvement. Not sure Jupyter notebooks do that - certainly not for all supported kernels.

Jupyter is great but it's somewhat of a "lowest common denominator". So there is always the temptation to make a more task-specific version; see also the Pluto notebook project for Julia and R Markdown (although the latter evolved concurrently with IPython/Jupyter, not after it).

LSP is in a similar situation right now, where it's great for languages that lacked tooling to begin with (like Python), but it's not yet possible to migrate existing powerful language tooling (Lisp SLIME, OCaml Merlin) to use LSP.

For the record, ocamllsp uses merlin under the hood, and other tools, so it can be a more integrated experience and be easier to setup.

How to use dependencies within a livebook?

I just tried to use the enum_type (version 1.1.3) by just installing it inside the cloned livebook repo, but I'm getting the error that EnumType isn't loaded.

Why is this?

I'm using this tool to teach the basics of Elixir on my livestream. I think there's a lot of good usecases for Livebook, not only machine learning and stuff like that.

I'm not sure how I'm going to use this yet but I think there are going to be some great opportunities for prototyping here.

Using it everyfay. Greate tool.

Using it everyday. Great tool.

If I'm a data scientists with a bunch of existing Python notebooks can I use this product?

Not yet. It only supports Elixir for now (there is an issue for supporting other languages) and the notebook formats are different, so someone would also need to write a nbconvert to Markdown (.livemd).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact