Hacker News new | past | comments | ask | show | jobs | submit | Somasis's favorites login

$7000? Sounds like dating apps are wildly underpriced, or they are not fit for purpose. Likely a bit of both. A girlfriend of mine once used a matchmaking service for profesionals that was priced in the $10k range and the stories she told me about them all seemed to have the similar theme, where if you want a person to represent something in your life (wife, partner, husband, etc.), it's a recipe for disappointment.

Durable relationships with friends are ones that just work because you don't freight it with external meaning. That we use a noun for a "relationship" between people at all is probably the root of a lot of its difficulty. Relationships as things are intractable, whereas relating and choosing how you relate is the simplest thing in the world. It's as though we codified relating into a noun so we could trade it, which makes sense when you look at "being in a relationship" as a proxy for being property, and matchmaking services that want to sell you one.

Intimacy does require a shared perimeter of safety, trust, and exclusivity relative to that specific personal intimacy, and you need to maintain it, but reducing it to role-playing expectations just turns it into a power struggle in the guise of a game.

For a lot of people, marriage is basically a dead institution, but we still go looking for someone to "make" a marriage with, as though it's a thing you make that is abstracted from the people involved. The same can be said for family, where we relate to "the family" as our reflection against an ideal of family, instead of each person directly.

Maybe I've been into the stoics too much, but the simple mental rephrasing of "my partner," to "the partner I have" changes how you relate to them, from being an extension or reflection of yourself to being an experience in your life, and it takes a lot of pressure off how you relate to them.

That last statement is a destroyer of codependent relationships, which is probably good because someone spending thousands of dollars to find someone to represent their idea of a "relationship," in which they like their reflection in it is just going to suffer. That is, until they don't need to check a reflection to know they're good.


  In an effort to get people to look
  into each other’s eyes more,
  and also to appease the mutes,
  the government has decided
  to allot each person exactly one hundred
  and sixty-seven words, per day.

  When the phone rings, I put it to my ear
  without saying hello. In the restaurant
  I point at chicken noodle soup.
  I am adjusting well to the new way.

  Late at night, I call my long distance lover,
  proudly say I only used fifty-nine today.
  I saved the rest for you.
  When she doesn’t respond,  
  I know she’s used up all her words,
  so I slowly whisper I love you
  thirty-two and a third times.
  After that, we just sit on the line
  and listen to each other breathe.

  Jeffrey McDaniel, “The Quiet World”

Wow, great post! I have the same complaints:

(1) Languages have gotten worse as distributed back ends have gotten more powerful. The IBM JCL and XML references in this post were good!

(2) Workloads that currently run on such back ends could run on a single computer, or at least with many fewer resources. This is one reason I got into shell in the first place! I wrote some shell scripts that saturated 32 cores instead of using distributed systems. In other words I try to avoid the "COST" or "parallelizing your overhead" problem.

We're paying a huge productivity tax and in many cases not reaping the rewards. I think a better better UNIX SHELL can help in the following ways:

(1) We need to bring the interactivity of Unix back to distributed systems. We're still in the days of "IBM Job Control Language" with Kubernetes config and similar kinds of "declarative cloud configuration". We need a flexible and efficient analogue of Bourne shell.

(2) Unix shell is already how you set up local development environments: Docker embeds shell; virtualenv changes your shell state, Ruby's bundler, OCaml's opam switch, etc. We need to evolve this into first class and polyglot environments specified in shell.

Debugging distributed systems locally could be the norm, but it's not.

The local topology should simply be a configured variant of the distributed topology, but it's not. I used to do this at Google with a trick of generating a shell script with BCL (Borg Config Language).

(3) A better shell should be able express configurations that evaluate to JSON, and also statically validate them before pushing, to solve this problem.

XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster.

I want https://www.oilshell.org/ to go in this direction, and there is already some progress. (Feel free to contact me if this resonates with you.) And I have a draft of a blog post about shell, distributed systems, and languages that I need to publish, based on these comments from a couple weeks ago:

https://news.ycombinator.com/item?id=25343716

Those comments talk about the other problem with the cloud: that it locks you in to APIs! We need the POSIX of distributed systems. Kubernetes was trying to do that, but it's not good enough.

Shell can solve this problem more economically: it expresses UNPORTABLE glue code to leave your application PORTABLE. I did that with Oil's continuous builds, and the Unix-y gg FaaS framework also appears to do that in a pretty nice way.


Regardless of how long it takes the interviewer to review them, I think it is pretty extreme to ask the interviewee to give 15 references, assembling 10-15 references, especially if you are young or maybe have worked at a small shop for a long time would be pretty annoying

Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: