30 Days of Inbox Zero: How I Did it - <AUTHOR> http://waxman.me/30-days-of-inbox-zero-how-i-did-it <comment><USER3> I'm doing the exact opposite as Michael; but I can't say which of us has the better system. I probably get a lot fewer emails.

I've given up on inbox zero -- I now use inbox infinity. Everything stays my inbox unless auto-categorized (mailing lists, specific clients, etc). When I look through my emails, I flag any email I'm not dealing with right now. Otherwise I reply, leave it, or delete it. I archive anything old than 6 months every 6 months.

I suppose, in effect, my list of flagged emails is my inbox-zero but I feel more connected to whole stream of email with the box full. I occasionally need scroll to previous days and glance around.

I also have a Pebble so I'm effectively checking email instantly all the time. I find with the pebble that I dismiss things much more frequently now (emails, texts, and calls). Perhaps because the act of looking at the Pebble is so passive compared to checking my phone or computer.

<comment><USER4> An email in your inbox is two things: an imperative to act (reply, call, do something based on the email), and a piece of searchable supporting information for that action - or anything else, really.

So what you describe is pretty close already to inbox zero. The last step is to get even more aggressive about archiving things non-to-dos and trusting that archive search box. A truly empty inbox is more important than it may seem - new items are seen by themselves, standalone, instead of as part of existing glut of shit to take care of. And it's good to have the discipline to either commit to an imperative task or just say "no" \- either explicitly or via non-response.

<comment><USER3> My inbox is not an imperative to act -- only the unread bold items are such an imperative. Those are to be replied, forwarded, flagged, deleted, or ignored. If it's read then I've done one of those actions. No need to archive off the inbox to get that discipline. All the tools are there.

I found that it's a disadvantage to not have the stream of activity that Inbox infinity provides. All incoming email is sorted by date so I can always see my activity.

</comment></comment></comment><comment><USER5> I would never give access to my email account to a fly-by-night SAAS service. Nevermind the privacy concerns of mining my data, I just wouldnt trust their security practices unless they prove otherwise. An email nowadays is considered your identity. Any breaches to it can have a number of social, professional and financial implications.

Case in point, unroll.me mentioned in this article has a number of issues [1] [2] and response of Josh Rosenwald, founder of unroll.me at [3] dismisses that risk for perceived convenience.

