I guess one difference is the approach to concurrency. Node is still (as far as I am aware) single thread per process, and so tends to take the approach of using multiple processes (so that multiple cores are used) and some form of IPC.
Elixir (because Erlang) handles the distributing of 'processes' (not operating system processes but Erlang lightweight process) across cores for you. Erlang's been doing concurrency for a long time, it's very good at it.
The style of programming is very different in that you are encouraged to use processes in Elixir, rather than the callback style that is prevalent in Node. It feels weird at first, but pretty natural after a while.
I'm not sure there's much you can do in Node that you can't do in Elixir. But there are features in Elixir (again, because Erlang) like hot-code-reloading (update your app whilst it is running), and the way it can distribute tasks across nodes that I'm not sure are that straight-forward with Node.
It is great to see them releasing data, but I'm surprised they went with something based on Socrata given there are other OSS products out there. I can't imagine how much they paid - I guess that won't be in the data catalog anywhere :(
There's http://ckan.org (disclaimer, I work with this) and http://dataverse.org if you're more academically minded. There are others, but hard to judge any claims of open-sourceness without access to source code.
Most of my time I write Python, but I'm trying to spend more time with Elixir, and I haven't found using Erlang libs that hard.
There are a handful of rules to remember, if that, and it's reasonably straight-forward. module:func becomes :module.func, the erlang func probably wants char lists rather than strings, atoms are lower-case and should be changed to :atom, vars are upper case and should probably be lowered.
Learning the Elixir language is easy, thinking functionally less so (for me at least).
I'd suggest you find somewhere out of the house where you can go and work from time to time. I've been lazy of late (and regretting it) but I used to rent a desk at a local Hackspace where I could go and work for a day or two each week. It made a huge difference to my feelings of isolation, and also to my productivity on those days when I was at home. I also got to make new friends, which is always good.
The 'About Us' page says "As of today, the following companies have joined Advanced Erlang Initiative" under the "Founding Companies" header - which suggests more are able to join. Would be better if it were more explicit though I guess.
I'm really looking forward to seeing it grow, I've already found the videos very useful and the workshops look like a great idea. The more companies supporting Elixir and Erlang the better :)
Please, see my other comment, to avoid lengthy repeat, but in short, yes, the goal of the initiative is to grow and yes to be open to other companies that are developing Erlang products at the core of their business.
That's great, until code.google.com no longer resolves, at which point it won't help :( Would be nice if they used that info to automatically redirect to the new site.
I work on Google Code, and we will be putting a service in place to redirect
deep links to project homepages, issues, etc. to their new locations.
Projects on Google Code will need to set the "project moved" flag, under the
advanced tab of the project. But once set, things should work like you
expect.
QR codes for kernel panics is actually brilliant, because it encodes the data which would otherwise just be serialized to screen in a manner that makes it portable.
That actually might be nice but don't get your hopes up, systemd isn't actually part of the linux kernel as some conspiracy nuts would have you believe. The systemd project can't possibly just add random stuff to kernel panics, all of that code is in the kernel, not userspace.
I think a little while ago there actually was some work done on making kernel panics display a QR code but I doubt it'll ever be merged in if it's even done.
I think you're right, but if that's so, then apparently all of the features the OP claims to be bloat in systemd are questionably in systemd at all, and the entire discussion is moot.
