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 ><).
@hrefna Are you building an actor system as in #Erlang actors? (If so wow, that sounds amazing!) Or are there actor-based concurrency implementations available in OCaml already?
I'm starting to explore the OCaml ecosystem and I'm fond of the #BEAM concurrency model, hence my curiosity :)
There's a long-standing open PR for #wxFormBuilder to add #Erlang code generation for graphical user interfaces. https://github.com/wxFormBuilder/wxFormBuilder/pull/650
This, of course, would be awesome. I also discovered that you can build a whole GUI in wxFormBuilder, export it as an XRC file and then load the GUI into your wxErlang application. I had to figure out a couple of tricks, but it works nicely and you can build complex, good-looking GUIs with it (Linux/Mac/Win).
in terms of industry programming languages that any programmer can hit the ground running with little to no ramp up, #elixir does the best job imo. I never used ruby, but its all so obvious you can just get to work. and for distributed systems that need to scale in a flexible way, the #beam eliminates nearly everything that makes webapp development horrible. it's hard to make a good argument for any other industrial virtual machine. #commonlisp implementations being the exception.
Anyone looking for someone with a little bit of #Elixir and #Erlang experience?
You may know me from rewriting Elixir Logger back in 1.10, creating the CLI output for coverage back in 1.7, some work on OTP logger and socket modules, some work on OpenTelemetry Erlang implementation and stuff. I also helped people over ElixirForum, Slack, and Discord.
Ok, time to liveblog another paper! This time I'm reading a paper from Google published in HOTOS '23:
Towards Modern Development of Cloud Applications by Sanjay Ghemawat, Robert Grandl, Srdjan Petrovic, Michael Whittaker Parveen Patel, Ivan Posva, and Amin Vahdat
This blog post points out that automatically restarting processes can hide problems, which is certainly true. Doesn’t have to be systemd. Something like supervisor trees in #Erlang/#OTP might do the same.
If you’re restarting something, measure restarts and plot them on a graph. If it’s happening, understand why it’s happening. If it’s designed to fail, fail it on purpose at a regular cadence to make sure that failure is being compensated for correctly.
@lispi314@natty also #Prolog, where the program state can effectively be dealt with as "just" a cache of computations that gets refreshed on every program start.
That is ignoring the gnarly bits like external state that no environment has a chance of getting right.
Also #Erlang, the other extreme where you can design for not letting the system go down at all.
There are a few languages that thread this needle, but I'm a bit surprised that there aren't more.
In particular I've found the integration with #gitpod in #ocaml to be quite lovely and work exceptionally well and that eliminates a largish number of possibilities (e.g., clean, F*, to a lesser extent F#, Flix).
I know #scala and #kotlin quite well. I didn't really want yet-another-JVM language anyways unless very unusual. I knew #erlang at one point.
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.
1B users, 50 engineers. Yes, using simple and robust tech (#Erlang/#FreeBSD) helps. But note the part about keeping teams small (1-3 engineers) with a lot of autonomy.
So many companies miss this part and destroy all productivity.
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 finally finished my article on how to build #Erlang applications from scratch. If OTP applications and Erlang releases are still opaque to you, this should help.
Y’all: I have been wrestling with kbin on the fedia.io instance, but I want to take a step back and give some perspective. Kbin is new, it’s growing crazy fast, and it really wasn’t in a place to support the migration from Reddit. Despite that, @ernest has been working his tail off knocking down issues and helpings instance admins.
Reddit certainly seems to be tripling down on their position and I think kbin is shaping up to be a worthy alternative. If you like kbin (on whatever instance you use it on) and want to see it grow, may I ask that you throw some money Ernest’s way? (https://www.buymeacoffee.com/kbin)
I want to publicly thank Ernest for kbin and for his contributions to our growing fediverse community.
I'd still recommend something like #Erlang to handle that sort of horizontal scaling sanely, but having something currently working (however efficiently) is still good.
#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.