Plan to stream about management of elixir projects with Guix in one hour and a half.
Will talk about transitive package management in general and why it's better not to package language-specific packages with Guix, will learn by example and clean up some tools we've made during the last month for Elixir in particular.
Pro Tip: Learn an old programming language. #Ada, #Erlang, #Pascal; #Forth or #Lisp if you’re hardcore. All of these have modern tooling. Don’t tie yourself solely to modern platform politics.
Sim-Diasca is a discrete systems simulation package written in #Erlang, developed at Électricité de France a few years ago. I'm surprised that Erlang is not more prominent in simulation frameworks. (of course, I'm not an expert on simulation). Are there other frameworks? https://github.com/Olivier-Boudeville-EDF/Sim-Diasca
The standard type of list in Erlang and Elixir being a linked list seems like it introduces a lot of undesirable patterns. It shapes how we match on them, how we add to them, what we avoid doing on them (appending, concatenating). It generally imposes and awareness and you also see it reflected in what API gets exposed. Standard libraries are trying to help you not do the less optimal thing.
Is there a way to move on from it. So much is built on it.
How would you do it? #elixir#erlang
#CommonLisp type declarations are a life saver, but they are fundamentally limited: you cannot use them to express that a list contains elements of a specific types. Frustrating given how ubiquitous lists are. #Erlang type specifications are much more flexible.
I don't yet know how to efficiently answer questions about the Swift language, so forgive if the answer is obvious.
Erlang/Elixir have a fault-intolerance library built on top of their version of actors. https://en.wikipedia.org/wiki/Open_Telecom_Platform It involves "supervision trees”, where supervisors control the lifespans of actors they supervise, react to unexpected failures, etc.
Found a nice talk on concurrency. It has a very brief comparison of different concurrency models, like Erlang's Actors, Hoare's CSP, Go's goroutines, Clojure's core.async, Concurrent ML (aka Fibers in Guile).
Primary focus on Concurrent ML (but examples are in Scheme with type annotations ><).
TIL #erlang / otp comes with wxWidgets bindings. From what i've seen so far it actually fills in a lot of the annoying gaps that i've seen in other languages. Like the event system connects very well to the established actor model..!
The frustrating part of #Erlang is that the language is so well designed that I always want to go back to it even though the ecosystem is a huge PITA. I should probably start to extend what I already wrote on the build part to handle more complex systems with dependencies.
I've been reading about #Erlang lately. I'm a little disappointed. Erlang seems real good and powerful, but it's not nearly as weird as I thought. I had somehow gotten the impression that it was #Prolog-level weird, but it's only #Lisp-level weird, which is not actually all that weird these days, since everybody else added some functional elements to their languages.
So I was ready to have my mind blown, but instead I only got it expanded.
What is the use case for #elixir / #erlang I have been reading more into functional programming languages, and one that pops up a lot is Elixir.
As far as I understand, the great thing about these is that they run on the Erlang BEAM VM, which seems to be very suitable to distributed computations right? Does this mean that the BEAM VM could run on multiple machines? If I understand correctly, Elixir/Erlang would not be that great if I just want to write simple CLI tools, but would excel if I was writing for example a Data streaming platform or the backend for some app right?
First reaction after installing #Erlang 27 rc1 (kerl build-install 27.0-rc1 27): yes ~"foo" is shorter than <<"foo">>. But 1/ it's a lot less ergonomic to type (try it!) and 2/ the default printer is still going to spit out <<"foo">>.
Hacked some initial #Erlang mode for the #Lem editor yesterday evening.
I have an Erlang shell but did not manage to connect to LSP/ELP, it hangs while initializing. Language server support is also still somewhat minimal in Lem.
I love the ideas in #Erlang, but I’ve never quite gelled with the language. So when I heard someone was porting the runtime to #OCaml, my ears pricked up.
Leandro Ostera joins me this week to explain how he's borrowing BEAM's best bits. 😅
Can the principles of moldable development be applied to Erlang? What would that look like? What is already there (good tooling for system insight, for instance)? #MoldableDevelopment#Erlang
Today I was writing elixir code the first time in my life, to convert mix.lock to json, for later processing and converting to guix package definitions.
One of the problems I faced is a lack of specification of lock file format.
I still have a few questions, but having sha256 in lock files is very promising. We will be able to generate package definitions for the whole project without accessing network.