Livebook Alternatives

livebook reviews and mentions

• Show HN: PlayBooks – Convert on-call documents into executable notebooks
  5 projects | news.ycombinator.com | 4 Jun 2024
• Elixir and Machine Learning in 2024 so far: MLIR, Arrow, structured LLM, etc.
  7 projects | news.ycombinator.com | 29 May 2024

  I have always considered helping the community grow into a diverse ecosystem to be my main responsibility (the Python community being a great example here).

  This particular effort started because some people got together and realized that we could do it! Do it in a way that felt part of Elixir and not just a bunch of bindings to C libraries.

  We honestly never had the expectation that we had to beat Python (otherwise we would simply not have started). Early on, we were not even sure if we could be better at one single thing. However, 3 years later, we do have features that would be quite hard or impossible to implement in Python. For example:

  * Nx Serving - https://hexdocs.pm/nx/Nx.Serving.html - allows you to serve machine learning models, across nodes and GPUs, with concurrency, batching, and partitioning, and it has zero dependencies

  * Livebook - https://livebook.dev - brings truly reproducible workflows (hard to achieve in Python due to mutability), smart cells, and other fresh ideas

  * A more cohesive ecosystem - Nx, Scholar, Explorer, etc all play together, zero-copy and all, because they are the only players in town

  Of course, there are also things that Python can do, that we cannot:

  * In Python, integration with C code is easier, and that matters a lot in this space. Python also allows C to call Python, and that's just not possible in the Erlang VM

  * Huge ecosystem, everything happens in Python first

  At the end of the day, what drives me is that the Erlang VM offers a unique set of features, and combining them with different problems have historically lead to interesting and elegant solutions. Which drives more people to join, experiment, run in production, and create new things.

• Super simple validated structs in Elixir
  1 project | dev.to | 20 Apr 2024

  To get started you need a running instance of Livebook

• Arraymancer – Deep Learning Nim Library
  6 projects | news.ycombinator.com | 28 Mar 2024
• Setup Nx lib and EXLA to run NX/AXON with CUDA
  2 projects | dev.to | 22 Mar 2024

  LiveBook site

• Interactive Code Cells
  2 projects | news.ycombinator.com | 18 Dec 2023

  I prefer functional programming with Livebook[1] for this type of thing. Once you run a cell, it can be published right into a web component as well.

  [1] - https://livebook.dev

• What software should I use as an alternative to Microsoft OneNote?
  2 projects | /r/software | 7 Dec 2023

  If you're a coder, Livebook might be worth a look too. I certainly have my eyes on it.

• Advent of Code Day 5
  8 projects | /r/elixir | 5 Dec 2023

  Would highly recommend looking at Jose's use of livebook to answer these. It makes testing easier. It's old but still relevant. Video link inside

• Advent of Code 2023 is nigh
  19 projects | news.ycombinator.com | 1 Dec 2023
• Racket branch of Chez Scheme merging with mainline Chez Scheme
  5 projects | news.ycombinator.com | 6 Nov 2023

  That's hard to say. Racket is a rather complete language, as is F# and Elixir. And F# and Racket are extremely capable multi-paradigm languages, supporting basically any paradigm. Elixir is a bit more restricted in terms of its paradigms, but that's a feature oftentimes, and it also makes up for it with its process framework and deep VM support from the BEAM.

  I would say that the key difference is that F# and Elixir are backed by industry whereas Racket is primarily backed via academia. Thus, the incentives and goals are more aligned for F# and Elixir to be used in industrial settings.

  Also, both F# and Elixir gain a lot from their host VMs in the CLR and BEAM. Overall, F# is the cleanest language of the three, as it is easy to write concise imperative, functional, or OOP code and has easy asynchronous facilities. Elixir supports macros, and although Racket's macro system is far more advanced, I don't think it really provides any measurable utility over Elixir's. I would also say that F# and Elixir's documentation is better than Racket's. Racket has a lot of documentation, but it can be a little terse at times. And Elixir definitely has the most active, vibrant, and complete ecosystem of all three languages, as well as job market.

  The last thing is that F# and Elixir have extremely good notebook implementations in Polyglot Notebooks (https://marketplace.visualstudio.com/items?itemName=ms-dotne...) and Livebook (https://livebook.dev/), respectively. I would say both of these exceed the standard Python Jupyter notebook, and Racket doesn't have anything like Polyglot Notebooks or Livebook. (As an aside, it's possible for someone to implement a Racket kernel for Polyglot Notebooks, so maybe that's a good side project for me.)

  So for me, over time, it has slowly whittled down to F# and Elixir being my two languages that I reach for to handle effectively any project. Racket just doesn't pull me in that direction, and I would say that Racket is a bit too locked to DrRacket. I tried doing some GUI stuff in Racket, and despite it having an already built framework, I have actually found it easier to write my own due to bugs found and the poor performance of Racket Draw.

• A note from our sponsor - InfluxDB
  www.influxdata.com | 12 Jun 2024

  Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →