Live data from Hacker News

Elixir Livebook now as a desktop app

news.livebook.dev

91–100 of 111 posts

Re: Elixir Livebook now as a desktop app

#92

Earlier quoted context omitted.

I, too, am interested but I'm not terribly literate in elixir yet. I am aware that you can compile executables in elixir with a release command but I'd be curious to hear more about (or at least be pointed to the specific spots in the code) how the bundling was done to give you a discrete application per platform, with app icon and everything. Having a script that opens a web browser pages is simple enough, but the e…

Right, so our goal was to allow configuring the bundle with app icons etc and importantly custom URL schemes and file types [1]. And then macOS- [2] and Windows- [3] specific launchers capture the "open file" and "open url" events and trigger the Elixir side of things. Another reason for native launchers is if for any reason we couldn't start the Elixir side, we want to let the user know that something went wrong and…

are there any plans to also have LiveBook open up in a separate wrapper app, like Electron?

Re: Elixir Livebook now as a desktop app

#93
post #90

Earlier quoted context omitted.

Plus sane failure domains: go has had preemptively scheduled green threads from day one but failure domains are really not a thing in go.

Hm, I think I've read somewhere that both Go and Elixir and kinda cooperative. A process in Elixir can yield control after certain number of reductions (function calls I think) and in Go a goroutine can only yield control on function calls, so if you have an infinite loop just adding numbers it will run uninterrupted. Both of them are "less cooperative" than Python with explicit yield statement. Do I get this right?…

Yes technically they are not fully preemptive in the sense that an os thread is (the os sends an interrupt which halts the processing at the CPU level), but in both go and elixir the programmer has no control over when the context switching happens, and "function calls" which are the yield boundaries happen all over the place, so it's "effectively preemptive".

Elixir is in practice more preemptive than go (last I checked with go) because you cannot infinitely loop and lock cpu in elixir -- a loop requires you to tail-call in elixir, so that's a yield boundary, and I'm certain that in earlier go that wasn't the case if you `while true {}`

Re: Elixir Livebook now as a desktop app

#94
post #39

Earlier quoted context omitted.

Elixir also opens you up to the entire erlang and Beam ecosystems. Not as common as Java, I know, but still decades of knowledge and tooling around it cutting across many industries.

Seems like Beam is a more specialized tool than JVM but if you need that sort of functionality it's phenomenal. With things like built-in performant persistent key value stores and cluster management I'm kind of surprised more people haven't pushed through the "this is useful but lacks broad adoption" barrier.

Well… yes and no. A lot of things built in are pretty spartan and not always appropriate (Mnesia …cough…).

This said it’s the only environment I’m aware of that is built around the idea of cluster, not just a local process that may do some rpc to other processes.

You can find libraries for many things but they are not the same quality and breadth as the big Java ones.

Re: Elixir Livebook now as a desktop app

#95

Earlier quoted context omitted.

Why would you use a notebook for quick scripts though

I often need to inspect/transform some JSON/CSV/text/whatever data, move around/organize a bunch files, and similar things. I find that notebooks work great for that as you don't need to set up an environment, you can easily collect and rerun your scripts if you do need them again, and the output options are great for debugging and looking at data.

Visidata† and Datasette†† are both excellent for rapid exploration. Both are available via Python pip.

† _ https://www.visidata.org/

†† _ https://datasette.io/

Re: Elixir Livebook now as a desktop app

#96
post #9

Earlier quoted context omitted.

The headline on the landing page is "Write interactive & collaborative code notebooks in Elixir". That's pretty clear and coherent to me.

why would i need to do that instead of Jupyter Notebooks?

Because you want to write Elixir instead of Python/R?

Re: Elixir Livebook now as a desktop app

#97
post #78

Earlier quoted context omitted.

Neat, I didn't know about Discord. Whatsapp I thought it was all Erlang, are you sure about Elixir being prevalent there? I wonder if it's only a few teams handling major events at Discord, or if that's truly their default backend service language all their backend teams uses. If so, maybe I should look at their job listings :p

From the discord blog posts it seems that elixir powers the chat system, with rust and python as the other two main languages in their stack. As for whatsapp, they are mainly a erlang shop and yesterday they open sourced a type checker for erlang: https://github.com/WhatsApp/eqwalizer

Since Elixir just compiles into BEAM byte code, like Erlang does, can this type checker be used on Elixir code too?

Re: Elixir Livebook now as a desktop app

#98
post #43

Earlier quoted context omitted.

I've wondered whether it's easier to add data analyst stuff to Elixir that Python seems to have, or add features to Python that Erlang (and by extension Elixir) provides out of the box. By what I can see, if you want multiprocessing on Python in an easier way (let's say running async), you have to use something like ray core[0], then if you want multiple machines you need redis(?). Elixir/Erlang supports this out of…

[I have no experience with Elixir.] Would that be possible to have elixir intelligently manage multiprocessing of python scripts? I would be especially interested in being able to have the scripts talk to each other, but have no idea how it could work, besides perhaps having them communicate by writing to / reading from the same files, which seems risky.

This is exactly the solution I was thinking of as well.

Re: Elixir Livebook now as a desktop app

#99
post #43

Earlier quoted context omitted.

I've wondered whether it's easier to add data analyst stuff to Elixir that Python seems to have, or add features to Python that Erlang (and by extension Elixir) provides out of the box. By what I can see, if you want multiprocessing on Python in an easier way (let's say running async), you have to use something like ray core[0], then if you want multiple machines you need redis(?). Elixir/Erlang supports this out of…

[I have no experience with Elixir.] Would that be possible to have elixir intelligently manage multiprocessing of python scripts? I would be especially interested in being able to have the scripts talk to each other, but have no idea how it could work, besides perhaps having them communicate by writing to / reading from the same files, which seems risky.

I think you can have the scripts talk to each other through Elixir via the BEAM/OTP approach: for each script you will have a GenServer module that manages it in a separate process. Call this module MyApp.ScriptServer and put "use GenServer" at the top of the file. This GenServer process will have a client API, which you can write, which will be how you interact with your script. In the BEAM programming model, processes communicate by sending messages to each other's mailbox, so you set up some logic for this and maybe have another module called MyApp.ScriptCoordinationServer that manages some global state.

This is just my amateur guess -- I'd be happy to hear an Elixir/BEAM/OTP expert chime in.

Re: Elixir Livebook now as a desktop app

#100
post #19

The Elixir ecosystem is growing incredibly well. I am impressed both from an engineering and a product perspective. It shows that they are playing the long game. I think they are achieving what I wished happen to the Clojure ecosystem: productive, well designed, respected and popular. Clojure missed the last step, unfortunately.

Because of the Java ecosystem, in Clojure you are in much more advantageous position than with Elixir.

I see it the other way around -- because of the BEAM ecosystem and programming model you are in a much more advantageous position than with Clojure.
Post reply on HN