Ixiaus

If you're using spawn to fire off a long-ish running process that is too small in scope to justify making a gen_<something>, you might be doing it wrong. You can easily affix the logic you need as a process on a supervisor which will (very importantly) help clean up those processes for you.

A common pattern is to use a high-level supervisor for starting up the primary gen_<whatever>'s with sub-supervisors responsible for short-lived and long-lived "small logic" children - you can also ask a supervisor to add and start a new child and to remove one, let the supervisors do the bookkeeping!

Supervisors make your process trees declarative and help you avoid process soup, even when the processes aren't that important. I highly recommend harnessing that as much as possible when designing non-trivial Erlang programs.

1) Use systemd; I've taken the time to learn it and the tooling it exposes for codifying process dependencies, how weak or strong they should be, and restart behaviors is thoroughly designed

2) Use Erlang/OTP - I went this route for an IoT product I worked on that used Erlang as the primary high-level "firmware", I codified the process tree and dependencies and custom supervisor restart behaviors for unix processes into Erlang/OTP's supervision tree; using Erlang process ports

The second approach has worked extremely well for me in the past but I would only recommend it if you're going to use a lot of Erlang to process output from the programs it spawns for you, which was the case for how I was using it at the time, the robust supervision of the processes it managed in a supervision tree was incidental to the primary use but extremely robust.

THAT is where Haskell shines, the ability to refactor and expand fearlessly and aggressively.

I think for large or complex programs Haskell is much faster for constructing a skeleton because it's usually not the logical operations that trip us programmers up, it's the data flow and correct alignment of types, which are implicit in a dynamically typed language and explicit in Haskell.

So, it's kinda-sorta like writing your ideas down in a structured language which enables you to "see" the abstractions in a rigorous light, then the ability to refactor aggressively and safely kicks in so once you can see your abstractions you can quickly adapt for better ones.

So I think the initial work is made quicker in that it forces you to excogitate then because it's in some concrete form you can see it clearly and take advantage of quick turnaround time in refactoring.

I love nix, my biggest gripe would be that the Nix language is dynamically typed...

I really don't like docker.

I think stating the salary range and then providing examples of the CoL in the area without trying to justify the salary range in comparison to it is the best way to advertise the position.

Saying what you just said: We are looking for great candidates wanting to live in beautiful southern Idaho is compelling too (for people wanting to get away from the huge and congested cities).

Anyway, random internet stranger conversations, take it all with a grain of salt :)

Your generalization is not true. There are many reasons why a company does not want to post salary ranges and I'm quite sure that direct and non-hostile feedback about how copy for a job posting on Hacker News might be interpreted, is a small maybe even insignificant, reason.

It's fine to post the desired salary range for a candidate no matter what that range is, you'll filter out the people who are or are not willing to work for that range, which is fine.

But 80-120 in Idaho is not equiv to 150-200 in CA. Most outfits that I've worked for and spoken with pay based on "fair and equitable" comp and do not attempt to complicate the situation with a "cost of living bonus".

By phrasing it the way you have, it sounds like you're trying to get away with cheaper comp "because of lower cost of living" without actually considering that you're competing against many other companies willing to hire remotely that pay significantly more regardless of locale.

http://docs.basho.com/riak/cs/2.1.1/

I think it's remarkably important to surround yourself with people that are meaningful to you; that to me is different from things in common. Having things in common helps provide a medium for bonding but it's rarely the specific activity that is the focus for bonding, it's the shared experience that is.

There are lots of people that I call friends with whom I have little in-common, but there's a specific experience I've had with them or perhaps one specific thing to bond over that has created a strong connection.

Meaningful conversation is important too but I often find that trying to have a conversation I want to have can be productive. Many people are actually very interested in different ways of thinking or approaching life.

Our node cluster sizes are fairly manageable so we can tolerate the inefficiency right now but it will be nice to have a solution in-place when we want to optimize.

I did not know about HyParView. Thank you!

Note that CRDT stands for Conflict free Replicated Datatype and there are a few sub-acronym expansions: Convergent Replicated Datatype and Commutative Replicated Datatype.

[EDIT] I wanted to add that CRDTs were mentioned here because in order for them to provide the kind of guarantees they do they must satisfy the law of associativity (or, be a semigroup), commutativity, and idempotency. So, technically, you have to go further than semigroups with commutative semigroups. [/EDIT]

At Plum we made heavy use of CRDT's on-top of an eventually consistent whole-state replication technology called Plumtree, no relation to the company's name, just coincidence, within the internet-connected dimmer we built called the Lightpad.

The primary design goal was to enable advanced configurations: Arbitrary groups of Lightpads could be controlled from any other one on the same network by binding it to a specific finger gesture. We also did not want this configuration to be dependent upon any single master, they had to be truly master-less.

In-general, Eventual Consistency is pretty scary when you're deploying it to embedded internet-connected devices where you can't immediately shell onto the device like you can with a server in a data center. I have lots of stories here I'll write about sometime of the pains I encountered while developing this solution and how I ended up on CRDTs.

Strong Eventual Consistency (typically, CRDTs deployed on-top of an eventually consistent substrate), though, is very safe and provides a lot of guarantees about the concurrent behavior of the algorithm as it acts upon your data.

Using a CRDT (specifically the ORSWOT - Observed Removal Set Without Tombstones) eliminated the majority of our pains and concerns with data-loss, conflicting concurrent writes, and integrity in the face of flaky consumer-grade home networks (Plumtree is highly-available and partition tolerant - perfect for our needs where we have to be able to continue moving forward even if a majority or more of the Lightpads go offline and never come back up).

Don't initialize into env vars and don't store in repos, even private ones.

https://github.com/fugue/credstash

Parsing it wasn't hard but it wasn't fun...

We didn't rate limit, we would just increase the size of the cookie pool if a captcha was hit, which was rare because we would scrape n-pages till a threshold was met to prevent that session from being captcha'ed so we wouldn't have to captcha solve it. We had two pools, the primary pool and the "chilling" pool, cookies near their captcha life would cool off for a few hours before returning to the active pool which behaves just like any other resource pool, every page scraped would "borrow" a cookie out of the pool, customize the encrypted location key, and make the request with a common user agent string.

Scaling it was difficult but once we had it figured out, Erlang was invaluable to us and our dependence on IPs dropped once we figured out the cookie methodology.

Solving captchas is cheaper than renting IPs.

It was highly effective and very scalable because you can stimulate the captcha pages easily and out-of-band generate a very large cookie pool by captcha solving. Then when you go to actually scrape google you can balance your pool of IPs and cookies, chilling them before they trigger another captcha, to handle spiking demand. Contant, sustained demand was very easy to plan for.

Anyway, we stopped using the API after the third day and realized it was not only not accurate and you couldn't turn many knobs (want to scrape results as they look for a different geographical region?)