> 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.
The whole thing `false or true' is sent in for evaluation, so if there is a side-effect function that returns `true', it is executed too. Because Elixir treats it as a macro and not short-circuit.
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.
If you're seriously using agents, you'll know that if they didn't offer that then people would rapidly switch platforms if they didn't. Maybe not all of them yet, but soon it will be all.
Switch to a git provider that offers agentic augmentation of your workflow. And I don't necessairly mean the way it works right now - it's being refined & adjusted & infrastructure is being built as we speak.
For example, in our company, most commits on main currently have 3-5 authors (we squash): 1-2 humans, 1-3 agents (cursor cloud agent getting started, ppl pulling it into cursor locally to continue, then review using copilot review, modify using copilot agent) then use a vibe coded github app offloading UI test execution to a beefy baremetal machine to adjust baselines.
Copilot review in particular is just so good, better than any agent i know (incl opus 4.7). It just allows you to skip the first few review rounds by humans and fix simple but hard to spot logical bugs, keep docstring & style up to date across the codebase, before you give it to a human - which means everyone can focus on writing more code.
Setting all of this up, at a massive scale, is just not feasible for any of these projects.
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.
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.
i have the feeling the very first optimization ( not using the VM real green thread, but something lighter that doesn't provide debugging tools) is also something you wouldn't like to have in the real world..
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.
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)
In original article it should be:
time.Sleep(10 * time.Second)
wg.Done()
And memory usage will drop about 2x. I am no Go nor Java developer so I cannot say anything more.
> 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.