While the initial compile time might be slow because of dependencies, subsequent runs are incremental and maybe take a second for me.
664 karma · joined September 28, 2013
It was a bit easier to learn because most of the keys are on the same finger as on qwerty, but with the rows swapped. For me the biggest problem with using an alternate layout is that the hjkl vim movement keys are scattered.
I do think that Lumen is potentially more interesting in the real world usecases though, and I wish you best of luck. Having an alternative Erlang compiler is a lot more complex but allows us to explore new techniques easier that could potentially be ported back to OTP if nothing else.
It was a big help initially to grok the bytecode format.
After I achieved both of those I decided I'll keep going if there's any interest in the project. There wasn't, so I moved on.
I do think that having alternative implementations is good for experimentation though, similar to how Ruby was improved upon ideas from JRuby and Rubinius, even if most users never used those two directly.
It was kind of interesting exploring the OTP internals, especially some of the parts that haven't changed in a long time. One example is the PAM: I think it stood for "patrick's abstract machine" and it would compile erlang terms into bytecode for pattern matches (intended for fast ETS lookups). It's all there in one file and it took a fair bit of digging to figure out how it works since it's been static for a long while and nothing on the internet really documented it.
I had a lot of fun working on this project, having implemented enough of the VM to run both Elixir and IEx before I stopped.
Ultimately development stalled since I couldn't get any community interest (I was hoping to give an ElixirConf talk but wasn't accepted either). Was hoping to raise some interest and find some contributors in similar vein to https://github.com/RustPython/RustPython
Nowadays I write a lot less Elixir and a lot more Rust.
I also don't see bus factor the same way you do. People can be smart enough to understand the code, but unless someone actually goes and actively takes up code maintenance the project will slowly fade and disappear (for example the synaptics driver that libinput replaced https://github.com/freedesktop/xorg-xf86-input-synaptics/com...).
> In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake. The driver now has over 70 configuration options resulting in a test matrix with a googolplex of combinations. In other words, it's completely untestable. To make a device work users often have to find the right combination of options from somewhere, write out a root-owned config file and then hope this works. Why do we still think this is acceptable? Even worse: some options are very specific to hardware but still spread in user forum examples like an STD during spring break.
> The xf86-input-evdev driver is in maintenance mode at this point. The last commit was in May 2018 and, since the 2.10.0 release four years ago, there have been a total of 19 commits. It is still shipped in RHEL 8 in order to support "crazy devices" that don't work otherwise. Similarly, xf86-input-synaptics had a 1.9.0 release in 2016 and has had nine commits since. It is effectively dead and all touchpads should be working with libinput at this point. Since libinput took over from xf86-input-synaptics three years ago, no one has stepped up to say they want to continue maintaining it, Hutterer said.
Most of the "announcement" type articles are mailing list quotes without context that don't link to the original source, but link to even more Phoronix articles.
$ tokei C: 492003, C Header: 58547
Total line count at 889658, "code" count at 716316, but 202314 of that is plain text which could signify documentation. It's still a lot, but not even nearly close the headline.
https://github.com/GitAlias/gitalias
g f && g rom
git fetch && git rebase origin/master
You could go nuts and make it even shorter with https://github.com/thoughtbot/gitsh
gitsh > f & rom