lazygit rules!

Huge fan of uv and ruff and starting to play around with ty. Hats of to astral!

My biggest problem with Elixir is the lack of support for 3rd-party libraries and the small community. I love the idea of it, but every time I try to ship a real project in LiveView, I'm left feeling like the community is not that mature. Maybe coming from a Go backend React frontend stack, that might be the case, but maybe for quick CRUD apps, it's great.

Elixir is pretty "nifty", and has Rails feels. I have worked on and seen its performance compared to scaled up Rails application. The BEAM / OTP is a very cool system to program on top of. I think it would be a great underlying system to develop a consciousness for AI systems with its concurrency paradigms and message passing, node connecting, other builtins. I'm not sure if the AI/ML focused Elixir projects like Nx have really taken off, but again, an Elixir based system that accepts numerous connections, passes messages around like exciting synaptic communications between functions... it just seems cool, maybe just on paper...

What do you mean "consciousness for AI systems"?

When you consider the message passing paradigm, I can envision how that simulates neuro-chemical communication between neurons (now here being functions that do things). So there is a design for communication between functions, then there are memory storage and information retrieval parts of the system, short-term RAM, long-term HD/SSD, databases, cache-systems, where relevant information can be and become manipulated. Long and short running processes, acceptance of fail-fast and that communications can fail and that's just part of software system life (I assume also a similar idea in the human brain, don't you find yourself forgetting something you were just thinking about?). There is then the external part of the system, accepting inputs from the outside.

The message passing paradigm is called the "Actor Model" and was invented in the 70s IIRC. It's available in most programming languages and it's not something exclusive to Elixir by any means.

https://en.wikipedia.org/wiki/Actor_model

Not exclusive to Elixir, but the BEAM was built from the ground-up around Actor for concurrency. Almost all other popular language ecosystems have it bolted on over time (with varying degrees of success) or relegated to a third party library. It's very natural and ergonomic in Elixir, because it's the paradigm of choice in the underlying vm.

Goroutines probably come closest.

> It's very natural and ergonomic in Elixir, because it's the paradigm of choice in the underlying vm.

Thank you, this is the key factor -- a fundamental design decision that influences the foundation.

Correct, it's not strictly unique to this. Even Ruby has it, but Ruby does not have BEAM/OTP.

Smalltalk was a fun language to work with, albeit academically.

Having built a mediumish soft realtime queue processing solution on rails I gotta say it was not great. If we didn’t kinda grow into it I would not have chosen ruby

Thanks for sharing. Yeah, I think that's a problem with bolted on functionality. Did you end up building a new version with a different language? What kind of problems did you encounter that made the solution "not great"?

We eventually managed to build something in sidekiq that did the job but if your jobs are not unrelated and you want to make sure not to starve any specific resource the options in ruby are just way worse than eg Elixir

Are you able to provide more context and details? It’s always interesting to learn about system design and architecture decisions from real world examples.

The issue was processing messages for live pro esports tournaments. Each game had to be processed and the biggest issue was that messages from the queue were not guaranteed to ordered and because of processing issues upstream you could get a large amount of messages for a specific match in sequence. Thus we decided to run just a light weight worker on the original external queue copying to our datastore which is very fast and can be run massively parallel.

Then run a unique job per running match that does the ordering and processing. This worked well enough but you need to now make sure that each worker gets called again after it finished and originally we had a recursion going on but the best place to do it was eventually deprecated in a new sidekick or unique jobs version update. We eventually settled on a supervisor that would monitor and restart workers. Which is just a bad version of elixir in the end

Just curious, what libraries did you miss in particular compared to Go?

I use it to prospect for sales. Otherwise I would prefer not to haha

I use linkedin a lot for work, and it's awesome. But a lot of the time I find myself scrolling the feed mindlessly instead of doing the thing I came to linkedin to do. So I (alongside claude code) built this little browser extension to block the feed while keeping everything else the same. It runs locally and you install it directly from source.

Finetuning a LoRA based adapter using a tool like predibase.com does this really fast. If you wanna go fully open source and have your own hardware you can do the same thing using a ludwig + lorax stack to do this yourself.

Can you please explain how you were able to fine-tune these models for less than $8?

We fine-tuned all of these adapters using Predibase. You can take a look at the pricing here: https://predibase.com/pricing

Thank you for this great write up that expresses the sorrows and pain a lot of us have been feeling.

Hey! I worked on this and it's great to see it being shared. Check out the blog post explaining more about the project https://predibase.com/blog/lorax-the-open-source-framework-f...

A great framework for serving many fine-tuned llms in production by quickly swapping adapters for the same base model (eg. Llama-2-70b)