[1] [https://plus.google.com/u/0/+SimonPhipps/posts/fJQZbGuoY9G](https://plus.google.com/u/0/+SimonPhipps/posts/fJQZbGuoY9G)

[2] [http://startup-stuttgart.de/unroll-me-complete-mail-data- tre...](http://startup-stuttgart.de/unroll-me-complete-mail-data-tremendous- security-hole/)

[3] [http://startup-stuttgart.de/unroll-me-complete-mail-data- tre...](http://startup-stuttgart.de/unroll-me-complete-mail-data-tremendous- security-hole/#comment-1361)

P.S. previous discussion of unroll.me security hole: [https://news.ycombinator.com/item?id=7035724](https://news.ycombinator.com/item?id=7035724)

</comment><comment><USER6> I feel like I'm the only person in the world who doesn't have this problem, even though I get a bajillion emails a day. Why is it so hard to hit Inbox Zero?

<comment><USER7> I would imagine it depends heavily on your email load. I get plenty of email, but the majority of it is automated, so with my gmail fitlers, I have only 2-3 per day that I actually need to read.

OP, on the other hand, is the founder of Grouper, and presumably gets dozens or hundreds of emails from real people requesting his time, input, or other resources. As such, there's significantly more effort involved in determining that a given email isn't worth responding to.

I don't know what your situation is, but I would imagine OP has significantly more real-person mail than the average HN poster.

<comment><USER8> Minor nitpick but the page shows he's the founder of Grouper, not Groupon.

<comment><USER7> Whoops, thanks. Updated. I was thinking of Grouper when I typed this, anyway.

</comment></comment></comment></comment><comment><USER9> I get around 50 emails a day, and hover around inbox 40

Removing all filters and categorization has helped me reach this number, and forced a few habits and mindset changes:

1: I aggressively unsubscribe from mailing lists. If you have to make a filter to automatically archive a mailing list because you never read it but want to keep it just unsubscribe. If you have to, bookmark the site but if you aren't reading it now when will you be?

2: I ask a lot more of the people who email me. If I have partial answers I send those immediately, and if I know I won't get around to it for a while I make it clear that it will take time. I err on the side of archiving unfinished conversations as if it is important most people are OK with sending a follow-up email.

<comment><USER10> I have a very similar system, and for the first time in well over a decade, my total inbox (spanning 3 gmail accounts) has hovered somewhere around 10-15 messages for the past 2 months.

Two questions decide the fate of every email "Is this from a person I know?" and "Will I ever need to search for this?" If both are no, then it's destroyed with reckless abandon. All others are archived immediately. No "read" messages in my inbox, ever. It's either "unread" or it's archived.

I almost always Send + Archive, unless what I sent was "I'll take a look in a couple minutes". And then I Send + Archive as soon as I send the next reply. If it sits in my inbox for over a couple days, I add it to Asana (if I haven't already) and archive the message.

I unsubscribe to almost everything automated (besides my own daily system summaries, which I delete once I've reviewed them).

One thing I would _love_ to have is the ability to set expiration filters on my emails. For instance, I like getting travel deals in my inbox, but I never need them for more than a day (since they generally only last that long anyways). Same for system summaries: Auto-Delete or Auto-Archive after 3 days would be perfect.

Also, since I don't use a local client for email, the "Checker Plus for Gmail" Chrome extension is pretty great, since it shows everything as a unified inbox, and shows me a single "unread" number so I know when I need to dive in and do some triage.

<comment><USER11> Why do you want to know if an email is from a person you know?

<comment><USER10> I like to have a history of emails from people I know.

<comment><USER11> If you could automatically have a history of emails from people you know, do you still need to know if a new email is from a person you know for you to manually process it? And if so, why?

I'm not so sure if I would want to destroy an email with reckless abandon if it's from someone I don't know but who know me. Maybe they want to get in touch about some of my work.

By the way, I liked the idea of expiration filters on emails.

</comment></comment></comment></comment></comment><comment><USER12> Can, uh, can someone please explain me how _exactly_ you end up with a hundred mails in inbox? Every day?

This is a genuine question, please bear with me. I follow several high-traffic mailing lists, and I use e-mail as my primary means of Internet communication, because I started using it back when ICQ wasn't all the rage yet. But they're all tidied up and filtered. Checking my e-mail in the morning takes, what, five minutes, plus 10-15 minutes or so of reading messages from the mailing lists that I actively read because they're really important for my work. Every couple of days or so I spend maybe another thirty minutes skimming the other mailing lists, but _an hour_ of e-mail is pretty much something that I've never done. Do various service-related e-mails pile up, like Facebook's neverending stream of notifications? If so, why is this news-worthy?

I regularly hear about it, and regularly hear that Gmail is particularly adept at dealing with this. I don't use Gmail; I have an old account there, opened when it was still invitation-based because every techie had to have one of course, but I'm not really sure about what else it can do other than, you know, filter messages. Are there any additional capabilities here?

And, Interwebs, please don't take this the wrong way -- I'm not trying to put up the smug l33t h4x0r attitude who doesn't understand how kids nowadays misuse computers, I'm really trying to understand how people use e-mail nowadays.

<comment><USER13> I think it's a very "role specific" problem.

You sound like you're in a really lucky situation where neither your specific job, not your organisation has a big email culture.

But, for a lot of roles or organisations they use email for distributed tasking. Even in a reasonably small technical team I'd say this is common - <USER2> you start receiving email that requires response due to it either being a task or it checking on status on a task.

It becomes even more difficult in situations where your response is required quickly as business is being blocked while you don't respond. A lot of (for want of a better word) middle management roles fall in this category.

There is a bit of the 'hero' problem about email management and far too much "FYI"'ing but it is a real problem. Ultimately, the cost to "send" an email is a lot less than on the X people who you just asked for a reply. So in some senses the impression of zero friction communication is very costly.

<comment><USER12> Thanks! Yeah, it does make some sense.

</comment></comment></comment><comment><USER14> i get probably 1000 messages a day. inbox zero was never a goal of mine, and never will be. i'm not really sure what the point of it would be. seems futile.

i have 3 things that help me keep my mail organized (my startup runs its own postfix+dovecot mail server)

* mail client on dedicated vertical 24" monitor

* procmail (mailing lists, alerts, tickets)

* spamd (spam)

everything else hits my inbox, and if i don't delete a message, it stays there, where it stacks indefinitely.

search bar + at-a-glance view of every important message i've received in the last N days is useful, i'm not really sure where this obsession for having an empty inbox comes from. that would actually hinder my productivity.

lots of ssd + ram = right now there's 29,453 messages (and attachments) in my inbox and it feels great. all of them are marked read.

<comment><USER15> yeah, unread 0 seems way better than having an empty inbox. what's the overall benefit with having 0 inbox over unread 0?

</comment></comment><comment><USER16> I wonder if Inbox Zero is a worthwhile goal.

My inbox is effectively one of my to-do lists. Since I don't cross off everything on my to-do list each day, my inbox usually has a few dozen messages. I have found that when I move an email to a "check later" folder, I never do so.

<comment><AUTHOR> pg has described email as a to-do list of tasks assigned by other people.

The social dimension is my reason for pursuing inbox zero. Especially as a founder, it's important a) not to be a bottle neck and b) to respect others by responding promptly.

</comment></comment><comment><USER17> My problem with solutions like this is that they never seem to fit any other people's methods of working. Saying things like "Only check e-mail twice per day" is not going to work for 95% of the people that are reading this (rough guess).

If I only checked email twice per day, I'd just end the day with 500 emails that need responding to all in one bunch. On top of that, many of them would no longer be timely, disrupting other people's days and slowing others down.

Am I alone in thinking like this?

<comment><USER18> If you get five hundred e-mails per day and many of them need replies on a timescale shorter than a few hours, presumably replying to e-mail is (a large part of how you do) your job. Which is fine; that means if you spend a few hours a day replying to e-mail, you're spending a few hours a day doing your job, which is as it should be. Articles like this one are addressed to people for whom e-mail is a distraction from their jobs.

<comment><USER19> > that means if you spend a few hours a day replying to e-mail, you're > spending a few hours a day doing your job

Sadly not. In the corporate world, if an activity doesn't have a timesheet task code associated, it doesn't exist.

Clearing e-mails doesn't have a task code, so effeectively it's a few hours unbillable on top of your working hours each day.

<comment><USER18> > Sadly not. In the corporate world, if an activity doesn't have a timesheet > task code associated, it doesn't exist.

Then don't do it. If that stops other people getting their jobs done, that's not your problem. Trying to fix dysfunctional organization problems with "I will work harder" doesn't get you appreciated, it gets you a ticket to the glue factory. (Reference from Animal Farm by George Orwell.)

</comment></comment></comment></comment><comment><USER20> edit: for those thinking that unsubscribe is a good idea. it's not. changing your email to a junkmail email before unsubscribing from services you don't need anymore is a better approach

for mutt users this is really easy to accomplish even with many mail accounts. create a macro file eg. ~/.mutt/macros:

        # have to be sourced on folder hooks
        macro index,pager ,a "<save-message>=$my_account_name/archive<return>"
        macro index,pager ,p "<save-message>=$my_account_name/pending<return>"
        macro index,pager gi "<change-folder>=$my_account_name/inbox<enter>" "Go to inbox"
        macro index,pager ga "<change-folder>=$my_account_name/archive<enter>" "Go to archive"
        macro index,pager gp "<change-folder>=$my_account_name/pending<enter>" "Go to pending"
        macro index,pager gs "<change-folder>=$my_account_name/sent<enter>" "Go to Sent Mail"
        macro index,pager gd "<change-folder>=$my_account_name/drafts<enter>" "Go to drafts"
        # vim: syntax=muttrc

now in your account hook do the following:

        folder-hook gmail \
           ' \
           set my_account_name=gmail ;\
           source ~/.mutt/macros ;\
           ....

afterwards type `T*,aG` and all your current email will be archived. from then on you can use the quick bindings for accessing all your mail with those shortcuts

<comment><USER21> If it's a newsletter they are sending you legitimately (ie, you signed up for it) then you should not be marking it as spam; just use the unsubscribe link.

Marking emails as spam can have a negative effect on the company and, if they didn't do anything wrong, you shouldn't be hitting them with that.

</comment></comment><comment><USER22> Another recommendation I would make (either to get to zero or get yourself to stay there) is to pre-commit to your goal using Beeminder ([http://www.beeminder.com](http://www.beeminder.com)), which will make you pay money if you don't hit a target each day. (Don't worry, it only counts "read" emails so you don't have to worry about emails coming in and causing you to go off track)

<comment><USER23> Is there a good "getting started with beeminder" guide? I tried Beeminder, and had no idea how to use it.

<comment><USER24> Last month, they published a New User's Guide: [http://blog.beeminder.com/newbees/](http://blog.beeminder.com/newbees/) .

</comment></comment></comment><comment><USER25> Not a big deal. I'm surprised this is a thing, been doing it daily since 2004. I don't really get the alternative.

</comment><comment><USER26> One _great_ way I have found is to filter all emails with 'unsubscribe' into a separate folder for reading later using this:

`Matches: ("opt-out" OR unsubscribe OR "viewing the newsletter" OR "privacy policy" OR enews OR "edit your preferences" OR "email notifications" OR "update profile" OR smartunsubscribe OR secureunsubscribe OR yahoogroups OR "manage your account" OR "group-digests")`

It really helps cut down unproductive emails

</comment><comment><USER27> Michael, what if I told you not only you wouldn't need to overly focus on hitting inbox zero but never have to use email again?

Intentdo was created for busy people like yourself and for the minimalists alike. It works outside the scope of email, it doesn't try to solve the 'problem' of email, it simply gives you a different paradigm by letting you ask to be sent intents rather than emails.

How?

The format: Intents are quick and encourage clarity. Own your time, welcome intents when you want to. If you choose to answer, a yes-maybe-no does it. This is intent-like: Intention + 4 actions, 250max

Here's the answer to your main concerns:

1\. "Have a method for writing emails (on both my phone and computer) without checking them"

The method is the very intent's format to draft a new intent.

"Without checking them" is the Waiting list where you see (if you happen to open it) whose intents are waiting to be welcomed by you thus unlocking its content. Good thing is, you decide when to.

2\. "...triage frequent mail sources that I want records of, but never want in my inbox (e.g. certain reports, shipping confirmations for online shopping, etc.)"

Even though Intentdo is only a week old, we're already working to launch upcoming features that will give you what you could say it's a Pinterest for your Dropbox. Interfacing with email, Intentdo not only will inspect your inbox (with your permission) for the services you're subscribed for and want to get notifications of but will organize your files for you.

I'd love you and everyone here to try and start asking people to send you intents rather than emails. I'd love also to know how you feel about it. To me, it's all about the liberating feeling of coming back to owning my own time, but most importantly, the great calming ripple effect it creates by encouraging clarity through the format which brings people to think thoroughly and edit what they're saying. Three words: Clarity. Integrity. Simplicity.

www.intentdo.com , invite code "replace-emails".

Send me intents at ^frank.

Note: just found out about grouper here. It sounds great. Invite accepted!

</comment><comment><USER28> As of yesterday I've been at Inbox Zero for 47 days. Before that my longest streak was 8 days. For me Inbox Zero is all about not having loose ends at the end of the day.

How I did it: 1) liberal unsubscribe. 2) ruthless delete. 3) scheduled time on my calendar to reply.

I remember on day 26 one message I didn't want to deal with stuck in my inbox. At the thought of breaking the streak I re-read the message and scheduled 30 minutes the following morning to reply.

</comment><comment><USER29> I'm making a to-do list for Gmail as a browser extension. It'll be free and I should have screenshots up in the next week if time allows. If you're interested, get on the list here:

[http://toduh.com](http://toduh.com)

</comment><comment><USER30> There was a discussion of Andreas Klinger's system that also included a Google Apps script for catching emails you forgot to mark as needing a response. I can't find it though - anyone have the link?

</comment><comment><USER31> I was just looking for a system like this. Thanks Waxman!

</comment><comment><USER32> just feel surprised there exist people who think using email filter is something worth showing off!

</comment><comment><USER33> Is anyone who gets a lot of emails use default Gmail filters, how do you feel about it?

</comment><comment><USER34> If you don't have any concerns regarding privacy or security, use Mailbox app [http://www.mailboxapp.com/](http://www.mailboxapp.com/) I do #inboxzero very easily and it's so piece of cake, I don't need to write blog post about to tell how I did it.

</comment><comment><USER35> I'm at Inbox 3580.

</comment><comment><USER36> Inbox zero is meaningless. It doesn't matter how many emails you have in your inbox; what really matters is to get to the important stuff first! So prioritisation is the key!

</comment><comment><USER37> None of you know what inbox zero really is.

</comment><comment><USER38> cmd + a, delete?

<comment><USER39> I do sometimes declare e-mail bankruptcy and just archive/move everything to a folder for later reference. To the OPs point, if something is important, people will generally follow-up.</comment></comment>


Tell HN: Allow your users to report fraudulent signups without signing in - <AUTHOR> It seems like every day I get someone signing up for an app and using my email.
There really needs to be a new standard one-click way of saying "this isn't me".
The current options are suboptimal for both "user" (aka victim) and company.
1) I try to unsubscribe and it works.  You have a user who doesn't receive any email communication from you.
2) I try to unsubscribe and it requires a login. You have a spam report.
3) If it's an app I may actually want to use in the future, I have to go through support to get your user kicked off their current account, possibly annoying them if they were a legit (but lazy or deceptive or whatever) user.  You have two annoyed users and a support burden.
In neither of these cases is the actual person who signed up:  a) dissuaded from doing this again, if on purpose, b) corrected and set up with a valid email, if by accident.
I've also noticed that for the few apps that make you confirm your email, failing to do so often does not prevent future marketing / re-engagement emails from showing up.  So what was the point of requiring confirmation?
Does anyone else have this problem? <comment><USER2> You are right. I experience this a lot. I have faced login to unsubscribe also. Your solution seems to be good.</comment>


Testing Without Mocks: A Pattern Language - <AUTHOR> http://www.jamesshore.com/Blog/Testing-Without-Mocks.html <comment><USER2> I like your article a lot. I do have a hard time to map the layers you've described (Application, Logic, Infrastructure) to a mobile/frontend/ui application.

For instance in Android we've Activities/Fragments (and less commonly Views) as the entry points to the application code. From there we might have [View Models]([https://developer.android.com/topic/libraries/architecture/v...](https://developer.android.com/topic/libraries/architecture/viewmodel)) and External API clients that are clearly _infrastructure_.

From what I've seen it is common to call the External API clients from ViewModels directly. (This is so we can test more logic outside of Android runtime, AFAIK.)

If I get the layers you've described we should instead let Activity/Fragment ask the ViewModel for some data and then use it to call the External API, correct?

<comment><AUTHOR> Thanks, I'm glad you like it. I haven't done any Android work, so I'm not sure how the A-Frame Architecture applies. From my quick glance at the ViewModel documentation you linked, that looks like Application layer code: in the first example in that document, the `loadUsers()` call would turn around and call the actual a specific Infrastructure Wrapper responsible for communicating with the service that provides the users.

</comment></comment><comment><USER3> > there's no need to create interfaces for dependencies

I think in this context you're using `interface` in the way that C# uses it: a point of abstraction and indirection.

I think you aren't using it in the API sense: the external surface of a thing.

If that's correct, you may want to clarify your wording. Perhaps "abstract interface".

<comment><AUTHOR> I meant in the term of the language construct. I'll think about how to make it more clear...

<comment><AUTHOR> I ended up just taking that paragraph out. I don't think it added much.

</comment></comment></comment><comment><USER4> Interesting innovation. Coincides with 2nd Edition of Martin Fowler's "Refactoring," for which he chose to code in javascript. Interested in feedback from the mocking pioneers — Steve Freeman, Nat Pryce, Keiþ Braiþvvaite — and, of course, the father of TDD — Kent Beck.

Is there sample code illustrating the pattern language?

<comment><AUTHOR> Other than the sample code in the article, my "WeeWikiPaint" project demonstrates most of the infrastructure patterns, particularly in its server code: [https://github.com/jamesshore/lets_code_javascript/tree/epis...](https://github.com/jamesshore/lets_code_javascript/tree/episode614/src/server)

</comment></comment><comment><USER3> > This can result in multiple tests failing when a bug is introduced.

One way I approach this is "a bug will only cause one test to fail _at that level of abstraction_".

</comment><comment><USER3> I don't see ports-and-adapters (aka Hexagonal Architecture) mentioned. Is that because you don't like it / don't find it useful?

<comment><AUTHOR> I don't feel like I fully understand it.

<comment><USER3> P-and-A makes Simulators possible, which are the one kind of test double I'm happy with. But your pattern language seems complete without it, so maybe I don't need it as much as I thought.

Simulators fit right where you have Nullable Infrastructure. Having a null object and a real object, instead of a single object with both null and real behaviors is how I'd normally organize things. I write my Focused Integration tests so they can be run against both the real and the simulator, to ensure that they both agree on the contract. And just like the Nullable Infrastructure, I can use the simulator in tests.

However, the real with with Ports-and-Adapters isn't the simulators (even though everyone notices that first). It's the way a good Port abstraction lets you organize your code well, writing it in terms that make sense in your domain, instead of in terms of the dependency.

This is worth exploring further.

<comment><AUTHOR> One of the key ideas of the Nullable Infrastructure is that all the semantics of the infrastructure class remain _exactly the same_ other than disabling external communication. So any logic inside the infrastructure code still runs. This is important because we don't have broad integration tests.

That's why the null code is inside the infrastructure, instead of using the classic Null Object pattern. It's also a major difference between it and classic test doubles. And perhaps your simulators?</comment></comment></comment></comment>


Git 2.11 has been released - <AUTHOR> https://github.com/blog/2288-git-2-11-has-been-released <comment><USER2> This is a really well written partial set of release notes. I was curious and looked at the full release notes [1], and I think these are pretty well written as well. I'm very impressed, especially given that git has such a large set of contributors.

[1]: [https://github.com/git/git/blob/v2.11.0/Documentation/RelNot...](https://github.com/git/git/blob/v2.11.0/Documentation/RelNotes/2.11.0.txt)

<comment><USER3> I liked this gem in L547:

> The code that we have used for the past 10+ years to cycle 4-element ring > buffers turns out to be not quite portable in theoretical world.

<comment><USER4> That piqued my curiousity, and I had to dig up the relevant commit: [https://github.com/git/git/commit/bb84735c80](https://github.com/git/git/commit/bb84735c80).

It deals with wrapping an integer index around after incrementing it, the old code just used ++index and a bitmask, the new code uses + 1 and modulo.

I have problems understanding this right now, in my world ++index for an int really shouldn't trigger overflow when counting to at most 4, on any (sem-)realistic environment?

Feeling extra dense, must have more coffee.

<comment><USER5> The counter never resets, it just keeps going up and we only look at the low bits. So eventually it will need to wrap. It's doubtful that ever happened in practice, even on a 32-bit system (you'd need to print 2 billion SHA-1s in a single process, and even the largest repos have on the order of millions).

So the key difference between the old and the new is that the counter resets to zero every fourth call.

<comment><USER4> Ah, right, that was the thing I failed to see. Obvious now, of course. :) Thanks.

</comment></comment></comment></comment></comment><comment><USER6> They were off by a factor of 10 with the likelihood of being struck and killed by lightning, according to the nws website.

To clarify: the likelihood of being merely struck by lightning is ~ 1/1,000,000 per year. The likelihood of being struck _and killed_ is 1/10,000,000 , or about 1/2^23.25

Given this, you would only have to be struck and killed by lightning 6.8 years in a row to equal a sha1 hash collision probability.

<comment><USER7> More importantly, the comparison is useless. The odds of running into issues with SHA-1 collisions in Git is a very different question from just the odds of two random SHA-1 hashes colliding.

<comment><USER8> Doesn't the birthday paradox make it much more likely to eventually occur ?

</comment></comment></comment><comment><USER9> Great write-up! I love the focus on performance in this release.

I've put together another write-up of the Git 2.11 release that discusses some of the other new features (and goes into a little more detail on some of the 'sundries'): [https://medium.com/@kannonboy/whats-new-in- git-2-11-64860aea...](https://medium.com/@kannonboy/whats-new-in- git-2-11-64860aea6c4f)

<comment><USER5> That is a nice writeup. One of the interesting things for me was to see which topics you decided to cover and which to omit. For instance, I noted `clone --reference --recurse-submodules` as a potential topic of interest, but I am afraid to point anybody to the `--reference` option due to its hidden dangers.

I'm also curious how you came up with 19,290 for a birthday paradox on a 7-hex hash. I think it's 16,384, but probability can sometimes be tricky. :)

<comment><USER9> Thanks Peff, congrats on the great release!

I came up with 19,290 using the generalized birthday formula[0] (actually after double-checking it's slightly closer to 19,291).

16,384 is the value you get using the square approximation method[1] which I believe is a bit less accurate in terms of probability, but faster to calculate. I think Git's using square approximation under the hood -- which is probably a good thing since I think it'll always yield a more conservative result.

[0]: [https://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_col...](https://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem)

[1]: [https://en.wikipedia.org/wiki/Birthday_problem#Square_approx...](https://en.wikipedia.org/wiki/Birthday_problem#Square_approximation)

<comment><USER5> Right, I am so used to the square approximation being used for hash collisions that I forgot it was an approximation. Thanks for setting me straight.

</comment></comment></comment></comment><comment><USER10> I'm curious but not motivated enough to really search for it, but for ambiguous hash abbreviations, why not select the oldest, since presumably it was unique at the time it was created?

edit: I guess that information must not exist or I assume they'd be doing it.

<comment><USER11> Yeah, I guess dates are only available for commits but not blobs or trees.

This is suggested by the disambiguation listing; if there were dates they would be displayed I hope.

I think approximate dates _might_ be inferred, but since it might be misleading and costlier to determine it makes sense to leave it out - at least in this version of git.

</comment></comment><comment><USER12> Converting to and from base 36 (or 32) would probably do more to help the problem than any heuristics. Compare:

      66c22ba6fbe0724ecce3d82611ff0ec5c2b0255f

to:

      c04bo5604v5qsp6asgasjp9y4paxu8v

That's approx a 25% gain in compactness.

<comment><USER13> [https://github.com/thanatos/baseunicode](https://github.com/thanatos/baseunicode)

<comment><USER14> Interesting, I was hoping for an example at the end of the readme

<comment><USER15> (I'm the author.) That is an excellent suggestion. Now that you've mentioned it, it seems like a glaring omission. I'll try to fix that up once I get home.

In case the other parts of the README weren't clear, the concept was to use _any_ Unicode character. I was even thinking of (eventually) getting it to encode data with combining accents. Note that it was intended to optimize the string for screen display space (pixels), _not_ space.

I'm not sure it'd be a good fit for git hashes, simply b/c sometimes you need to type or speak a git hash, and the output from baseunicode was definitely not intended to be pronounceable. (Esp. since I was thinking of using CJK characters, but trying to weight them down for their wider screen area; but imaging trying to describe that to a co-worker who might only speak English.)

I wrote it mostly for fun, after I had a couple of difficult to transfer files between machines in the cloud. I find myself ssh'd into weird places, and scp'ing is sometimes trying. (I do machine-to-machine, so I almost always need -3, which I don't know why that isn't the default; scp doesn't deal well with the file being only accessible by root, not your user; scp has the weirdest arg syntax if you have ill-advised characters in your filenames, like spaces…) So I was cat'ing files, copying them from one window, and pasting into another window. base64 for binary data, tar/gzip for making it smaller. But for the copy/paste, scrolling is a pain, and heaven forbid if you're in screen/tmux.

(Also, if you find yourself really without a file that you can't scp, you can "re-implement" scp with `ssh $hosta sudo tar -cz <stuff> | ssh $hostb sudo tar -xz`; see also the -C flag, and don't forget you can also `ssh $host "sudo bash -c 'cd /where && tar -cz <stuff>'"`)

</comment></comment></comment></comment><comment><USER16> Participate in Atlassian Research

My name is Angela and I do research for Bitbucket. I'm kicking off a round of discussions with people who use Git tools. Ideally, I'd like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.

We'll just need 30 mins of your time, and as a token of my thanks to those that participate, I'd like to offer a US$50 Amazon gift voucher.

If you're interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I'm located in San Francisco). Hope to talk to you soon!

Cheers, Angela Guo firstname.lastname@example.com

</comment><comment><USER17> It's been a while since I looked into what Git was up to in the latest version.

The release notes mentioned protocol improvements with git-filter that can dramatically speed up git-LFS (the large file storage plugin).

Does anyone know if there are any plans to make git-LFS part of the base instead of an add on?

<comment><USER18> I'd assume there's licensing issues before anything else: git-lfs is MIT licensed, git GPLv2.

<comment><USER19> It's a compatible license, so it's not an issue.

</comment></comment></comment><comment><USER20> I'm curious if anyone knows if the optimizations Twitter made to improve fetch performance for large, active repos have made it upstream yet? I don't work there anymore and neither do any of the people who were originally doing that work, but it was a pretty impressive speed up (I could git pull thousands of commits and be done in under a second on a 3GB repo with no large objects). I know the watchman support made it in, which was the other half of what made large repos perform well, but I haven't seen mention of the log-structured patch queue stuff that helped the server by eliminating most of the work to calculate what to send on a fetch. Anyone know?

</comment><comment><USER21> Hexadecimal dumps of binary data are the worst of all worlds if used as keys/references. Hard to memorize, hard to type, look ugly, aren't compact.

Better alternatives:

Base64 without padding: compact.

Grouped decimals: slightly less compact than hexadecimal, but extremely easy to type and pronounce. E.g. 577-467-341-467

<comment><USER22> Case-insensivity is important for some to be able to reliably remember a string. I won't easily retain the difference between 'b4dQbFs31' and 'b4DqBfs31'.

Same thing when speaking it out loud. 'B four D capital Q B capital F s thirty-one' is way more convoluted and error-prone than 'B four D Q B F S thirty-one'.

The best thing I've found that fits this criterion is Crockford's Base 32 [1], basically the extension of hex digits, removing letters ILOU.

But Base 32 (case-insensitivity by proxy) constrains us to 5 bits, which is only a 20% reduction over the 4 bits of base 16. So instead of the 20 bits `1ab2f` we could express them with something like `1qm3`.

Or we could be using words...

[1]: [http://www.crockford.com/wrmg/base32.html](http://www.crockford.com/wrmg/base32.html)

<comment><USER23> Regarding Base 32, I love the justification used for removing U. I, L, and O all have potential confusion with digits, but U was removed because of "Accidental obscenity".

<comment><USER24> I'm surprised it wasn't just "and all vowels" with the same reasoning, or at least 'a' (because I can more readily think of examples than for, say, 'e').

I suppose, though, there's an attraction in using b32 rather than b29... (Though I notice mid-word apostrophes are double-tap-selectable at least on macOS, so perhaps swapping 'a' for ''' would be advantageous, if more complicated to explain.)

<comment><USER23> The two "worst" swearwords that pop into mind both have "u" in them. Meanwhile, the swears with "a" in them seem to be the tamest of the lot.

<comment><USER24> "Tameness" varies extraordinarily by region - an infamous example being 'twat' which throughout the UK ranges from friendly to vulgar.

Regardless of variance, I don't think I'd regard either the above or the name of a fat character in Austin Powers as "tamest of the lot".

<comment><USER23> I find it interesting that you're willing to say "twat" but not "bastard". I admit that I didn't think of either of those words, though I think they're still much tamer than the ones with "u" in them. Really what I was thinking of was "crap" and "damn".

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> It's interesting that Git 2.11 shortened the delta chains on aggressive repacks, when mercurial happily creates chains of > 1000 deltas (afaik, it doesn't have a hard limit, it stops using deltas when the size of the required deltas is larger than the full text).

Although it's worth noting mercurial and git use different delta formats.

Edit: This is apparently what chooses to store a delta or not in mercurial: [https://www.mercurial- scm.org/repo/hg/file/9e29d4e4e08b/merc...](https://www.mercurial- scm.org/repo/hg/file/9e29d4e4e08b/mercurial/revlog.py#l1395) self._maxchainlen is not set by default.

</comment><comment><USER26> Jesus christ Git's interface design is horrible.

      Master Coder: Hmm. We refer to changes by a long, totally non-human-parseable string of characters that nobody can memorize,
      and when we abbreviate it, it doesn't work 100% of the time. What can we do about it?

      Novice Apprentice: Well... how about we stop using a long totally non-human-parseable string of characters that no
      human can can memorize just to briefly refer to specific changes in human-readable output?

      MC: What?! HERESY. Making a human use a cryptographic hash to reference a single random logical reference point in a mass of
      logical binary objects among millions of others is clearly the best way to go. We just need some quick fixes.

      NA: But... you can't reference it via speech, it doesn't work reliably via text when abbreviated, and it gives absolutely no
      context whatsoever as to what it is. What's the point of using a cumbersome, inhuman reference for something you
      only need to talk about briefly through a computer interface?

      MC: SILENCE FOOL! ME DESIGN GOOD. YOU MAKE CODE MASTER ANGRY.

      NA: Err... but what if we just let the program rename the references temporarily to human-parseable short strings, and resolve
      what they are in between logs and commits?

      MC: I SAID SILENCE!! Just for that, i'm going to make you explain to a new user why we force people to regularly clean
      our their repositories after doing complicated things with them, like merging.

<comment><USER27> > Git is full of some of the worst design decisions in modern software > history.

It's also full of some of the best software design decisions. The internals of Git are simple and elegant and they work like a charm. There have been very little changes to the internal workings since the first commit of Git.

I agree that the user interface is inconsistent, ugly and hard to grasp. But if you have a solid understanding of the internals, with the help of the git manpages it's pretty easy to achieve what you want.

There's software that's intended to work like a black box, just poke around the user interface and you can get stuff done. Git is not one of those. You need to understand the internal model, accept that the UI sucks, embrace the manpages, quit whining and get shit done.

<comment><USER26> > I agree that the user interface is inconsistent, ugly and hard to grasp. But > if you have a solid understanding of the internals,

You should not have to understand the design of the modern combustion engine to operate a car. You shouldn't even have to understand bicycle geometry to ride a bike. It's a friggin tool!

Why on earth would you _want_ to have to become a master of the design of a tool to use it? The whole point of making a complicated tool is to make your life easier! No other revision control system is this complicated and annoying. And i'm not going to quit whining, it sucks and it's stupid and it doesn't have to be, and people keep worshipping it like it's this amazing invention like nobody's heard of a merkle tree before. It treats chunks of changed text like blobs, wow, nobody's done that before. Oh a collection of packed objects, how novel.

By the way, the internals aren't that great either. You have to constantly "clean" your repository as it collects useless crap, merges become such a headache you're asked to destroy your merges to make it somewhat sane to maintain, handling "large" objects is a mystery to us, and the entire design is intended to interface with others and yet it's designed as if your personal repo were the only repo in the universe. You have to use a dozen filters and options and processes to do what a single script could do if it asked you what you wanted to get done, but we have to literally sacrifice a goat on the mountain of Unix Philosophy in order to get something done and go back to _doing real work_.

Why does it force us to send these anonymous patches and not allow merges to happen intelligently among a group using locks? Why does it force a maintainer to do all the work of managing patches? Why does it waste local storage when we don't need 99% of the repository most of the time? Why can't log messages and status be rendered in a quasi-usable way, or, heaven forbid, we have a Curses frontend for the myriad of random chunks of text and commands we have to memorize to accomplish one small simple operation? Why does the repository fall apart into a completely unusable mess if you don't weed it once a day? Why do we have to shuffle around a bunch of commands to perform a single simple task that any reasonable program 15 years ago would have done for you?

Answer: Because the design is crap. If people would at least just _admit_ the design is crap, I would stop whining. But at this point I feel like i'm the only sane human in a world full of people doing the work _for the robots_ and smiling about how much easier their lives are now.

</comment></comment></comment><comment><USER28> Big fan of the negative parent selector for merge commits. Also enjoyed the writeup of the algorithm improvements for the various caches.

</comment><comment><USER11> What a _great_ writeup.

</comment><comment><USER24> When a non-ambiguous short-hash _becomes_ ambiguous, can't it be disambiguated by simply disregarding those not in existence at time of reference?

<comment><USER29> Imagine if you merge a branch of old commits from another repo or something, which introduce short hash collisions. Then you copy/paste a short hash, and Git doesn't know when that reference is from or which branch it might refer to.

</comment></comment><comment><USER30> Why doesn't git upon commit ensure the sha-1 is unique by having some nonce as part of it?

I guess if you only work with rebases instead of merges, it should be possible, right?

<comment><USER31> It would defeat the purpose of a content-addressable storage system. The fact that the same file and the same tree will always have the same hash is important for speeding up diffs, merges, and other operations.

</comment></comment><comment><USER32> Git is the worst</comment>


Problem in Rust adoption - <AUTHOR> http://sanxiyn.blogspot.com/2016/06/problem-in-rust-adoption.html <comment><USER2> There's no supporting details?

"C++ programmers find it difficult." Says who? I doubt someone who slogged through enough pain to learn C++ would be fazed by the weird parts of Rust.

The Rust language is not at all a significant barrier to its adoption. I think that the fact that Mozilla refuses to standardize its development and has a history of political-correctness inclusivity is a bigger barrier to its adoption. Especially given that C++ has been around for so long already, is always (very slowly) improving, and is already standardized. It's not a great language in the sense that it's FUN to program in, but neither is Rust, and even if it was, it's not a good enough reason to throw away c++.</comment>


Ask HN: Why are Covid-19 death rates low in US - <AUTHOR> Serious question. Italy has a ~10% death rate. Spain is pretty higher too. So what's driving the difference? Is it treatment or otherwise that results in a low death rate for us?
US ~70k infections ~1k deaths Italy  ~75k infections ~7.5k deaths Spain ~55k infections ~4K deaths.
What's causing the difference? Treatment, numbers misreported or something else ?
Data source "johns Hopkins covid dashboard" <comment><USER2> First, the rate is not very low in the US, relative to places like Germany.

Second, the 'death rate' is not a matter of deaths/cases, because the # of cases is very much dependent on testing. More testing is more likely to yield the cases that are not aggressive. So we'll have to do a lot more testing everywhere to get a real picture.

Third, there's a delay in all of these numbers, they eventually converge, but if there's a period where there's 'big change' in whatever measure, it will take a few weeks at least to even crudely converge. The US is just starting now to get hit with a lot of hospitalizations, so the death rate will probably spike a little bit.

Long term, it may be due to things like average age, the quality of care, how hard the hospitals were hit (i.e. if some people were turned away because of overflow) death rates will be higher.

Of course, the overall death rate/capita (not deaths/infected) will likely to be due to how hard the nation was able to adapt, shut down etc. and how bad the inherent r0 was in the first place as there is evidence that it's slower moving in warmer climates.

</comment><comment><USER3> USA is starting to do a lot of tests. Same for Germany.

So virtually keeping the death rate low.

Other countries are testing only people already sick with a lot of symptoms (==hospitalized). If we were testing "everyone", dead rate would be lower in Italy,...,...

</comment><comment><USER4> Most hospitals in the U.S. are only starting to reach the point of ICU overcapacity, staff shortages, and ventilators. Italy and Spain are about 1-2 weeks ahead of the U.S.

<comment><AUTHOR> That makes sense top of my head. Hospitals overfilled with patients and understaffed with medical pros and resources means more sick people will go untreated and hence higher probability of deaths. So if what you state holds water then in two/three weeks we should be seeing the rate go up drastically. Right in time for the economy to be "raring" to go according the nations leaders and imbecile in chief</comment></comment>


Meet the Shenzhen maker ruffling Silicon Valley's feathers - <AUTHOR> http://www.newsweek.com/naomi-wu-sexy-cyborg-misogyny-silicon-valley-704372 <comment><USER2> Interesting is also criticism of her from the other side, where she is derided for being overly sexualized or promoting objectification of women. No winning. :(</comment>


An Introduction to WebObjects, in Swift - <AUTHOR> http://www.alwaysrightinstitute.com/wo-intro/ <comment><USER2> From 2006-2008 I worked in a WebObjects dev team, and it was extremely enlightening.

So, so, so much of the work is done for you with WO, it's so much faster to just get down to business and code in your business logic. To this day I miss everything being done for me.

I genuinely hope Apple find a way to resurrect it.

EDIT: Project Wonder[1] gets a mention in the links section. This is a "mod pack" for WebObjects that is like putting it on steroids. Seriously impressive stuff.

[1] [https://wiki.wocommunity.org/display/WEB/Home](https://wiki.wocommunity.org/display/WEB/Home)

<comment><USER3> While I'm skeptical it would really be a server driven full stack web framework like it was in the past, a bit more effort on the server-side Swift front would definitely be appreciated. It seems like a small dribble of resources is currently invested in that, and overall I don't think it's ever really going to take off unless Apple really gets behind it. The stuff the community has done is cool but it's not good enough to build a large and sustainable ecosystem.

</comment></comment><comment><USER4> Wait, is webojects dead or not? It says wo6 is coming in 2018, but the project is killed... I see it's voluntarily bring maintained by a community, are they releasing?

<comment><USER5> It's community and yes lots of releases

</comment></comment><comment><USER6> It actually looks pretty nice (imo), but also seems like another one of those, "well, we'll see if it picks up any steam in a few years..." kinda situations.

The article is also clearly written and informative.

</comment><comment><USER7> This smells very much like ASP.Net web forms, horrible viewstate parameters, terrible URL design, etc.

Haven't we moved past this?

<comment><AUTHOR> Although the comparison with the ASP.net clone sounds like an insult to WO, you are right: we definitely have moved past this! :-) As outlined in the article: [http://www.alwaysrightinstitute.com/wo-intro/#web-20-ajax- an...](http://www.alwaysrightinstitute.com/wo-intro/#web-20-ajax-and-beyond)

Though funny enough client side frameworks today are plagued by pretty much the same issues WO had on the server side. (or in other words: the web is a document platform, not very well suited for applications)</comment></comment>


Software sucks - <AUTHOR> https://shitpost.plover.com/s/software-sucks-4.html <comment><USER2> The reason for pretty much any bug found in software driven by a huge company is that there is a large disconnect between fixing bugs and profit. Fixing a bug almost never excites users, and even if it did in this case, they won't see a measurable increase of users of their software, so you can't prove a profit increase.

Even if a bug is fixed, the effort might be wasted when a large overhaul of the system happens because they want to add a huge feature, like a new searching system or some internal backend refactor. Fixing the bug might be much more difficult than you think due to the scale and complexity of their database or some other reason. Then the change needs to flow through the review and testing pipeline.

My point is to explain that software gets harder with scale, which might cause a bug like this to cost tens of thousands of company dollars to fix, while the benefit to each user (and therefore the company) would be a tiny fraction of a cent, so both managers and financially-aware engineers would easily brush this off as "not worth it." Any argument of the form "why not just fix it?" would be countered with "you could say that for any of the 40k open bugs."

<comment><USER3> This isn't a bug. Recommendations are just hard.

He's trivializing it, but specifically mentions that including one 5.7 miles away would be fine. And then promptly says because he visited it before.

That's some complicated intelligence and pattern matching that he's asking for. What exactly should it be ranking by? Proximity and popularity and traffic density and Google rating and awhole load of other things.

The rules that Google apply obviously work for some scenarios, but not this one. Could it be better, obviously, but that's not a bug.

<comment><USER4> > _This isn 't a bug. Recommendations are just hard._

What is hard about ordering a bloody list of places by distance?

> _He 's trivializing it, but specifically mentions that including one 5.7 > miles away would be fine. And then promptly says because he visited it > before._

Well, they could first add the bloody sorting, then we can think about whether they should mark or prioritize previously visited places (which itself does not take any "complicated intelligence and pattern matching" \-- it's just persisting visited places and consulting their list).

<comment><USER5> I like you feigned exasperation at the simplicity of it all and then immediately noticed one of many many complicating factors.

<comment><USER4> My point is that all the "complicating factors" are still trivial -- each alone, or put together.

My second point is also that even if they weren't (for some exotic cases) , the most common cases and sane defaults, remain trivial -- and anything else could be relegated to settings and the like.

My third point is also that no matter how easy or hard the complicating factors, a screen like the one shown by the poster, is an utter failure.

To continue on this 2nd and 3rd point, it's like people are trying to defend Clippy, the office assistant, by saying that "AI is hard".

It might be, but getting Clippy out of my bloody monitor and not having it disturb me when I try to compose a Word document, is very easy. MS could always do that (and that's what they ended up doing).

</comment></comment></comment></comment></comment><comment><USER6> Unrelated but similar and I feel like venting... On Google Maps you'll search for something, and the results are shown as a list that almost covers the entire map. It's Google MAPS and it hides the map for so many things. I'd rather go to a place that's 3 miles straight down a free way than 2 miles of stop lights, but I don't know that if the map is covered!

<comment><USER7> Or why's it so hard to get it to show a street name? It will show some, and it won't show others. If the one you want is in the latter category you've got a lot of zooming before you see it. Ugh.

<comment><USER8> That and for some reason the scale only shows up while your zooming and for a couple seconds after. I want to see it all the time, damn it!

<comment><USER9> Go to settings and select "Show scale on map" / "Always".

<comment><USER8> I swear I've looked for that setting before. Thanks!

</comment></comment></comment></comment></comment><comment><USER10> It's showing him Wawas he's been to before. That's what the clocks mean.

For the search "wawa" it doesn't make a lot of sense to prioritize history over distance, because Wawas are nearly identical. But for "farmer's markets" this would probably be a useful feature.

Figuring out how to differentiate between those two examples algorithmically is super non-trivial though

<comment><USER11> This is incorrect: the clocks mean he has selected those search results before, not that he has physically been there.

Source: Just tested this in-app.

<comment><USER12> Oof, that's really bad if that's the case; it means that a mis-click can poison your search results and make them less useful.

I get that Google's all about saving clicks now, but I've noticed between maps and other apps (Google Music comes to mind) the extra inference sometimes just makes me scared to click on things.

Can you at least long press or something to remove a location from your history?

<comment><USER13> This is usually true for any big website you browse on the internet. Any click on Facebook or Amazon is influencing the content you're going to see.

Google has a user history website where you can see everything they recorded from Search and other apps, and you can delete the entries

<comment><USER12> This is one of my biggest pet peeves with modern recommendation systems. It's like somebody decided "no, the user can't click a 'show-me-more-like-this' button, it has to be automatic" and now I have to treat every website like I'm doing reinforcement training with a cat.

But at least with AI there's something marginally close to an excuse, because you need a ton of data to make it work. With maps it's just plain and simple bad UX design, I can't think of any reason why locations shouldn't be sorted by last visited instead of last clicked.

> Google has a user history website

From a usability standpoint, if it's not accessible from the same same interface where your results are displayed, then it doesn't exist.

</comment></comment></comment></comment></comment><comment><USER14> I think the clock icon next to the entries they're complaining about means that it's surfacing them because the user had looked at those particular stores' search results before, and would likely want to revisit those search results.

</comment><comment><USER15> I feel that the worst new "feature" in Google Maps is when you're on your way to your destination and it suddenly suggests you might first want to go to a random place you've never heard of before. You then have 3 seconds to tap "No" before it silently adds the destination (and 15-30 minutes of extra driving) to your route. I have found no way to disable this feature.

I'm worried that there could be people who were in a hurry to get somewhere and perhaps wound up in a grave instead because they felt the urgent need to look away from the road and fiddle with their phone to reset their map destination while on the highway.

<comment><USER16> Huh? This has never happened to me and I use Google Maps daily. Is there an update note or something for this?

<comment><USER17> Same. This is news to me as well.

</comment></comment></comment><comment><USER18> Google Maps apparently thinks I'm Prompto from Final Fantasy XV, and will send me alerts of points of interest (usually restaurants) suggesting I take pictures of them.

Uh, no. If I want to go somewhere, I'll ask you, Google Maps. It's shit like this that makes me glad I switched to OsmAnd (despite the latter lacking in features, such as finding an optimal foot/bus/train route).

<comment><USER5> You can turn off those adnotifications. They are kind of annoying, but one popup plus a button to block future popups is a small price for a powerful app.

<comment><USER19> For those unfamiliar. On android phones you can just long-press a notification to disable that notification category from that app. Granted most apps lump all their notifications in a single category, but google maps is not one of them.

</comment></comment></comment><comment><USER20> Budapest, a city of two million has place names only unique per district, there are 23 of them. So this is ubiquitous there, for example if you enter "deak ter" it will bring up some insignificant spot out in the boondocks instead of the central square of the city with three underground lines, the terminal of the airport bus and so on...

</comment><comment><USER21> He should be happy it actually looked up the place he wants. I go to maps.google.com and not only does it give the wrong town for my location (correct GPS coordinates, it just won't acknowledge the town exists even though it is the reservation seat of government), but the first result for "gas station near" is a Catholic Church and then gas stations in the next, next town over. Google doesn't seem to know about businesses on the reservation. Apple, sadly, is worse.

</comment><comment><USER22> Usually happens due to very high uncertainty in localization estimates.

<comment><USER23> Looks like it prioritized historical locations over nearby locations. The little clock icon usually represents a prior location that was selected.

Could be an interesting design approach to know which locations are "fungible". I.e., one Wawa is as good as another, but your parent's house isn't a replacement for mine [1].

[1] I'm sure your parents are very nice, of course :)

<comment><USER24> And ironically the OP was complaining that it didn't return him to the same WaWa:

> Last time I asked for directions to a Wawa, it was to the one on Oak Lane, > 5.9 miles away. Why doesn't it guess that I might be trying to go back to > the same place?

</comment></comment></comment><comment><USER25> Consider using a better geocoder? [https://pelias.io](https://pelias.io)

</comment><comment><USER26> Have had this problem many many times, maybe someone from big G will tell us why

</comment><comment><USER27> Software does not suck; requirements, especially from non-technical stake- holders suck. Every single piece of software starts with a single and easy to understand idea, then different stakeholders arrive and start adding inputs and often conflicting requirements, and then software starts to suck. None of these would have happened if we knew how to say "No". :(

<comment><USER28> I see you've read that terrible book by uncle Bob and now you're a professional coder. :)

<comment><USER29> What book are you referring to?

<comment><USER28> The Clean Coder

</comment></comment></comment></comment><comment><USER30> Case in point, the site is down.

</comment><comment><USER31> I'm working on b2b software and when working with the designers at [http://fairpixels.pro](http://fairpixels.pro) I've learned many things from their approach as to why (a lot of) software sucks. Personal example: I've been measuring qualitative feedback users have been giving us and passing it to them to make design updates. They (design team) would come back with me with questions about data & metrics. They were more interested in what the users DID vs what they told me. This sounds small, but has made a huge difference in the way I look at product design & development. The things users told us in a few cases, didn't match the way they were acting in the product. After some research, we found out why and managed to redesign those features and solve the problems.

The thing with most software, just like ours, is that many of us engineers don't have the deeper design knowledge to really understand how a product needs to be build from a user's perspective.

<comment><USER32> One thing I've learned is that the user's complaint is always valid, the user's proposals seldom are.

That is to say, users know when they don't like something, but they are often wrong about why they dislike it or what is interrupting their workflow. Our job is to find and fix the root cause starting from user feedback, and fix the product in accordance to what the user is actually trying to accomplish.

This is often very hard

<comment><USER33> What's interesting about this, is that user complaints can be suspect too. I read an anecdote recently about the American auto industry. They'd ask people about what they didn't like about the cars they bought. And they'd get all these complaints, then try to build cars based on those complaints. The problem was, many of the complaints were for things that took them out of the market for the car they bought. For instance, people who bought sports cars would complain about lack of doors, or lack of back seat, and so GM or Ford would build a car that wasn't quite a sports car, because it was too big, and it wasn't quite a sedan (for whatever reason, too sporty? whatever that means?), and so no one bought it.

I honestly don't know what the solution to this problem is, since feedback is invaluable. I guess, always be careful?

<comment><USER34> I'm suddenly reminded of the car that Homer built:

[http://simpsons.wikia.com/wiki/The_Homer](http://simpsons.wikia.com/wiki/The_Homer)

I suspect there is a lesson there about using aggregate feedback, rather than listening to single individuals.

</comment></comment></comment></comment><comment><USER35> The HN hug of death strikes again.

Cached version from Google: [https://webcache.googleusercontent.com/search?q=cache:E3wiNT...](https://webcache.googleusercontent.com/search?q=cache:E3wiNTW62PUJ:https://shitpost.plover.com/s/software- sucks-4.html)

<comment><USER36> Definitely not. My site hits the front page of Reddit a few times a year and handles it just fine. Today's HN hit was only about twice as much traffic as a typical day.

<comment><USER36> Case in point: my article about traffic control systems ([https://blog.plover.com/tech/highway- stuff.html](https://blog.plover.com/tech/highway-stuff.html)) is on the front page and has already received twice as much traffic as this one, and the West Coast hasn't even come to work yet.</comment></comment></comment>


Novichok nerve agent strikes two new victims in the UK - <AUTHOR> https://www.theverge.com/2018/7/4/17535024/novichok-nerve-agent-strikes-two-new-victims-in-the-uk <comment><USER2> "The British Government's 'Novichok' Drama"

[http://www.moonofalabama.org/2018/03/governments-decree- trut...](http://www.moonofalabama.org/2018/03/governments-decree-truth-about- skripal-dissenters-will-be-punished.html)

</comment><comment><USER3> Novichok is the most ineffective 'military-grade nerve agent' ever produced.

5 known victims, 5 survivors who have lived more than several days.

<comment><USER4> I'm still on the fence about how far into the conspiracy theory land I'd go – but if you imagine that this nerve agent though, it could kill, in these instances, isn't meant to kill, but rather, to show force, and penetration. A "see what we could do" – with the understanding that they could use something more subtle than Novichok if they wanted to.

</comment></comment><comment><USER5> Could be food poisoning from the same restaurant at which the Skripals ate. Nerve agents tend not to be so delayed or forgiving.

</comment><comment><USER6> Just before the Russian elections and the World Cup we have the first Novichok "attack". UK gov demands boycott of the world cup and all the news focus on Vlad "the Killer" Putin.

Russia starts doing well on the world cup, Sweden changes its mind and won't boycott it, trump-putin meeting scheduled and.... Novichok again.

It should be easy to see the BS of this narrative but the most amazing thing is that it works. People believe in it, demonize Russia and lose focus that the UK is miserably failing in the Brexit negotiations.

I hope Russia does not win the World Cup because I'm sure we would see another "attack" directly ordered by Vlad The Terrible.

</comment><comment> the-dude Did it ever strike the first victims?

<comment><USER4> Not sure what you mean? Are you saying in order to be a victim of an attack one must die?

The previous victims may be alive but they are still victims.

</comment></comment><comment><USER7> Perhaps it could be helpful to fly a drone over Red Square, dispersing a spray with microdots that read: "This could have been Novichok, Tovarich. Stop it, already.".</comment>


Every Entrepreneur's Least Favorite Question - <AUTHOR> http://blogs.hbr.org/cs/2013/05/every_entrepreneurs_least_favo.html

<comment><USER2> Spending time preparing your answers to these seemingly trivial questions can have a big impact. "How's it going?", "What do you do?", and "Tell me about yourself." are three great questions to spend a few hours thinking about. It's worth it.

</comment><comment><USER3> I have recently-ish started experimenting with just sharing one random personal thing that's on my mind when people ask me how I'm doing. It's much more interesting, but, you know, kind of hard. You have to open up to people, be vulnerable, stuff like that. It's scary.

Then again, time and again, research has shown that personal relationships are built on mutual vulnerability/openness. Can't really expect to have cool relationships without that.

Really though, it's fun. Try it. Don't be awesome all the time, be human sometimes too.</comment>


Two Ancient Roman Techs Could Disrupt Modern Industry - <AUTHOR> http://www.forbes.com/sites/alexknapp/2013/08/25/these-two-ancient-roman-techs-could-disrupt-modern-industry/

<comment><USER2> There's even evidence of batteries in the archaic world:

[https://riversfromeden.wordpress.com/2011/08/18/electricity-...](https://riversfromeden.wordpress.com/2011/08/18/electricity- in-the-ancient-world/)

I understand some archaeologists, unwilling to accept the existence of such items, refer to them as OTTOs, or Out Of Time Objects. Personally, I wonder if the grandiose book burnings by the early Christian church might have also focused on things such as this, limiting their survival into the modern era.</comment>


YC Software Startups: Value and Initial Programming Language Used - <AUTHOR> https://charliereese.ca/article/top-50-y-combinator-tech-startups <comment><USER4> Fascinating to see how heavily Ruby and Python feature. The things that surprised me by their absence and near absence were languages I love: JS and C#

That said, this is taking now well established startups that will have begun their lives 5+ years ago in general. If I was picking a back end stack then I'd probably hesitate before picking the .NET Framework. But these days I'd easily pick .NET Core.

Likewise, I'd want a statically typed back end and 5 years ago I'd probably have hesitated before using TypeScript and node together. Now I do it regularly.

Would be super interesting to see the same chart in 5 years with companies starting now.

<comment><USER5> I use Python by choice and the more there is growing need for Natural Language Processing, Machine Learning, Data Mining, the more I can not leave Python.

I try Rust, Ruby and others on the side. But Python is just so heavily fortified now that I constantly suggest startups who are going to build non- trivial tech to select Python. Also the whole Linux, deployment, etc. space is filled with Python.

Biology, Physics, Math folks also use more Python than any other language.

<comment><USER6> what about R?

or Scala if you need bigger scale?

<comment><USER7> Yes let me just spin up my R web server.

<comment><USER8> Your web server isn't written in Python either, though.

</comment></comment></comment></comment></comment><comment><USER9> The page doesn't list the year the startups were founded. I wonder if you'd see a good correlation to the founding year.

More startups on the list use Ruby than any other language, and it accounts for over fifty percent of the valuation. It was very popular with startups ten, twelve years ago, but may since have slipped?

On the other hand among younger companions es one might expect to see more Go, Node and maybe Rust?

Still, an interesting analysis.

<comment><USER10> If you're talking about survivorship bias, I can well believe it.

Ruby is still popular with startups, and there's no falloff in Rails usage, if the gem download graph is anything to go by.

<comment><USER11> Rails download graph: [https://www.ruby- toolbox.com/projects/rails](https://www.ruby-toolbox.com/projects/rails)

<comment> purple-again This is excellent, thanks for sharing. Anyone know if something similar exists for JS frameworks (React,Ember,Angular,Backbone, etc)? Would be great to see their popularity over time.

I'm guessing maybe not having a single central repository like Gems will prevent this data from being so easily accessible.

</comment></comment></comment></comment><comment><USER12> This serves as an interesting counterpoint to Paul Graham's Beating the Averages[0] essay (which argues for using a powerful programming language as a secret weapon to allow a startup to outperform its competitors).

Reading this list, I'm struck by just how _mainstream_ the languages are. I don't have anything against Python or Ruby, but it'd be hard to describe either as a secret weapon — indeed, about the only "secret weapon" languages on that list are Lisp and Elixir, each of which shows up only once.

[0]: [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

<comment><USER13> He wrote that essay nearly 2 decades ago. It was a different world. At the time, the only language with a truly comprehensive open source ecosystem was perl, so, if you were going to work on anything else, there was a decent chance you'd end up writing almost everything yourself. That puts you in a spot where your secret weapon is the language itself.

Nowadays, I'd argue that the secret weapon is never the language itself. Ruby's popularity was never about Ruby itself, it was about Rails. Python is, IMO, an ugly hack of a language, but it's still the one I'm always pushing for at work, because its unbelievably lush open source ecosystem means that choosing Python means you'll end up having to do a lot fewer things yourself. Java's was originally about cross-platform deployment, but, now that it's been a decade or so since anyone was actually _that_ worried about interpreted languages, I'd guess it's now more the fact that Java developers are cheap and easy to hire.

I'm also honestly not super impressed by Graham's comments on programming languages. Sure, Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten. Graham has done a good job of pitching the idea that this is because people can't understand the obvious genius of Lisp, and I'll admit, as a Lisper, that that story once beguiled me. But, now that I've been around the block a few times, I realize that code that can only be maintained by its own author is never good code, and that sale price is rarely a good proxy for quality ( _especially_ when the purchaser is Yahoo!), and that sheer dumb luck plays a much larger part in entrepeneurs' success than any business essayist cares to admit, least of all the ones writing autobiographical essays.

<comment><USER14> _> Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten_

I think that's because the code after the sale had to meet different requirements than the code before the sale.

Before the sale, the chief requirement, at least from what I gather from pg's essays, was fast implementation of new features. That was the secret weapon, and Lisp was a key enabler for it. The number of people touching the code was very small, so having the code be understandable by others was not a high priority.

After the sale, the chief requirement, I suspect, was maintainability while running at scale. The before-the-sale period had already sufficiently explored the feature space that fast implementation of new features was no longer a requirement, so the advantages of Lisp were no longer crucial. But having code that lots of people could understand and modify reliably _was_ crucial.

So the code had to be rewritten after the sale. That doesn't mean the code before the sale was bad, just that it was tailored to different requirements.

<comment><USER13> That's one way of looking at it. I tend to prefer the mountaineer's ethos when thinking about goals for grinding out a new application: Getting to the top doesn't count if you can't get safely back down again.

<comment><USER15> It's a bit different with pre-sale/aquisition than mountaineering, with enough money and therefore ability to hire talent it's not impossible to refactor/split the project or even rewrite as needed once the business value is established. Reddit did it, going from lisp to Python, as did Twitter with microservices, Facebook rewriting a PHP VM, etc.

Startups in your analogy are more akin to: "get to the mountain top and succeed and have the cash to hire a helicopter out of there, or you die (the company)".

</comment></comment></comment></comment></comment><comment><USER16> Archive link: [https://web.archive.org/web/20200826060913/https://charliere...](https://web.archive.org/web/20200826060913/https://charliereese.ca/article/top-50-y-combinator- tech-startups)

Looks like HN brought it down.

<comment><USER17> Clearly they should have used a higher performance programming language. :-)

<comment><USER18> Nah, getting their MVP up quickly let them validate. Now they know it's worth the effort to scale ;)

</comment></comment></comment><comment><USER19> Just depends entirely on what you are doing. If you are ecommerce you can basically stick to really slow languages forever as the request volume is so small it should be a small fraction of your application. For consumer scale you end up scaling with caching and eventually migrate or severely optimize - like writing your own language runtime like FB. None of this accounts for all the analytics they are doing which is mostly written in Java and C++.

<comment><USER20> Even outside of e-commerce -- I would say anything on the web.

Run something like Ruby/Python for the majority of your web services, and deploy Elixir/Go/Kotlin/C++/Swift whenever you hit a data-munching need that Ruby/Python can't handle.

This doesn't fly if you're doing games, or augmented reality (AR), or mobile apps, or embedded stuff... but the web is still a pretty big place to build.

</comment></comment><comment><USER21> Seems like age is a factor: ruby had its day and companies of that vintage have been around long enough for some of them to be worth bucks. Python is more perennial (over the lifetime of YC itself).

<comment><USER16> In my annecdotal experience (could be completely wrong) Python and Django are much more common for the same vintage of startups in Europe as when Ruby and Rails were popular in the USA, I don't exactly know what drove it's adoption here.

<comment><USER22> Maybe related: One of Django's creators, Simon Willison is British. I think he worked at Guardian.

He's on HN too.

<comment><USER23> The creator of Ruby on Rails is Danish[0].

[0]: [https://en.m.wikipedia.org/wiki/David_Heinemeier_Hansson](https://en.m.wikipedia.org/wiki/David_Heinemeier_Hansson)

<comment><USER22> I know. And DHH worked on Basecamp and they are US based.

</comment></comment></comment></comment></comment><comment><USER24> Even though it says "initial back-end language(s)" it looks like the information is often pulled from the startup's current career pages. Mixpanel is listed as using Go as one of their initial back-end languages, even though Mixpanel was founded in June 2009, several months before the first version of Go was released.

<comment><AUTHOR> Thank you for pointing this out! Fixed and updated the article.

</comment></comment><comment><USER25> This is a really good time to remember correlation does not equal causation. :)

</comment><comment><USER13> I'm curious what's going on with the languages that seem to harm a company's value. Adding PHP or Java to your stack appears, from these data, to be a poison pill for company valuation.

It could just be a statistical fluke, given this sample size and all the selection effects at play, but I still have to wonder.

</comment><comment><USER26> The only thing that stands out for me, not a single one of these startups use Microsoft tech, even though DOT NET apparently is quite good to work with, from what I hear.

<comment><USER20> I think that this article[1] is still relevant. In short, if you go Microsoft, you know you're locking yourself into an _expensive_ ecosystem, one with no viable open-source escape hatch.

Moreover, you need to find developers that want to work on the .NET platform. Most of those people work in banking or in large organizations, and are unlikely to want to jump ship to a startup.

[1] [https://blog.jonathanoliver.com/why-i-left-dot- net/](https://blog.jonathanoliver.com/why-i-left-dot-net/)

<comment><USER27> An article from 2014? You should know things have changed since then, with .NET Core and the open-sourcing of most .NET tech (Roselyn, OmniSharp and the .NET Core tooling).

No more lock-in with Windows Server, no more SQL Server. Bring your favourite Linux distro and open-source RDBMS.

I left .NET for Ruby in 2013, and in the last two years, I've come sprinting back to .NET Core. Microsoft is definitely hot again.

<comment><USER20> Microsoft Research certainly does a lot of interesting stuff, but I think the bigger point is inertia -- Microsoft doesn't have any in the startup space.

Ruby, and to a large extent Python, started from zero, and gained a ton of traction during the whole Web 2.0 rumble.

Microsoft is starting from a negative perception amongst a lot of engineers, and unless they can provide some sort of killer reason to use .NET technologies -- one that doesn't lock you into their ecosystem -- then I don't see them unseating the established players.

Swift and its descendants will be around as long as Apple is, same story for Java and Android. Ruby/Python/Node will continue on in the Web space, with Go/Rust/C++ duking it out for backend services.

This game changes should Microsoft blow a new market open, though, like Apple and Google did with smartphones.

<comment><USER27> > Microsoft is starting from a negative perception amongst a lot of engineers, > and unless they can provide some sort of killer reason to use .NET > technologies

Yeah, as stated above, I _used_ to build on .NET back when WinForms was king. ASP MVC wasn't fun to write, Rails was a blast.

If you haven't got C# experience, I can understand the apprehension.

History repeats itself and almost definitely MS will get it wrong again for .NET, but right now, the money is good and the tech is interesting if you're into web tech and C#.

<comment><USER28> > Winforms was king. MVC wasn't fun to write with

Having worked with both, I have exactly opposite feelings about the two platforms. Except speed of development, I have absolutely nothing positive to say about Webforms.

<comment><USER27> Ah no! While a standard thing to do for the web, WinForms let you do the strangest stuff like mimicking OS X for a piece of Windows-only software.

My excuse is I was seventeen at the time... Back then, I was afraid of both hard graft and human interface guidelines.

[https://mattryder.files.wordpress.com/2010/04/capture.png](https://mattryder.files.wordpress.com/2010/04/capture.png)

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> There's a correlation but I don't think it's the one drawn from the article (programming language). I think that you have to consider the background of the person who would typically opt for these languages to start a new business/project. This might inform you of their thinking and perhaps a language like Java, where the developer is likely an Enterprise developer, leads to more brittle thought and execution. "Move fast and break" vs "thoughtful OOP and architecture" \-- It's possible to do that in both languages but you'd rarely encounter a "move fast" Java developer while you'd probably quickly encounter "move fast" Ruby developers.

That's perhaps down to experience having the effect of hardening oneself. You've made the mistakes, you don't want to make them again, so you create solutions that are more robust and by definition "better code" and "better designed". Unfortunately, this can cause you take longer to get to market and if you do have to pivot, can be a harder effort pivoting off of a larger, purpose-built codebase.

</comment><comment><USER30> Reddit was Lisp for a rather short time before being rewritten in Python. Isn't the story that HN was written in Arc as a response to Reddit's Python rewrite?

<comment><USER25> HN was written in Arc because Paul liked Lisp and made Arc and wanted a real project to try it. It really had nothing to do with reddit's switch to Python (which as you correctly point out was in it's second year).

HN was more a response to PG wanting more moderation control over the content.

</comment></comment><comment><USER31> I bet there's at least one company on this list who says they use a flash programming language because they're too embarrassed to tell the world they're running autohotkey scripts over an excel spreadsheet.

<comment><USER32> no way, is that actually possible?

<comment><USER31> Excel is extremely well optimized and can easily handle GB size CSVs

<comment><USER33> At a company I used to work for there were tales of an early admin guy handling all of payroll, employee directory, and tonnes of admin task data for multiple hundreds of employees in Excel. Guy was an Excel god.

It worked perfectly fine until it was move into a proper database with in house built portals to handle the tasks.

<comment><USER34> We used to have a prophecy that when the IT apocalypse hits, we'll be pushing our shopping carts around like in Cormac McCarthy's The Road; moving from company to company to fix the VLookups in their Excel spreadmarts

</comment></comment></comment></comment></comment><comment><USER35> Ruby certainly seems to have advantage in terms of spinning up a basic working product, which matters more than developing a well engineered solution.

<comment><USER20> Why does using Ruby or Python preclude having a well-engineered solution?

<comment><USER10> Well, that's the best part; in a very wide gamut of cases, they don't, and since both play nice with compiled languages a scaling up can benefit from both worlds.

<comment><USER20> I would argue that "engineering" and "scale" are different concerns.

Engineering is about building and maintaining things fit for their purpose.

A bridge that only needs to last for one year is designed very differently than a bridge intended to be used for twenty years.

In the case of software, that means (a) building what your users and business need; (b) designing software that is easy to change; and (c) delivering enough scale to meet your expected needs for the current business cycle.

For a new startup, you can probably get by with a Rails app on a single Digital Ocean droplet, with plans to scale horizontally. For an established business, you might have a large data warehousing operation running custom C++ code across multiple datacenters, of which the web frontend is a tiny (but important) part.

Good software engineering makes the steps between "New Startup" and "Established Business" as painless as possible, with a minimum of additional overhead.

<comment><USER36> > A bridge that only needs to last for one year is designed very differently > than a bridge intended to be used for twenty years.

Yes, but in software, the usual case ends up that the 1 year bridge actually has to become an interstellar spaceship and has to last basically forever.

This happens in other disciplines as well but I have not seen it as extreme as many software projects I saw.

</comment></comment></comment></comment></comment><comment><USER37> Start up year likely correlates. But also it would be nice to know how many startups failed and what languages they used?

Did using Node.JS or Typescript correlate with business failure or is it just more recent?

I'm also particularly interested if trying to use Kubernetes correlates with failure. Kubernetes, for all its good, is a rats nest of complexity.

</comment><comment><USER38> So the use of C# dooms my startup? I feel really out of touch having never used python or ruby.

<comment><USER39> I don't think language has got anything to do with it. It's more about the instincts. I'm purely talking in terms of probabilities but the odds of a C# programmer coming with an enterprise background are high. As such they bring certain instincts with them which are very useful in enterprise but not useful at all in startups. At worst, those instincts might do more damage than good.

So it's more of background/instincts things than language. C# technically has nothing which makes it a bad choice for startups.

</comment></comment><comment><USER40> Some of these are wrong: Rappi used PHP exclusively for it's first year, for instance

<comment><AUTHOR> If you can send me a source for that (on Twitter @charlieinthe6), I'm happy to make that change!

<comment><USER41> Can we also submit it via HN? If so, my understanding is that Pagerduty is running and long-term invested in Elixir ([https://www.pagerduty.com/blog/elixir-at- pagerduty/](https://www.pagerduty.com/blog/elixir-at-pagerduty/)) and Podium has migrated from Ruby to Elixir as the main stack ([https://medium.com/podium-engineering/two-years-of-elixir- at...](https://medium.com/podium-engineering/two-years-of-elixir-at-podium- thoughts-9f30defedb7d)). Thanks!

Edit: oops, I see now it is the _initial_ language. Indeed PagerDuty started using Elixir only later on. Although one could argue Elixir was part of Podium in its initial growth.

<comment><AUTHOR> Exactly - trying to capture what language they started with.

It was by no means a perfect science - was a lot of digging around on the internet for the oldest reference I could find!

</comment></comment></comment></comment><comment><USER42> This is a lagging indicator. If you did this in 2010, the top companies would all be PHP.

<comment><USER43> The biggest example of this I can think of is Facebook

</comment></comment><comment><USER44> I'd be more interested in _failed_ startups vs programming language.

<comment><USER45> Exactly.

Successful startups are analogous to surprising research results in academia, in the sense that we have much more information on them and therefore we can draw better conclusions about these entrepreneurial/academic successes.

Today, every good scientist is aware that having plentiful information on unsurprising research is almost as equally important, for many obvious and non-obvious reasons. This has resulted in journals created exclusively for publishing unsurprising research. [1]

If the most rigorous among us w/r to taking care of our collective body of knowledge are only starting to do it seriously, we can have hope that the industry might ramp up its capacities in this regard at some point - <USER2> wouldn't hold my breath that's it's going to happen soon though.

[1]: [https://news.ycombinator.com/item?id=24229269](https://news.ycombinator.com/item?id=24229269)

</comment></comment><comment><USER46> I know a little about Coinbase. The CEO did the initial MVC with ruby on rails. He was somewhat technical so it was a natural choice.

Then they moved forward with ruby for the whole platform, maybe as that's what he understood and what was the alternative back in the day.

However for any of these businesses the language of choice if starting today for me would be rust.

I really feel you get a much more maintainable codebase than a ruby project,

<comment><USER47> Rust is a great language, but how do you scale a Rust team? It's a hard language to learn without a ton of developers out there. I suppose you could hire C/C++ devs, but if you're just making a fairly standard SAAS Web app, it might be hard to pull those people over. Rust feels like overkill for your typical Web service to me.

<comment><USER46> There's a tradeoff, a high inital cognitive load for people learning the language vs the long term pay off of less bugs in production.

There are plenty of people who have spent time learning rust but haven't had a chance to use it on a production project. I would start looking there.

<comment><USER48> > vs the long term pay off of less bugs in production.

It has not been proved large, long-lived Rust projects have fewer bugs than large, long-lived Python/Ruby projects.

</comment></comment></comment></comment><comment><USER49> i've always wondered why the Whatsapp acquisition didn't spawn a bunch of startups using Elixir, since a lot of noise was made about how Elixir helped Whatsapp scale with so few people. isnt that how tech cargo culting starts?

<comment><USER50> WhatsApp used Erlang, not Elixir. There was an uptick in popularity (at least here on HN) after the acquisition. Elixir wasn't as popular in 2014 as it is today, but it was starting to grow.

</comment></comment><comment><USER51> Interesting that all of them which have "Y" for category "LowLv" incorporated one or more of c++, go, or rust[0]. Many which have "Y" for "DataSci" similarly use strongly typed/compiled languages (including Java). However, for general ecommerce / service-oriented offerings, there can be no dispute, given this list, whether ruby or python by themselves are up to the task.

[0] Dropbox is listed as python only, but it is well known (and documented) they have re-written key elements of their back end in rust. [https://dropbox.tech/infrastructure/rewriting-the-heart- of-o...](https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync- engine)

</comment><comment><USER52> The title seems to insinuate there's a correlation between a startup's value and dev language. While I think our "inner geek" all likes to think so - <USER3> that really the case?

<comment><USER53> There is no correlation. Success is 100% business connections. Even if the CTO was terrible, it wouldn't matter because the most talented devs would be applying to work for this hot new startup and would be able to work around all of the CTO's silly constraints. I have seen this over and over in my career.

The CTO imposes pointless arbitrary rules, tools and languages and then talented developers figure out a way to deliver value within those arbitrary constraints. Developers will use whatever language their boss tells them, then later when the project succeeds, they will praise that language, those tools and their bosses.

People will always praise the leaders of a successful company, no matter how incompetent they are.

People who succeed always think that it was because of good decision making across the board. They don't admit to themselves that the only decisions that actually matter are who the CEO is and who their friends are. Our system is crony-capitalism, no doubt about it. Nothing to do with value creation; the evidence is everywhere.

Any good developer who analyzes cryptocurrency projects, for example, will realize that there is no correlation between quality (or scalability) of the technology and ranking/market cap of the project. The top, most valuable project is Bitcoin and consumes the same amount of electricity as the nation of Ireland to process a measly 4 transactions per second. Anyone who thinks that Bitcoin is the most valuable project due to technical merit is an idiot. It's 100% network effects.

I can say from experience across different tech industries that the current market selection process works the same way across the entire tech sector, not just cryptocurrency.

Every time a project succeeds, the people who built it will try to claim credit for that success. The people who are actually responsible for that success (through their personal connections) will happily let the technical people claim the credit because it diverts attention away from the much more cynical and unjust reality.

Any attempt to insinuate that success has anything to do with choice of tech is either misguided or deeply corrupt as the dogma harms real people (who will be forced to use tools they don't like) and causes real loss in productivity.

<comment><USER54> No correlation is a bold claim. It seems obvious that a web based startup built using Rails is far more likely to succeed than one using bash scripts, if all else is roughly equal.

</comment></comment></comment><comment><USER55> Is there a list of what they have changed their programming language to? Like... Reddit indeed used to have their initial implementation in Lisp, but it is now Python.

</comment><comment><USER56> The fact that JS barely makes the list indicates to me that YC companies tend to have entirely separate frontend and backend codebases. That either indicates separate teams of frontend and backend developers, which I think is unlikely in a young company, or that there's an expectation that developers in early YC companies are expected to use (at least) two languages. Something to think about if you're starting out as a dev and thinking of looking for a role in a YC startup.

<comment><USER57> Two devs, each frontend and backend will work out pretty well even in a super- small startup I guess?

<comment><USER58> Depends entirely on the dynamic of the two people since backend and frontend has to work well together. When you're in a early startup, you want everyone to be on the same page, so you want people to collaborate closely. If they are people who like to work in silos without talking with each other, you'll have bunch of impedance mismatches at that stage. So you'll want a close team early on and if you can find someone who is good with both frontend and backend and could build it as one person, that'll be better for the early stages. Or two people who can collaborate closely.

</comment></comment></comment><comment><USER59> This would be more interesting if YC didn't have a strong inherent bias toward these particular languages. In other words: these are the results because this is what YC picks and filters for, not because of any inherent meaningfulness about choosing these languages, or qualities of the languages.

<comment><USER60> It's true that investors filter for easy to see signals, so therefore it is also likely true that 130 IQ startups get funded but 140 IQ startups are not recognized (or even outright ostracized), but this is the same for customers, executives, and humans generally. So it's not clear that this could be any other way. In this way humanity is a tragedy. Look around. Everything is mush.</comment></comment>