HN user
OP here
Maybe they wanted to see if you would speak up and handle potential conflict. Or maybe they had a mixup between two candidates.
I did speak up during the call if that is really what they want me to do as I have literally 0 experience with that. It was literally my first action after I heard that. I pointed it out to them, that it is not what I was expecting from this position.
They didn't care. It was how they roll.
What do you mean there? What is not short-circuited there?
I agree that any company would struggle in such case. The thing is that everyone see that GH is pushing for more agents, their Copilot thingy, and AI everywhere, while basic functionality that people relies on is constantly failing.
If you push a lot of new features but your baseline is constantly failing, then something is wrong.
Author here - the goal from day 1 was to provide procfs/sysfs-like interface. The additional concepts that I would like to explore are bindings for Khepri[1] or Hobbes[2]. I see a lot of potential in such interface available from Erlang/Elixir/Gleam, as it can provide interesting use cases.
Why use a knife when you can use our EveryThingCutter-9000 that requires a week of training to operate.
It is using VM green thread, just more primitive one. Just to be more like other implementations (except anode) in original article that do bare minimum to run. Also, this isn't that unusual to use just `spawn/1` for simple and short "one-off" processes.
Yes it is. Though until the last paragraph everything is done more or less to be an idiomatic approach to this task rather than "just optimisation". The VM flags part though is solely "optimizing for the benchmark, by cutting features that we would have needed in real-world scenarios". The "RemoteCall" code is pretty idiomatic approach to such problem.
It is in the original article [1], though I was made aware that Go implementation is also incorrect as `defer` in it make the memory usage to substantially raise. So instead of:
defer wg.Done()
time.Sleep(10 * time.Second)
time.Sleep(10 * time.Second)
wg.Done()
Author here. If you have any questions, here I am.
But what would be a point of doing that?
That section was removed as it was leftover from the early drafts.
I have removed that part as it was accidental leftover from the early drafts that I forgot to remove.
I know about Podman, I just wanted to focus on systemd without additional tooling.
Erlang VM startup is ok, but it is not ultra fast, and it can be easily slowed down with many modules in releases or slow applications. Additionally as it was said - Erlang works best in case of long-running instances where the VM is handling spawning and managing of short lived internal processes.
First draft of this article also included the socket activation and FD passing section, but these were making the article way to long, so I moved them to the Part 2 where I will have more space for them. With socket activation Erlang VM startup time is negligible problem.
At the beginning I wanted to add all that information and options, but I thought that it can be overwhelming in this article. I wanted to focus on Erlang <-> systemd communication and basic options.
However it may be nice follow-up article where I will describe full hardening process.
Oh, I didn't know about `SocketBindDeny=` and `SocketBindAllow=`. This option may be a little troublesome in case of Distributed Erlang, but in recent versions it can be circumvented. Thanks, I will add it as a better option than adding capabilities.
This article? Not at all. Does you need to understand D-Bus to use systemd? Not at all. It is just implementation detail. I have an idea to leverage that in future to slap distributed service management on top of systemd, but in normal operations you will probably never spot that everything is D-Bus backed.
Actually I am using Zola, not Hugo, but the theme I am using is modified port of Terminal.
No, because these states are set on shutdown, and processes are killed in reverse order. So first the `draining` message will be set and then `drained`.
Author here. If you have any questions, then you can feel free.
My goal there was to provide simplest possible proxy that would allow me to dynamically add and remove the applications from the system during development. It provides passthrough TLS proxying as well as TLS terminating proxy. TLS terminating proxy will automatically create self-signed certificate (in future it will allow defining CA certificates as well as it should support working as ACME CA).
For creating sockets for services it uses systemd-compatible interface where there is FD passed down to the spawned process, this approach allows it to “simulate” socket-activated processes (which are IMHO great idea).
I assume that there is control character after carriage return that deletes everything from there to the EOL, so this do not break copy functionality or "go to EOL" shortcuts.
Unless you want to implement that on top of your custom structure, like, for example, b-tree. Then you either need to write N different implementations for each separate tree or you need to use `interface{}`.
Yes this is still true[1]
Elixir would create a telemetry
Erlang `telemetry` is something different from OpenTelemetry.
Phoenix (and other libraries like Ecto, etc.) would use it
And this is a fact. Both Plug, Phoenix, and Ecto are using Erlang's Telemetry library.
And the end goal was to have a Phoenix web UI that would come out of the box that you could goto and see a bunch of really useful things about your server's health
This will probably be implemented as an external library in form of OpenTelemetry as I said.
Did all of that get scratched for OpenTelemetry?
No, OpenTelemetry and Erlang's Telemetry have different goals. Erlang's Telemetry is meant to be lightweight metrics logging library with API for defining exposed metrics. OpenTelemetry is the OTP application that will ingest these metrics and will expose them to the external services like DataDog or Prometheus.
The official website at https://opentelemetry.io/ doesn't show Elixir as being a supported language.
[Not all languages are listed on the website](https://github.com/open-telemetry/opentelemetry-erlang).
hint that it was being worked on next and will be implemented into Phoenix as a web dashboard in the future but there was no hint of that mentioned this year
Currently there is EEF Observability WG that is working on integrating OpenTelemetry, so it will not be integrated into Phoenix, but will be more general and more cross-language solution for monitoring.
Source: I am part of that WG.
1. Each package in Nixpkgs repo has assigned maintainer mentioned in source. 2. Nothing prevents you from using your own repo/hosting solution for Nix channel. 3. Writing or overwriting packages in Nix is dumb easy, so I do not see a problem here as well.
I started using Nix exclusively on macOS and I couldn't be happier. The best part IMHO is the fact that I can easily test different packages without permanently changing my system and dealing with clutter left by these.
So in general, this is less of the problem that you think it is, especially as you clone that repo locally, so you do not hit GH/Savannah on each installation.
There is also quite older, but still maintained other implementation https://github.com/murarth/ketos
As far as I know there is no way for Erlang to automatically cast between types (except numeric, but these are treated as one type with variants), so by any definition that I know it is strongly typed language. Dynamically typed, yes, but strongly.
About other languages that are weakly typed in "current use":
- JavaScript is still weakly typed as far as I am concerned, nothing prevents you from 0 == "" and get true value. - PHP is still weakly typed, with optional type hinting but still sometimes can bite you in the ass
Erlang + Dialyser can be read as quasi-static typing, but it is still strong one.
As a Pole you shoul know better. It isn't true in all cases, i.e. Jadwiga was king, not queen.
You should try Cargo
Have you tried https://github.com/tomaka/glium?