dave_ops

Having had several offers to relocate to the Bay Area all I can really say is that almost nobody pays well enough to make it worthwhile. You can make $150k-200k in Seattle, Portland, Denver, Austin, etc. and work on some really interesting problems with marketplace leaders (often even for companies based in the Bay Area). You end up living like a king comparatively. You'd have to make at least 30-40% more than that in the Bay Area just to maintain a lateral quality of life.

Having now screened over 300 candidates for openings on my team, the overwhelming majority of them being people already in the Bay Area, about the only thing I can say is that with all the easy money sloshing around the economy there it's just way, waaaaaaay to easy to be a terrible engineer and still maintain being a highly paid "professional". Most of the people I screen/interview are advanced-IDE users at best or simply framework operators (i.e. they have no idea how the things even work that they're claiming to be experts in).

Sure there are a lot of bright folks too (law of averages and all that), but it's depressing to see what people are getting paid to do glorified web scripting or whose entire job function could be replaced with 50-lines of Bash.

I'm extremely drawn to funny women. I like that they play around mentally with cultural taboos and find creative ways of walking the line between making themselves laugh and making other people uncomfortable.

You can now do this in a sanctioned way in Erlang as of v18. They're including merl as part of the standard distribution now.

Seems reasonable to me... except I don't see the point of having foo/1 and foo1/1. The author could just have easily done:

  foo(bar) -> void;
  foo(X) -> undefined.

without the need for the proxy function:

  foo(X) -> foo1(X).

Your first paragraph is an expectations management problem on both sides.

That doesn't depend on the "technical" part of "technical leadership".

So "Elite Firms" basically have horrible hiring processes?

When I internalized this trend ~3 years ago, it's what spurred my interest in distributed storage systems across machines, racks, and datacenters, that are only memory backed.

The first versions of Objective-C were most definitely implemented as pre-processors to C compilation.

I'm a functional programmer (Lisp, OCaml, Erlang), and I only touch C++ when I have to wrap it in something to interface with a higher-level language.

Most of the cases where I run into this problem and end up feeling like I didn't gain much, if anything, from doing a straight C implementation are situations with deeply nested data structures.

I get that the thinking is that the benefit is that once I've made the compiler stop complaining, my memory management model should at least be sound and safe, and that is a win. Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language.

Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C).

This has been my problems with Rust for the last 10-12 months.

Lifetime elision seems thoroughly broken or extremely limited in functionality, and now when I'm writing (sometimes seemingly trivial) solutions in Rust I'm spending at least as much time and mental energy explicitly annotating lifetimes as I would be if I was just managing malloc and free in C.

As a result the pain vs. benefit curve doesn't bend nearly as far toward Rust as it theoretically should.

I realize they called this out in the article as "snark", but it really is just a blog engine, and its monthly web traffic is a small fraction of what wordpress.com gets (which is being served on one of the most craptacular platforms that exists).

They in fact could have solved this problem with Rails or even a more full-fledged CMS like BrowserCMS.

That's a terrible Faustian Bargain. The choice between someone who doesn't want to learn new things and someone for whom everything is new.

This is actually a good idea I think. Salesforce Chatter is a thing, and it sells well, and it's also terrible.

An on-prem corporate twitter would actually be useful.

But it's a SPoF and an extra remote or local service that has to be configured, maintained, etc. The thing that's coming online has to publish a message to redis anyway, so why not just maintain the service map inside the Rust application and open up a socket that allows those things to speak straight to Nucleon for mutating its configuration?

This has a redis service dependency? That is weird.