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.
That said, I'm not sure if the data agrees with you. I think Clojure is more popular and widely used at this time. Not sure, but I think from what I remember of the few rankings, and just the fact I don't know an equivalent success story to NuBank for Elixir, I think maybe Clojure is at the moment more popular in practice.
But with the amazing learning material Elixir is putting out, maybe it won't last.
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 the box.
Explorer[1] is an interesting approach, where it uses Rust via Rustler (Elixir library to call Rust code) and uses Polars as its dataframe library. I think Rustler needs to be reworked for this usecase, as it can be slow to return data. I made initial improvements which drastically improves encoding (https://github.com/elixir-nx/explorer/pull/282 and https://github.com/elixir-nx/explorer/pull/286, tldr 20+ seconds down to 3).
[0] https://github.com/ray-project/ray [1] https://github.com/elixir-nx/explorer
Oddly, it seems to me that Clojure (the established people in its community) don't really care if anyone is attracted to it.
It seems like the people who come to Clojure do so because they caught a glimpse of it somewhere, did some digging and searching, and decided to give it a try. Not exactly the same as Sun spending $500 million to market Java.
That's not to suggest the Clojure community is unwelcoming or silent, but they generally fly under the radar.
Several years ago I went to a few of the Amsterdam Clojure meetup group meetings, and at that time there were 10 to 20 people there.
Meanwhile, the Elixir meetup would have 20-40! And Elixir was still comparatively young. Of course the Ruby meetup group was even larger, but that's no surprise given the prevalence of Rails in business.
Nevertheless it's fairly easy to install[1]. If you have docker, you can just run the image to try it out:
docker run -p 8080:8080 -p 8081:8081 --pull always livebook/livebook
If you want a "native" install, after you have elixir installed you can use
mix escript.install hex livebook
livebook server
They discussed it, but no one has taken it on yet. I think Wojtek Mach(the desktop initial author) is a mac user, and they actively wanted to provide a way for windows users to easily try it.
It's a fantastic way to learn and a huge advantage over other languages, I think, to help build up the Elixir community.
Really appreciate the kind words and happy to hear that you are enjoying the book! Hugo Baraúna and I have really enjoyed putting this book together and feel that Livebook has become pivotal in explaining certain topics and really understanding how things work under the hood. I wrote a blog post about some of my thoughts around Livebook as a learning tool on the DashBit blog: https://dashbit.co/blog/livebook-as-an-educational-tool
Edit: one thing that would make it even nicer is if it would remember the folder and/or recently opened notebooks.
Having a script that opens a web browser pages is simple enough, but the extra sugar on top to wrap in an app bundle that shows up in your task bar or dock is something I am very curious about.
EDIT: Someone further down the thread linked to a more specific place and that led me to the macos.ex file[1] (which is what I was most interested in, being on macOS myself.
It looks like at least in the case of macOS it will build the bundle by hand, template in enough swift code to build the application, sign and notarize a bundle, and add the compiled elixir program in there. Pretty interesting. I guess the idea is that you write just enough swift to manage the life cycle of the compiled elixir application. It's an interesting approach but it seems like it would be frustrating and fragile.
[1]: https://github.com/livebook-dev/livebook/blob/355527f7e8034e...
It's simply put, not that easy to manage distributed live state in a sane fashion with python (see openstack), the programming model of the underlying language puts obstacles in your way. Meanwhile Erlang was created by a physicist who understood that the speed of light is a thing and consistency of data across distances is a real issue.
I tried to learn it a couple of years ago. Bought a book and couldn't shake the impression that it was created to be complex and hard to reason about or maybe I am wrong and it is "easy", but has a steep learning curve?
That being said, I looked at Go around the same time and I clicked instantly. Easy to read, simple and yet powerful.
If nothing else it's neat to learn as one of the few somewhat well used languages in modern times that actually adheres to Alan Kay's original conception of OOP.
I'm messing with Elixir just for fun, so this caught my eye.
The difference between features and benefits. It's good at telling you the features (what it does) but not so much the benefits (why you would use it, how it can help you).
A common issue, but more understandable in this case than most as your average visitor to the Livebook site will likely know they have a need for it already, rather than end up there based on a 'random' link (like this thread).
That's pretty clear and coherent to me.
Think Jupyter Notebooks (if you're familiar with the python world), but collaborative and for Elixir.
For example, recently an addition to add automatically generated sequence diagrams to Livebook Kino (https://github.com/livebook-dev/kino/pull/165). So generate code which shows a supervision tree, and automatically create a visual diagram of the code in one place. Pretty great for learning and explanatory material.
Communicating over a network or one of those chrome sockets to an elixir or erlang vm so someone else can manage your data.
Life is good