Startup lessons - <AUTHOR> http://www.defmacro.org/2013/07/23/startup-lessons.html <comment><USER2> Wow is this list good. It has the kind of resonance you only get when you're writing from a lot of hard experience.

As I just wrote when I sent this link to the current YC batch, if you see advice here that puzzles you, it may be a sign of a painful lesson you're going to learn in the future.

<comment><USER3> > if you see advice here that puzzles you, it may be a sign of a painful > lesson you're going to learn in the future.

Ugh, does anybody mind taking a stab at paraphrasing this one:

> Don't say things if your competitors can't say the opposite. For example, > your competitors can't say their product is slow, so saying yours is fast is > sloppy marketing. On the other hand, your competitors can say their software > is for Python programmers, so saying yours is for Ruby programmers is good > marketing. Apple can get away with breaking this rule, you can't.

This is the only bullet out of the list that I can't quite brain.

<comment><USER4> Hard won marketing lesson: being different is way better than being better.

Scott McNealy polarized this further -- he would say, I want half the potential customers to hate my products but half to love them.

<comment><USER3> Ahhh, that reminds me of the wonderful success that was OS/2\. Makes perfect sense now, thanks.

<comment><USER4> Yep. Scott's nightmare was that everyone would think his products were fine.

</comment></comment></comment></comment></comment><comment><USER5> Lesson #58: Don't always believe your own BS.

There is some good stuff in here, but it's not all right all of the time. The part about firing people is interesting. Maybe there is friction because the manager/CEO is doing something wrong and the employee is merely agitating to make things better for the business? The ability to self-evaluate and take criticism/recognize the difference between "difficult" employees and employees who are trying to fix things you are doing wrong seems important and missing from the "people" section.

<comment><USER4> That's what pain in the ass employees who get fired for being pains in the ass always think on their way out the door.

<comment><USER6> And Marc that's also what really good employees who leave because they're not listened to always think on their way out the door.

<comment><USER7> Everyone who isn't listened to is, in their own mind, really good ;)

<comment><USER6> Jeff Immelt, CEO of GE said this recently:

 _Every idea begins with a constituency of one. There's probably one or two times a year that I turn to our very top leaders and say, "we're going to do it my way." Do that too often and good people will leave. But if you never do it, nothing ever happens._

</comment></comment></comment></comment></comment><comment><USER8> _If you can't get to ramen profitability with a team of 2 – 4 within six months to a year, something's wrong._

That probably makes perfect sense for some random SaaS app or consumer facing app, but for an enterprise startup, I'll argue that it's off the mark. Just doing market research, a few rounds of customer development interviews, and building the product out to prototype phase could burn up the better part of a year, and enterprise sales cycles are often slloooooowwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.........

 _Pick the initial team very carefully. Everyone should be pleasant to work with, have at least one skill relevant to the business they're spectacular at, be extremely effective and pragmatic. Everyone should have product sense and a shared vision for the product and the company._

That's one of those things that is on every one of these lists, and for good reason. But, by the same token, you could spend the rest of your life looking for the "perfect" co-founding team, never build a god-damned thing, and die peacefully in your sleep, of old age, at 97. By the same token that "good is the enemy of great", one has to realize that "perfect is the enemy of good enough".

That said, I worked alone for quite some time before inviting anyone else to join up, because this does matter. But you can't wait indefinitely... in the real world, the environment around you is changing, and windows (of opportunity) come and go. You could easily miss one trying too hard to find the ideal co-founder(s).

<comment><USER9> imho being solo-founder > having a bad co-founder any day. Agree you can't wait indefinitely, but if you're onto something and you can't find someone great to help you grow it, the problem might be elsewhere. (Bad product/market, Hard personalty, etc)

<comment><USER8> I think there's some room between "bad" and "great", though. My point isn't to accept a "bad" co-founder, but rather to not let the quest for a "great" co- founder keep you from going with a "pretty good" co-founder for so long that you miss the opportunity anyway.

That said, this is all pretty subjective and hard to measure anyway. I mean, do you _really_ know that a "great" co-founder _is_ "great" from day one? Or that someone you think is just "good enough" actually is "great"? Of course, that fuzziness is part of why I say "just pick somebody and get started already" to some extent.

<comment><USER9> Fair enough. That's why sometimes the best cofounders are old colleagues at university or company (or hackatons!). They've already worked together and know they can get shit done quickly.

<comment><USER8> _That 's why sometimes the best cofounders are old colleagues at university or company (or hackatons!). They've already worked together and know they can get shit done quickly._

Good point. I know I went that route, recruiting a co-founder from among the group of people I had worked with at Lulu.com.

</comment></comment></comment></comment></comment><comment><USER10> A bit of self-contradiction here:

* Product sense is everything

* Product comes first

* Sales fix everything

* Development speed is everything

* Do everything you can not to attach your self esteem to your startup

I'm reminded of a former CEO who, after careful analysis of a failing business, decided there were nine critical areas of focus for the company. (She was eventually fired.)

<comment><USER11> This type of post often uses the Goldilocks fallacy to appear like it offers advice when it's actually restating the actual problem: the way to achieve Y is with just the right amount of X.

"A successful startup is easy: simply build the right product in the right market with the right team, and don't forget to build it at the right speed!"

<comment><USER12> I've never heard of that term, good explanation.

</comment></comment></comment><comment><USER13> A lot of these resonate with me... to the extent that I already believe them. It's tough to absorb these sorts of generalities though, which is why startups make the same mistakes over and over again... not because they haven't heard the advice, but because it's hard to apply. I'd love to see, over the next 57 weeks, the author take one of these per week and tell a real story about how he learned it. An example: "Your authority as CEO is earned... don't try to use authority you didn't earn." When did you learn this? You certainly didn't think before "I should use authority that I haven't earned." So how did it stand in your head before, and what experience made you rethink it? Overall, I love stories that give me more concretes to absorb into my understanding of cause and effect, and details that I can use to bolster my understanding of the pithy advice. Thanks for sharing your hard-won experience, and I look forward to more posts in the future.

</comment><comment><USER14> > _Split the stock between the founding team evenly._

I've heard the exact opposite from VC's -- fact is, the engineer or product founder might be bringing _way_ more value to the table than the business guy. Or sometimes it's vice-versa.

And that "unfairness" in an initial even stock split will come back to haunt the company, since certain founders are not being rewarded justly for their contributions, and will come to resent it later. And that VC investment can be contingent on founders adjusting their ownership stakes beforehand to match the reality of what each founder is actually bringing to the table.

<comment><USER9> That's why you want to split the stock evenly with co-founders you know will put as much effort/time into it. Starting a business with not-evenly stock is akin to saying "I'm better than you" which is, arguably over-simplified, but not a meaningful way to start a long adventure with someone.

Obviously, if someone is ready to join part-time or come more as an early employee with more salary, then the variable changes. I'm talking here about the "I start with 60, you get 40 because I've got the idea first and I've been working on it for 2 weeks". That's a recipe for trouble.

<comment><USER15> What about "I've tested the market with a prototype over the last year that has generated revenue (not much but some) and now I'm recruiting a cofounder?" Still 50/50? Or should the earlier founder be compensated for earlier work with future work being earned evenly b/w the two cofounders on a vesting schedule?

<comment><USER16> You might find Mark Suster's opinions helpful. The podcast of his Stanford talk(s?) are also pretty good.

[http://www.bothsidesofthetable.com/2011/05/09/the-co- founder...](http://www.bothsidesofthetable.com/2011/05/09/the-co-founder- mythology/)

<comment><USER4> Mark's advice on these topics is some of the best ever.

<comment><USER17> Marc, you and Mark seem to disagree on at least one thing:

You:

 _if you 're considering a cofounder who you don't want to give equal stock to, do you really have the right cofounder?_

Mark:

 _I meet far more second or third time entrepreneurs who wouldn't do a 50 /50 (or 33/33/33) partnership ever again than you would image.

I am one of them._

Based on my experience, I'd recommend finding a co-founder you _want_ to split equity evenly with before you start up as you recommend.

</comment></comment></comment></comment></comment></comment><comment><USER18> There is good advise in this list. But I also know counter-examples from "successful" startups for many of the points.

Given that, I'll propose a 58th: be formidable enough to overcome any of the other 57.

</comment><comment><USER19> "11\. If you have to give away more than 15% of the company at any given fundraising round, your company didn't germinate correctly. It's salvageable but not ideal."

I thought the rule of thumb was a lot higher than this. Any good references this one?

<comment><USER20> This article says the industry norm is 20-25% at the early rounds, which has been my experience as well.

[http://techli.com/2012/02/the-founder-dilemma-risk-equity- di...](http://techli.com/2012/02/the-founder-dilemma-risk-equity-dilution- term-sheets/)

</comment></comment><comment><USER21> > #25 Don't build something that already exists. Customers won't buy it just > because it's yours.

Not a good rule. I know many guys that are making serious money because they improved something that already existed.

<comment><USER22> Opposite view: building something that already exists is the easiest way to know that there is a market. Then try to steal the market from other players with a better product.

</comment></comment><comment><USER23> I disagree with PG entirely. These lists are thoughtful, but they are 100% subjective. The only rule with startups is there are no rules. There is a time and a place for EVERYTHING. There is no "always," and there is no "never."

I have a funded startup. I can list 5 counter-rules for every rule he lists. For example: "Don't build something that already exists. Customers won't buy it just because it's yours." Living Social, anyone?

The phrase, "There is more than one way to skin a cat" comes to mind.

</comment><comment><USER24> Good list. From my point of view, it's also a good source of questions for an employee to ask the founders when interviewing at a startup .

I don't get this, though:

> _Watch Jiro Dreams of Sushi, then do marketing that way. Pick a small set of > tasks, do them consistently, and get better every day._

How is that marketing? That's getting good at your craft and improving your product.

I watched the movie, but I'm not sure that Jiro is good at marketing. Apparently he's very good at making sushi, but it seems he became successful (and later world famous) despite being bad at marketing.

Incidentally, his shop's average ratings at Tabelog (one of the biggest Japanese gourmet websites) is only 3.8 out of 5, with quite a few "bad" reviews.

</comment><comment><USER25> Read anything by Felix Dennis, and you'll be able to see the meta: it's a mind game and quite fun when you can step back a bit. Also, he's comes off as wickeder than Ben Franklin if that were possible.

</comment><comment><USER26> > 2\. Split the stock between the founding team evenly.

I can tell that you have all honest intent for writing this, but from experienced accounts I have read (a lot from PG and this forum). Many startup veterans strongly advise against this.

> 33\. Watch Jiro Dreams of Sushi, then do marketing that way. Pick a small > set of tasks, do them consistently, and get better every day.

I've seen this and I love it. I love how you tied it in to startups too. That man is an inspirational model of a life long determination to be the best at what you can be.

</comment><comment><USER27> _30\. Learn the difference between people who might buy your product and people who are just commenting. Pay obsessive attention to the former. Ignore the latter._

How do you do the first part?

<comment><USER4> That's a great question and a really important topic.

You use a sales technique called "qualifying", and when you figure it out, you do it all the time, and not just with potential customers, but also with potential investors, candidates, and even reporters.

(This is part of the art of sales that many founders today refuse to learn.)

To qualify a prospect (potential customer), at the end of every interaction, you should determine from them what has to happen from here for them to pull the trigger. You do this by asking questions, and testing the answers -- have them lay out their process for making the decision, have them identify the steps that have been reached and the steps that have not, have them identify other people in their organization who can block the purchase, and so on. And you do this over and over again until you get the sale.

If the prospect can't lay out the logical sequence of steps from here to close, then you need to qualify them out and stop spending time with them, because they're not going to buy.

Two interesting corollaries:

* Yes, there are a LOT of people in a LOT of companies (as well as a lot of potential investors, potential recruits, etc.) who will spend a lot of time with you even though they can't ultimately pull the trigger. A lot of people like to windowshop, and a lot of people have nothing better to do.

* Like a lot of sales techniques, this sounds to engineers like it might be hard (will the potential customer tolerate all those questions?) But any serious potential customer will have a very easy time answering the questions, and will respect their potential vendor for being professional in the sales process.

<comment><USER28> The hard part of qualifying is actually not that people will lack the time, but people feel guilty about financially profiling people superficially. Just check the recent Oprah scandal. It could be said that the sales girl was 'qualifying' Oprah's sale and directing her to buy the cheaper handbag, but turns out that she had misjudged the book by it's cover.

<comment><USER29> She may have been better off if she asked questions rather than jumping to conclusions. In other words, if she had read pmarca's excellent advice, she may have made the sale and earned a repeat customer.

<comment><USER4> Yes! You ask polite questions. "Have you been here before? What product do you use today? What are you looking for? That's a beautiful watch/scarf/sweater. Where are you visiting from? What do you do for fun?" It's not that hard.

</comment></comment></comment></comment></comment><comment><USER30> While I do agree with many of the things which are on this list, most of them have trade offs. They certainly are not as black-and-white as the author has stated it.

I really recommend reading The Founders Dilemmas. It covers many of these issues in detail. Here's a link: [http://hbr.org/2008/02/the-founders- dilemma/ar/1](http://hbr.org/2008/02/the-founders-dilemma/ar/1)

</comment><comment><USER31> This list is amazing. I will offer a counterpoint on the free side of freemium users. Have a plan to cultivate their love and action. Ranking in Google, the app store, etc is a part of your revenue path, so don't ignore your army of likers, linkers, etc. Just don't waste time _disproportionally_ in their favor when you have paying customers to service.

</comment><comment><USER32> I would add exercise daily, sleep well, eat a healthy diet, and get some sunlight to the list. You'll be happier.

</comment><comment><USER33> Marketing after product - totally disagree. Today marketing and product is one in the same, no way to tell when one begins and the other ends. Basically what he should have said is start with deeply understanding your target customer, that's the hard part and people always screw that first step up.

<comment><USER34> 100% agree.

Above all, understand who your customer is, what they need and how they value that need before you begin to think of your solution...

By all means, start with a hypothesis and "big idea," but conduct thorough qualitative research with your prospective target customer before you start building in any real sense (beyond simple prototypes).

As a marketing research consultant, I've worked with too many companies (large and small) who flail around to find target segments after not spending the appropriate time upfront understanding and qualifying their target audience.

Despite seeing so many companies fail at it, it's even tough advice for me to follow on my own personal projects because I love building things and just want to get started right away...

</comment></comment><comment><USER35> It's refreshing to see someone defending a point that, IMO, should have been obvious all along, instead of encouraging the "lifeless code-drone" style: "Every once in a while, get away (...) It will make you more effective and make the people around you happier."

Today, I'm releasing my product's 3rd alpha version for testers and then leaving for a small break. My main goal will be to read the two books that are waiting for me for a long time and, to the extent possible, NOT think about anything work related. I could do some productive work these 5 days, but in the long run it'll cripple my stamina when things get rough in a few months. So, it's time to restore balance.

</comment><comment><USER36> The problem with "rules" is that they live in an ideal world, not the real world. "Give up only 15% of your company" sure, if you are the next Google, but even then every raise they did wasn't perfect. Let's be honest there is an ideal way you would build a company, but it doesn't exist for anybody. Startups are hard and messy. You do the best you can, but you can't just know in advance you're picking the best idea, the best people and fundraising quickly. It's not like that at all.

</comment><comment><USER37> _Product sense is everything. Learn it as quickly as you can. Being good at engineering has nothing to do with being good at product management._

How do you know if you have it? How do you learn it or improve it?

</comment><comment><USER38> My experience has given me a simple litmus for whether a startup is going to fail or not:

Are they trying to build a small idea into a great company, or are they trying to build a giant idea into a giant company?

<comment><USER39> Which one of those two options do you feel is the one more likely to fail?

<comment><USER38> I hoped it was obvious:

There are huge advantages to having a small idea. There's a clear MVP, a clear short term goal to achieve. This has a big effect on morale: the developing team has a series of short development bursts ending with an achievement and the vision of the company in eyesight. The quality of the product tends to be higher sheerly out of being simpler.

A small idea can have very wide reach, and can be an essential need to users, or a new pillar of infrastructure. Often after building a small and strong product, a company has the freedom to apply and maximize it for the full range of possible use cases. The easy example is Google, but I like to use the StackExchange network. They started with a Q&A site for software engineers, and once that was successful they expanded to a huge range of fields.

Huge ideas often send startups down a path to failure. Morale gets drained over time as features get completed but the vision remains too far away. Complexity increases greatly, and the core product gravitates to unmanageability as it grows. Even a best in class engineering team can be toppled by the exponential complexity of a large product, there's a potter's field of large products being built by awesome engineers, in big companies and small.

I could go on and on for each side, but the main point is, having a company vision that is the MVP is amazingly powerful, and opposite, having a company vision that is massive even with an MVP that is a stepping stone on the way to the massive vision, is a swamp to trudge through for years.

</comment></comment></comment><comment><USER40> >Marketing >Product comes first

Marketing should always come first, in terms of what you do.

Don't build a product and see if anyone wants it. See if anyone wants your product and then build it.

<comment><USER8> Or you can do those two things at the same time. That's the essence of @sgblank's "Customer Development Process" \- it's mean to run _in parallel_ with the Product Development process, with periodic synchronization between the two.

</comment></comment><comment><USER41> Re: "Market to your users. Getting attention from people who won't buy your product is a waste of time and money."

That statement is misleading. It's not an "or" situation. You need to market to both your existing users and your prospects (users or customers). You can't just rely on viral and word of mouth for growth. Yup, good marketing is not easy- you need to figure out your segmentation and reach your prospects cleverly.

</comment><comment><USER42> > Split the stock between the founding team evenly.

I worked as the first employee at a now successful start up. They were 5 founders with each 20% of the shares. What I heard from them after several investment rounds is that investors _don 't_ like evenly split stock and prefer that _one_ of the founders has the most stock, even if that's just a single stock more than the other founders.

<comment><USER3> N/5 + 1 is just plurality.

"most" == majority == N/2 + 1

which is it, is it just that VCs want to see that there is a designated leader among the founders, or do they want the relative amounts of stock to not ever become an issue for the viability of the startup ?

mere plurality is risky, because any of the founders could sell their share to another, creating an ownership crisis where the nominal head of the company has a minority share.

<comment><USER42> Thanks for clarifying the semantics :)

</comment></comment></comment><comment><USER43> This list is so good, I should memorize it to the point when I can look at what I'm doing wrong and shout out one of your numbers! I've made many of these mistakes (#1 in particular).

Here are my top picks by number referring back to the article, for some of the sections (YMMV of course!):

PEOPLE: 1.

FUNDRAISING: 12.

MARKETS: 18.

PRODUCTS: 24 (and 27 which to me is a subset of 24)

MARKETING: 32, 31 (I wonder how RethinkDB or companies like it can do 32??)

SALES: 40

DEVELOPMENT: 45 (and 46 which is a subset of 45)

</comment><comment><USER44> > Working on the wrong thing for a month is equivalent to not showing up to > work for a month at all. I cannot agree to this statement. Even though some > venture turns out to be a flop, you did learn a lot while trying to conquer > it. And additionally, it's only trying out something to find out that it was > the wrong thing - also you learned this about your field of study.

</comment><comment><USER45> A list full of startup platitudes dressed up in pedantic rhetoric. Did you really learn this o'wise oracle, or did you just plagiarize a bunch of wisdom, rewrite it in your own voice, and claim it as your own? Elements of Style you are not because there is no great sense of consistency. And who the hell are you anyways?

</comment><comment><USER46> I don't know that you get to say that something is wrong if you can't get to Ramen-profitability in 6 to 12 months and then later say to follow the example of Google and build something that touches billions of people's lives. Adwords didn't show up for a long time.

</comment><comment><USER47> I liked the "Jiro Dreams of Sushi" bit. I saw it yesterday, after seeing a lot of recommendations on HN for it. Excellent movie for all of HN. Go watch it.

<comment><USER48> I haven't seen it yet, but will today. One other thing, which is that I associate the whole blogpost with the movie "Revolver". It is like Jason Statham, speeking the words; I guess it is the "former and latter" phrases. IMHO also a good movie, when it comes to be better. "You only get to be better, by playing a better opponnent."

</comment></comment><comment><USER49> Point #11 seems different than my understanding of most VC Series A rounds. It tends to be 20-40%, so almost always over 15%

</comment><comment><USER50> I feel as though this list overly generalizes. Don't just blindly follow these; many of them can be proven to be wrong.

<comment><USER4> I feel as though your comment overly generalizes. Don't just blindly follow it; it can be proven to be wrong.

</comment></comment><comment><USER22> I guess another valuable hidden lesson is that Slava is a lisp lover working in a C++ product.

</comment><comment><USER51> This is a wonderful list.

Is RethinkDB a YC company?

<comment><AUTHOR> We are.

</comment></comment><comment><USER52> Cashflow.

<comment><USER53> Yep, that's the first thing on the list, all right. Okay, my turn: split the stock between the founding team evenly.

<comment><USER24> No, it is not. The first item on the list is about profitability. Being profitable isn't the same thing as having positive cash flow:

[http://www.investopedia.com/articles/01/110701.asp](http://www.investopedia.com/articles/01/110701.asp)

</comment></comment></comment><comment><USER54> "ramen profitability" \- LOVE IT!

</comment><comment><USER55> > If it doesn't augment the human condition for a huge number of people in a > meaningful way, it's not worth doing.

this is the kind of arrogance i find disheartening about these kinds of lists. really - things aren't _worth doing_ unless they clear this impossibly ambitious bar?

should i tell the owner of the corner cafe i stop into after work every other day, and that gives me a huge amount of joy nearly every time, that she should give it up because her business doesn't "augment the human condition for a huge number of people"? how about the guy who wrote the $5 clipboard app that makes my life much easier? i'm sure he has lots of customers but "a huge number" that have "augmented" their humanity because of his clipboards....

and i hate to be an ass, but ... under whose criteria does rethinkdb qualify for this, anyway? how meta do we have to go here? how many degrees of separation are we talking about exactly?

the problem with these kinds of statements is they can be rationalized by smart people into all sorts of justifications for doing and/or not doing a huge number of things.

<comment><USER56> It's not an impossibly ambitious bar. Many people have cleared it in the past, and many more will clear it in the future (including Slava the OP).

<comment><USER57> "people have done it" doesn't mean that its a good lesson (or a lesson at all)

i think @beachstartup's point is that the problem with treating this as a "lesson" is that you're imposing a value judgment on other peoples' value creation by saying that what they're doing, possibly their LIFE'S WORK, is NOT WORTH DOING just because they may not "augment the human condition for a huge number of people in a meaningful way".

For example, any failed venture could probably be said "not to augment the human condition for a huge number of people in a meaningful way". Goodbye scientists who are trying to cure cancer but haven't succeeded yet. No offense, patio11, but bingo cards? Come on... try to augment the human condition a bit.

It just comes off as judgmental and moralistic bs.

<comment><USER56> I would guess people spend billions of hours a year staring at bingo cards. So having nice ones is not a small thing.

<comment><USER58> I believe his statement was that of mockery or sarcasm when using the "augment" line. Not actually demeaning some of patio11's work. :)

</comment></comment></comment></comment></comment><comment><USER59> This article's advice creates the same kind of terrible, derivative "feature" companies that simply exist to get acquired, rather than really breaking new ground.

There's gems in there, but lots of bad, bad advice.

</comment><comment><USER12> I take issue with a lot of these, but a bunch of other commenters have covered most of them.

This:

> _" Assume the market is efficient and valuable ideas will be discovered by > multiple teams nearly instantaneously."_

That's just irresponsible and unrealistic advice.

Splitting stock evenly and governing yourself as a "final say" CEO seems a bit self-contradictory, to say nothing of whether or not you _should_ be a "final say" CEO in a startup (debatable).

This is also deplorable:

> _" If it doesn't augment the human condition for a huge number of people in > a meaningful way, it's not worth doing."_

Yeah, it's wonderful to "augment the human condition...", but don't be a condescending prick about it. Things are _perfectly worth doing_ even if they don't impact a large number of people.

The trouble with this is, Slava inherently claims superiority to his audience when he declares (not suggest, _declares_ ) that things are not worth doing just because they aren't up to his self-defined standard of ambition.

Such a statement is not for him to make; it wouldn't sound right coming straight out of one of Paul Graham's essays, so on what authority does he get to make this statement?

<comment><USER60> I see nothing condescending there. "Augment the human condition" means making someone's life better. "Huge number of people" means going after big markets. "Not worth doing" means not worth doing _as a startup_ —it might be well worth doing in some other context, and that's clearly not the scope of this post.

<comment><USER12> Perhaps I worded that comment too harshly.

However, that's a distinction you're making, gruesom. The OP doesn't say it's not worth doing as a startup, he says it's not worth doing in general. There's no qualifier. Had there been, I wouldn't take the same issue with it. This is something other commenters have pointed out down and upthread as well.

<comment><USER60> "He says it's not worth doing in general."

He did not. It's you who read that in and became indignant at it.

"There's no qualifier."

Certainly there is—the title of the post. Plus its whole context, which is obviously that of a classic Silicon Valley venture-funded startup.

Look at it this way. When people in this context say "You should go after a big market", do they mean that anyone going after a small market is an inferior person? Of course not. What they mean is that if you're going for a classic high-growth startup, you'll need a market big enough to support that. They're communicating a distilled lesson about startups, not the world in general. Same with Slava's post.

<comment><USER12> You know, I guess you're right. I was off base with this comment - I tried to be more neutral and less critical in my top level comment to pg. But yeah, I concede. I see your point.</comment></comment></comment></comment></comment>


Golang Brad Fitzpatrick being attacked on his support of Hong Kong - <AUTHOR> https://twitter.com/bradfitz/status/1181570516059951105 <comment><USER2> If the CCP can't use you, they attack you.</comment>


Reason why Linux is not main steam yet - <AUTHOR> https://irenicus09.wordpress.com/2013/11/03/reason-why-linux-is-not-main-stream-yet/

<comment><USER2> Consistency is totally killing GNU/Linux on the desktop for me. Ubuntu does a pretty good job at providing an usable desktop experience out of the box, and by that I mean decent UI, decent font rendering, decent defaults. However, it is not seldom that, for example, I have 4 windows open and each one of them has a different type of scrollbar. I know this is not important for many people, however, for myself this is totally killing it. I grab my Mac and I can focus on my work without being annoyed by the environment.

</comment><comment><USER3> In the OSS world, many people feel no need to finish things and make them usable for the end-user. (I am looking at you, bcache.) Honestly I'm wondering why. Does nobody have the missionary drive anymore to bring Linux to the people, and everybody wants to just hack something to make it work for themselves? When do OSS developers feel rewarded and highly regarded -- when things work for them and the other people on their IRC channel, or when people start picking up the features they just wrote and actually using them?

</comment><comment><USER4> Lack of system-wide spell check might be a contributing factor.</comment>


Network topology design at 27,000 km/hr - <AUTHOR> https://blog.apnic.net/2020/02/25/network-topology-design-at-27000-km-hr/ <comment><USER2> The first generations of Starlink satellites will serve as bent pipes. They're not doing intersatellite links. This will require dozens of small trunk-link earth stations around the USA, in the same general region for rural services.

For example an earth station near the fiber in Boise, ID would have visibility for bent-pipe type relay to the same satellites presently overhead of many very hard to reach, rural, remote Idaho locations. The remote parts of ID which are presently only serviced by small geostationary VSAT terminals (viasat/wildblue/hughesnet etc).

About a year and a half ago Elon Musk fired the part of the starlink team, based on Redmond WA who wanted to go directly to intersatellite links in the first generation, most of whom have now ended up at Kuiper.

[https://www.reuters.com/article/us-spacex-starlink- insight/m...](https://www.reuters.com/article/us-spacex-starlink-insight/musk- shakes-up-spacex-in-race-to-make-satellite-launch-window-sources- idUSKCN1N50FC)

This also means that in order to establish service in a particular area it will require putting in place starlink earth stations in the general region. Meaning that there might be full satellite coverage over the same latitudes in Canada, and Russia on the same calendar date, but Canada will receive live service much earlier.

<comment><USER3> That's really disappointing to learn. It was the inter-satellite linking part that make it really interesting (to me) and which promised to provide big latency improvements over fiber (over longer distances). I wonder if it proved too hard in practice?

<comment><USER4> Elon Musk has stated that until they have inter-satellite laser links deployed, they can get wide area low latency communications by relaying via ground stations at a high slant angle. I built a simulator and ran an analysis of this, and actually it works pretty well. My video analysing all this is here: [https://youtu.be/m05abdGSOxY](https://youtu.be/m05abdGSOxY)

<comment><USER2> There's a variety of software packages you can use to simulate the ground footprint of a starlink satellite, from the TLEs (two line elements). Or Iridium or anything else.

It's a circle many hundreds of km wide. Assuming that an earth station will have a minimum look angle of about 18 degrees above the horizon, one can calculate the serviceable area for customer and trunk link spot beams within the satellite's moving footprint.

The scenario shown in your youtube video has uses for HFT and similar very latency sensitive applications. But because it's RF, there's no way that a chain of starlink satellites relaying through multiple ground stations will compete in raw throughput and capacity with fiber. Remember that a single IT standard 100GHz grid DWDM channel is a few terahertz wide, and 80 channels can easily fit in the conventional bands of a long haul DWDM system in just two strands of fiber.

<comment><USER4> Yes, that's correct, but the interesting part is not the footprint, but the latency and variability of the dynamically routed paths you can obtain. That's what I simulated. I also made some modifications to how you'd normally route such a network, because the conventional approach wasn't fast enough if you have a wide choice of groundstations and the topology is continuously changing. The animations in the video are doing the route calculations in realtime once per frame of video; I was pretty pleased with those optimizations. One surprise, for me at least, was that there are paths where you sometimes want to relay via ground stations, even when the satellites have inter-satellite laser links. That's in the video towards the end.

Edit: in response to the point you added about bandwidth: that's correct - there's no way the ground relay path competes with fibre on bandwidth. There are, however, many potential uses that require low latency and are not high bandwidth.

</comment></comment></comment></comment></comment><comment><USER5> If you enjoyed this, _Eccentric Orbits: The Iridium Story_ by John Bloom is a good book on the similar topic from few decades back. Spiced with a healthy bunch of politics, entrepreneurship and action.

<comment><USER6> Have to second this comment. The Audible version of it had me riveted. A great story well-told, with a raft of good quotes, such as "People didn't like game changers in the 90s anymore than the owners of of the Erie Canal liked the transcontinental railroad. New technology always leaves a battlefield littered with bodies."

</comment></comment><comment><USER7> While general purpose satellite internet is nice, I'm wondering (in brainstorm mode) about whether there are alternative situations for which an architecture based on such fast moving satellites would be desirable rather than a challenge.

Below are some unfiltered thoughts on this -

1\. Treat satellites like postboxes. If ground to satellite link is fast, use it to upload TB of data to these satellites and let them transport it across oceans and dump them at destinations (article notes it takes 6mins to cross the Atlantic).

2\. Serve applications off satellites - sort of like CDN edge servers. Thinking Cloudflare Workers. No idea what their capacities are though.

3\. Distribute updates to devices or end points. Tesla updates?

4\. Make the satellites pick up and drop data between specific ground stations.

Any intelligent ways to abuse this system?

</comment><comment><USER8> Yoo, I met the author when I toured ETH Zurich for visit days. If you're reading this, super excited for you :D

</comment><comment><USER9> Are there any companies that are doing something similar in the bay area?

<comment><USER2> oneweb, kuiper, starlink, telesat, and SES (o3b) are all hiring. Not necessarily in the bay area.</comment></comment>


Garden Hermit - <AUTHOR> https://en.wikipedia.org/wiki/Garden_hermit <comment><USER2> This is the job I want. If you're absurdly wealthy and have an estate in the greater PHX area, would love to offer my services. I have my own druid robe.

</comment><comment><USER3> Sounds a bit like entrepreneur-in-residence.</comment>


From Rust to TypeScript - <AUTHOR> https://valand.dev/blog/post/from-rust-to-typescript <comment><USER2> The first code example he uses immediately threw me for a loop. Why is he adding the return value of a function call to a function itself? bar() + bar????

function bar(someNumber: number)

{

      return foo(someNumber) + 1;

}

function baz(someNumber: number) {

      return bar(someNumber) + bar;

}

baz();

Moreover, baz is called with its only argument being undefined-- so the exception throwing code won't even throw, because it isn't 0. And _moreover_, this is typescript, so this would have thrown a type error since a required numeric argument is omitted.

This has so many problems. This is not a promising start to this article's correctness or thought-outtedness. Yet here it is at the top of hacker news...

<comment><USER3> In JS it's the function would be converted to a string representation of its code and concatenated to the result of `bar(someNumber)`.

Some quick playing with ts-node says that the same thing should happen, depending on the return type of bar. Given the definitions above, it should throw a TypeError, but if bar returned a string, I think it would still behave as I said.

<comment><USER4> I was unsure if this comment was sarcasm so I tried and concatenating a function and a string in JS _actually_ results in the source of the function being concatenated with the string.

<comment><USER5> <rant> This whole "wow I thought implicit type coercion in JS was a joke" style comment got old 10 years ago. If you look at where JS came from (the 90s browser) and what it tried to do there then you should be left with few surprises looking it JS code snippets. If you don't understand what a language was designed for and how it evolved how can you be surprised at the results of code snippets? Because it's not the same as every other language? What would the point of the new language be then?</rant>

<comment><USER6> It's not that the language is different, it's that the default is stupid. It's much more likely that if I'm trying to concatenate a string and a function, I've mistyped something, not that I want the source code of the function.

You can always include some additional function which takes a function as an argument and prints the source code as a string for the 4 people in the world who rely on function to string coercion, why is it a default behavior with no visibility?

I get it, JS is different from C or C++ and every other language but we call out poor design decisions by comparing them to expectations fostered by other languages

<comment><USER5> Again how can you say it's an outrageous default if all you reference is what you think it should have done from a generic language PoV not looking to understand why it does it that way?

Javascript came in as a scripting language for working with the untyped string content of a browser so you get dynamic duck typing where it tries to make the types work (generally towards string since that's what the browser had) instead of having the scripter trying to make some simple web content dynamic do more type checks than actual code. In JS functions are just objects (like most everything) and objects. Combine the above so when you say object + "foo" it coerces object to string and it shouldn't seem outrageous just not what you're used to.

Now a fair question would be "Why doesn't TS consider this an error out of the box".

Also for those annoyed by this in places JS wasn't originally designed to go (heavy app logic, server backends, desktop applications) you might want to look at the no-implicit-coercion rule in ESLint or similar.

</comment></comment></comment></comment></comment></comment><comment><USER7> I love this. It reminds me a lot of the work I did in Prism to port what I learned using Haskell in TypeScript: [https://dev.to/vncz/forewords-and- domain-model-1p13](https://dev.to/vncz/forewords-and-domain-model-1p13)

Reading the article, I do have some suggestion:

1\. Never use isLeft or isRight; they break the composability of the monad instance — use `fold` instead, as late as possible

2\. Do not use Enum in TypeScript — they have a runtime representation in JavaScript that's likely messing up a lot of things. Use string unions to accomplish the same result

<comment><USER8> I really wish the TS team would have used frozen null prototype objects for enums instead. Feels like it would have been a perfect fit.

With that said I am curious why you think one shouldn't use enums. I know it's a "factory" IIFE like namespaces at runtime but otherwise I don't understand why it's undesirable?

<comment><USER7> My main issue with Enums in Typescript:

1\. Because they have a runtime representation, I cannot do `import type` — and I am importing the entire file (which might have a side effect). While it's still not justified (ideally importing should not do anything) the reality in JavaScript is different.

2\. I can swap the enum value with a number or a string and it would still work, even if invalid. See [https://www.typescriptlang.org/play?#code/KYOwrgtgBAggxgFwJY...](https://www.typescriptlang.org/play?#code/KYOwrgtgBAggxgFwJYHsRQN4CgpQKIByMAQgDJ5QC8UADADQ5QAiAkgMonlVQCMWAvliwATYHAA2AQwBOwKADMwIRKnTCUbBGHnyAFAHcAFpIQAuWCrQBKcwCMUKccEkgA3EPWbte+MjQA6Qk48K1coAHpwqAB5AGsRDS0dXV9Vf1YOMhCwyJiAaQSvZJ4aUIioghQEKFlJcXEATyg4B3EhUEgoTWkkEABzVLRMRiCs7gAiPBBJWydxhlwM4ImmJABnGbmBIA) for an example

3\. On the other hand, I cannot use strings to create an Enum ([https://www.typescriptlang.org/play?#code/KYOwrgtgBAygLgJwJY...](https://www.typescriptlang.org/play?#code/KYOwrgtgBAygLgJwJYgOYEEDGckHsRQDeAUFFAKIBy6AQgDLlQC8UAROSAIYBGANsKwA0pKABEAkjFoNmbUUgDOPfq2IBfYsUz4FcKJwBcsRCgzY8BFuy58BUAPT2olXHs69euAO7AAJkA)) — this is the exact opposite of n. 2

4\. Duplicates are possible: [https://www.typescriptlang.org/play?#code/KYOwrgtgBAIghgTwPI...](https://www.typescriptlang.org/play?#code/KYOwrgtgBAIghgTwPIDMDqxgGsoG8BQUUAymCACaIA0hUAsgPYXW0AqYwAzpQjURuRBcefKKwAWYAE7dEUALxQATKIBiUgJYjaxOABdpPfAF8gA)

<comment><USER9> 1\. You can define enum like `const enum A {...}` and they will not have runtime representation.

<comment><USER10> const enum doesn't work when in transpileOnly mode (e.g. webpack, Parcel), and Babel treats "const enum" the same as "enum". I'd really love a non-broken const enum in TypeScript, though.

<comment><USER7> I'd love to see them out of the language. I do not have evidence/document supporting this, but I think it was ultimately a failed attempt of copying the C# feature ignoring the fact that JavaScript works differently.

</comment></comment></comment></comment></comment></comment><comment><USER11> This article is unconvincing.

From the article: _Compared to the first snippet, this one is harder to debug. It seems so because 1.) You don 't know that callMe will throw an error or not. 2.) If it throws an exception you will not know what is the type of the exception. The more modular your code is, the harder it is to debug exceptions._

This is only a problem with unchecked exceptions as seen in TypeScript and C#. Checked exceptions are the solution.

The problem with error code return is tediousness:

      int foo() {
         int result = bar();
         if (result == ERROR_CODE)
            return result;
         int result2 = baz();
         if (result2 == ERROR_CODE)
            return result2;
         int result3 = bazz();
         if (result3 == ERROR_CODE)
            return result3;
      }

Compare to the same code written in a language that supports checked exceptions:

      int foo() throws SomeException {
         int result = bar();
         int result2 = baz();
         int result3 = bazz();
      }

In the first version the logic is interspersed with error handling, which makes the logic hard to see.

How do people using Go and other languages that don't have exceptions solve this reduced readability problem?

<comment><USER12> Go does indeed use the tedious approach. Rust and Zig have nicer syntax for it.

But personally, I prefer even Go's "tedious" approach to (unchecked) exceptions, simply because it's too easy to miss an error case otherwise.

I also find that knowing where errors occur is important information, so I don't really mind having it add an extra line or two. (But the more minimal Rust/Zig syntax is nicer.)

(This attitude comes from having once worked on a python server application, which involved a lot, "oh shit, that throws" whackamole.)

<comment><USER11> > _" oh shit, that throws" whackamole_

You don't have that problem in languages that support checked exceptions.

<comment><USER13> I've never seen a language that supported checked exceptions and actually used them consistently for everything.

But then that would be kind of awful, because IMO the checked exceptions cases for "I know this will never actually throw, leave me alone" and "This is just a quick script, go ahead and blow up the whole program if this fails" are poor, forcing you to write try catch blocks all over the place.

IMO, Rust has a nice approach for being stricter - unwrap. If it's a quick script, throw unwrap everywhere with reckless abandon. For real programs, grep for unwrap and make sure for every one, you really know for sure that it will never fail or that blowing up the whole program if it does is the right move. To convert from one to the other, grep unwrap and actually think about what you want to happen if that line is Err.

</comment></comment></comment></comment><comment><USER14> Sure, people say they want to have to check for _every_ possible error, but then Java gets endless heat for having checked exceptions.

<comment><USER15> Yes, this schizophrenic attitude drives me bonkers. Immature JS kids at my company love to make noises about Java's verbosity yet spend hours debugging and troubleshooting most mundane errors because seemingly nothing is ever enforced by the JS interpreter.

My theory is that nowadays Java is unpopular mostly because it is their parents' programming language. That's reason enough for these twenty somethings to despise it without even knowing the first thing about it.

<comment><USER16> Hold on, though. There is plenty to dislike about Java. Everything can be null, interfaces have to be implemented at definition, broken array type variance, no const/mutable at the language level, no value types, etc...

<comment><USER15> No question there is a lot to dislike about java but there are also things it got mostly right or better than competing languages of the day. Checked exceptions is in my opinion one of those.

<comment><USER16> I agree with that. I was heavily involved on the other thread someone linked to about Java's checked exceptions. Until that thread, I thought I was the only one who didn't accept that they were a mistake.

</comment></comment></comment></comment></comment><comment><USER17> I resonated with the post as I'm in a similar position but I'm really sad that typescript chose just to be a thin layer on top of javascript.

The sentiment mostly comes from having the JS ecosystem mostly being untyped and having to interact with it.

That being said I tried io-ts but found it undocumented, missing examples and hard to write. For future libraries/projects I'm looking to try again ReasonML, tried in the past but had to write too many bindings.

<comment><AUTHOR> Author here. I used io-ts when the documentation is still on its root README.md. Apparently it has been moved to [https://github.com/gcanti/io- ts/blob/master/index.md](https://github.com/gcanti/io-ts/blob/master/index.md)

</comment></comment><comment><USER18> IMO the `Either` construct should be avoided in JS because inevitably you'll either need to wrap everything in `try ... catch` anyway or you'll be pulling your hair out trying to figure out how to get them to work in an async/event context, in which case you'll end up re-inventing the Promise api (perhaps wrapped in an extra thunk to make it more fp-friendly or whatever).

A more practical approach is to work along the grain of JS while getting inspiration from fp. A common snippet would be:

       function maybeUrl(str) {
         try {
           return new URL(str);
         } catch (err) {
           return null;
         }
       }

This is much more straight-forward and interoperable. Dealing with something like Left<InvalidUrlError> where you've created an entire error subclass and wrapping function for an unrecoverable failure that will be discarded is way overkill.

The unreliablility of thrown values in JS is a valid concern, but instead of trying to wrap all my code in a container construct, I simply wrap/convert the untrusted errors themselves if I need to use properties on an error reliably.

<comment><USER19> Totally agree.

In cases where the error type matters, I like to return rather than throw the error.

        type Success = string
        type Result = Success | BadInputError | NotFoundError | IncalculableError

        const foo = (input: I): Result => {
          //...
       }

</comment></comment><comment><USER20> Don't write code like this... trying to fake sum types in an object oriented language ends up being a horrible, hard to maintain mess, similar to those examples on the original post.

Typescript's "discriminated unions" [1] make for incredibly inelegant looking code for anything but the most basic sum types, the ergonomics are nothing like the experience of using Haskell or OCaml.

I love sum types but in an OOP the equivalent implementation is the visitor pattern (if the problem calls for it). I was once starry eyed about "making invalid states irrepresentable". I even managed to introduce a code generator to bolt sum types into a production Dart app. My colleagues loved it (not) :-)

Thing is, programs have this annoying tendency of being incorrect no matter what technique you use :-), there's no silver bullet! If a pattern is natural for a given language, it is better to use that pattern than to force it to be something it isn't.

1: [https://www.typescriptlang.org/docs/handbook/unions-and- inte...](https://www.typescriptlang.org/docs/handbook/unions-and- intersections.html#union-exhaustiveness-checking)

<comment><USER21> The joke is, OO language have sum types, albeit incredibly broken ones, because any set of classes that inherits from the same base has the base as a sum type.

You can surface this by implementing the visitor pattern.

</comment></comment><comment><USER22> The first example code is rather off-putting, because it has multiple errors. The code would _not_ throw an exception, because it produces compiler errors so you'll never run it. (OK, so it still generates JavaScript that you could run, but I'm assuming you're using TypeScript properly and won't do so.)

• `return number + 1;` should be `return someNumber + 1;`. If you ignore errors and run the JavaScript, this means that it'll throw a ReferenceError on this line.

• `bar(someNumber) + bar;` is adding a number (well, it should be a number, but you've omitted the return types, so the previous error will mean it infers `any` instead of `number`) to a function. This is a type error.

• `baz()` is called with zero arguments instead of the one it requires.

> _When baz is called it will throw an uncaught exception. By reading the code > you know that foo throws an Error. Debugging this snippet is a piece of > cake, right?_

As mentioned, this code doesn't compile, but if you ignore that and run it anyway, then the uncaught exception is a ReferenceError, _not_ the error you see on a throw line. I… don't _think_ this is what was intended. This also demonstrates what I consider a bit of a weakness of the exception system in such languages: various programming errors that a compiler should catch come through as runtime errors instead.

(I'd generally prefer to use exceptions to indicate _exclusively_ programmer errors, and basically never use a try/catch block, but too much is designed around treating exceptions as normal parts of control flow to be able to do this in most cases. I like the Result/panic split in Rust, where panic _always_ means programmer error, and Result is for probably-exceptional cases, but where they're still generally expected and part of the design rather than programmer error.)

If you fixed only the first error, you'd get a value like "NaNfunction bar(someNumber) {\n return foo(someNumber) + 1;\n}" out of the baz() call. Fun times.

<comment><AUTHOR> Author here. Caught red-handed not running it on playground. Thanks for the correction.

> I'd generally prefer to use exceptions to indicate exclusively programmer > errors

The idea that panic/exception means programmer errors worth to be noted. It think they should be intended for errors that is intended to be unrecoverable. Still, catching errors on runtime is not fun

</comment></comment><comment><USER19> Reminds me of a pattern I've wished would take off in TS, but hasn't (yet):

        const result = await fetchData().catch(e => e)
        if (_.isError(result)) {
          return "some failure"
        }
        return (await result.json()).foo

TS is smart enough to know whether result will be of type Error or the Response type.

This pattern should replace most Either cases when the left is an error state of some kind. Also should replace exceptions and promise rejections.

You can also analogously replace a Maybe type with nullability, simply `type MaybeFoo = Foo | null`.

<comment><USER23> I agree with Maybe not being that useful in TS but the point of an Either/Result type is that the caller is gonna handle it each branch differently. In your example the caller has no way to tell the difference between an error and the succesful return value.

<comment><USER19> Perhaps I was unclear, the implicit typing is so:

        const result: FetchResult | Error = ...
        if (_.isError(result)) {
          // Here TS knows that result is of type Error
          return
        }
        // Here TS knows that result is of type FetchResult

On my phone, apologies for shorthand

In any case, with this pattern TS can easily tell the difference between success and error (or left and right or whatever) as long as the error / left case is a class of a different type than the success / right case.

Tldr, where relevant, classes are cleaner than tagged disjoint unions in TS. Errors are one situation where this is relevant.

</comment></comment></comment><comment><USER24> Tangent: This article made me think deeper about programming languages in general and I found it fascinating. So I went to subscribe to his blog in my feed reader, but alas, no RSS feed. :-(

<comment><AUTHOR> Author here, thanks for the input. Forgot to put it in my backlog :pepesad:

<comment><AUTHOR> Rolled out!

<comment><USER24> Thanks! Subscribed.

</comment></comment></comment></comment><comment><USER25> You can write bad code in any language, Rust included. This article is cherry- picking.

<comment><USER26> I think it's best to stay language agnostic especially in 2020. I try to think data-in data-out and use the best tools available for clean execution.

<comment><USER27> > and use the best tools available

How do you know which tools are the best?

<comment><USER28> 0\. Define what problem you are trying to solve, make sure you understand the domain.

1\. Come up with a set of options by doing research, talking to people who have solved similar problems before, etc.

2\. Rank them by some criteria (e.g. availability of libraries, documentation, raw performance, hireability, support, quality of tooling, etc).

3\. Do some prototyping in your problem domain using the top 2-3 (more if you aren't confident in your ranking) and pick whichever you like best.

4\. Always be willing to change your mind down the road. Avoid the sunk cost fallacy and try not to lock yourself in too much until you're confident in your choice.

</comment></comment></comment></comment><comment><USER23> You don't actually need the tag on Either. This is how I defined my Result type. The shape is enough to discriminate them.

        type Result<S, E> = Success<S> | ResultError<E>;
        type Success<S> = { value: S };
        type ResultError<E> = { error: E };

<comment><AUTHOR> Author here. Did this too. I found some quirks (rather irrelevant) while compiling using TypeScript 3.6-ish.

``` const { value, error } = result; if (error) return doSomething(); if (value) return doSomethingElse(); ```

^ You can't do this because value or error might be not an attribute of result

Nowadays I will just `npm install fp-ts` and use them.

<comment><USER23> You're right that you can't destructure until you've established which side of the union you got, does the tag help with that?

I like a Result type over an Either because it feels semantically more meaningful. I work with people with a wide range of background and a Result type is self explanatory, they can just read the code by themselves without knowing and understanding the convention of which side of the branch the error goes, etc...

<comment><AUTHOR> I agree with you on the Result type being semantically more meaningful and I agree there are a lot of conventions to be remembered coming from functional programming that gets meta.

Thanks for the insight

</comment></comment></comment></comment><comment><USER29> I'm very unconvinced considering the section on avoiding exceptions doesn't discuss async code at all. I mean, a returned Promise from an async function is very similar to the author's "Result" object where you can even pass a success handler and a rejected handler right in the single "then" method. That said, I greatly prefer instead to await on an async function and handle any rejections in a catch block.

<comment><USER30> Exceptions aren't typed though so you either have to decode it in some way or treat every exception the same.

</comment></comment><comment><USER31> Please please please don't perpetuate the use of either or maybe types :(

They make software very hard to maintain and end up breaking anyone who depends on a library that uses them.

Rich Hickey (author of Clojure) has a great discussion of Either and Maybe here: [https://www.youtube.com/watch?v=YR5WdGrpoug](https://www.youtube.com/watch?v=YR5WdGrpoug) that dives into their unsoundness.

<comment><USER32> Rick's argument seems to be that we should have better tools in the language type system. If your language doesn't give you those tools, these are still very useful types. In addition, the library maintenance issues he raises seem trivially solvable with languages that allow function polymorphism or have refactoring tools to me.

</comment></comment><comment><USER33> With JS and Typescript, I find myself going back to logic error handling in the catch block, because there is only one Error type. You can't have multiple types of exceptions. So you have to set the error.type attribute and then do logic.

<comment><USER34> It is worth noting that you can throw anything you want. It doesnt' have to be new Error(). There are definitely some drawbacks to this, such as if the errors thrown by your dependencies are of type Error, but the upside is that as long as you are consistent, you get a much richer set of types available.

IMO this also works primarily because errors are very rarely thrown by native APIs, which instead encode failure into the return type. For this reason, you can typically have a reasonable level of control over what code can reasonably be expected to throw.

</comment></comment><comment><USER35> Why do you need Either when you have union? All the left types subclass Error so you can easily separate that from the successful value as well. Seems rather a dogmatic choice.

</comment><comment><USER36> Does anyone else hate foo(), bar() and baz() as example names. They are meaningless - except communicating that its a programmer selected name. Even func1(), func2() would be better.

<comment><USER37> f(), g() and h() are decent alternatives.

Of course, the real solution is to come up with an reasonable example scenario with meaningful names.

<comment><USER38> a, b, c seems more intuitive

</comment></comment></comment><comment><USER39> Well exceptions are generally a sign that code smells. Instead of throwing an exception, just return the default value.

<comment><USER40> > 1 / 0 just returns 0, #yolo

No thanks.

<comment><USER39> Returns infinity like it should

</comment></comment></comment><comment><USER41> Stopped reading after the exception / result stuff. You can have both, both are useful, learn yourself some Swift maybe.

<comment><USER42> I can see the author's point, that a throw behaves awfully like a GOTO. It can add complexity and unpredictability to the code path, especially dealing with external modules.

On the other hand, there are situations in which throw/catch provides a simpler, even elegant way to handle errors.

So I'd agree with you that both are useful.

The author makes a good point though, and I will consider it next time whether returning errors may be more suitable, to be clear and explicit/verbose, without requiring the GOTO-like control flow.

<comment><USER43> Another place throws are inconvenient is chaining/streams.

Pseudocode:

        var goodStuff = listOfStuff.map(x => transform(x))
            .filter(t => typeof(t.result) != Error)
            .map(y => handleGoodData(y))

If `transform()` threw exceptions, this whole thing aborts. But if it can return an `Error` type, we can continue processing the good ones and log the bad ones (here I ignore them for simplicity).</comment></comment></comment>


JOHN MCAFEE: The Obama administration doesn't understand what 'privacy' means - <AUTHOR> http://www.businessinsider.com/john-mcafee-obama-administration-privacy-2016-1 <comment><USER2> I would tend to agree</comment>


Question: link to Amazon's study of HTTP latency vs cart abandonment? - <AUTHOR>

They did an interesting study showing that response time above 200ms led to people spending less money.  Basically, they A-B testing and artificially added server latency in small increments and measured how much money people spent.  200ms (or some similar number) was optimal, going lower didn't show benefit, going above lost them money.<p>Anyway, I can't find a link to this anymore.  I think it was on some blogs, probably after a talk Amazon gave.  Anybody have it?  I don't seem to have enough Google-fu to find it :( <comment><USER2> Greg Linden writes: "In A/B tests (at Amazon), we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue."

Google experienced a similar drop off in revenue when page load time increased.

More details on Greg's blog: [http://glinden.blogspot.com/2006/11/marissa- mayer-at-web-20....](http://glinden.blogspot.com/2006/11/marissa-mayer-at- web-20.html).

<comment><AUTHOR> Thanks, much appreciated.</comment></comment>


Archaeologists Find Infants Wearing 'Helmets' Made from Skulls of Other Children - <AUTHOR> https://www.smithsonianmag.com/smart-news/remains-infants-found-wearing-helmets-made-skulls-other-children-180973608/ <comment><USER2> Ah, the origin of the Cubone peoples are about to be revealed!

</comment><comment><USER3> It's amazing how superstitious and brutal humans can be. It reminds me not to take a naturalist approach to everything. Even in war very few people would be this brutal now, we have moved beyond what we were and I hope we can do it again.

<comment><USER4> > Even in war very few people would be this brutal now, we have moved beyond > what we were and I hope we can do it again.

While I appreciate your sentiments I can't help but feel that you are quite incorrect.

ISIS? Burning people in cages for propaganda? Mass rapes and executions? That's all happening in today's age.

<comment><USER3> The whole world does not grow at the same rate. Some places still live in the dark ages.</comment></comment></comment>


Tell HN: Stripe is coming to UK. I just got invited to the limited beta. - <AUTHOR>

Well, as the title says, I just got an email to join the limited beta. This is awesome for all UK developers who needs to accept online payments. How many of you received this email? <comment><USER2> "In what we're putting down to a bout of Valentine's Day confusion — or a desire to keep the launch quiet — Stripe co-founder Patrick Collison tells us that emails about the UK beta were sent out to some users "in error". So, despite some employees confirming the UK launch, Collison claims it isn't happening. We're continuing to look into this."

<http://thenextweb.com/insider/2013/02/14/stripe-uk-beta/>

</comment><comment><USER3> I would love an invite! Have also been on the list from the begging.

<bribe>

To anyone from Stripe reading this, I will give everyone at stripe a voucher for my website <http://www.posterhaste.com/> if I could have an invite! Would love to move off Paypal!

</bribe>

</comment><comment><USER4> That's good news for UK.

I'm in Sweden and been on that list since Stripe went public in USA, no email love here.

</comment><comment><USER2> I would love an invite! I was just about to sign up with one of their competitors but would prefer to use Stripe.

</comment><comment><USER5> OMG that's a good new! Just moved to the uk and would love to ditch paypal for Stripe for me business!

</comment><comment><USER6> i am in Uk and been on their list since forever and did not receive anything :(</comment>


Announcing HashiCorp (a Company for Vagrant) - <AUTHOR> http://www.hashicorp.com/blog/announcing-hashicorp.html <comment><USER2> I'm here to answer any questions, if you have them. I'm really excited!

Fun fact, I first "launched" Vagrant on HN almost exactly 1000 days ago: <http://news.ycombinator.com/item?id=1175901>

<comment><USER3> Maybe this is a stupid question, but how do you pronounce HashiCorp? Is it "HAA-she" (rhymes with Kashi, like the cereal) or is it "HASH-i" (rhymes with "flashy")? I'm guessing it's the former since it'd match the Japanese pronunciation of your last name...?

<comment><USER2> Rhymes with Kashi. ^_^

<comment><USER4> I'm outing myself as a philistine here, but how do you pronounce Kashi, if it doesn't rhyme with flashy?

<comment><USER5> I think it rhymes with 'squashy' or 'washy'.

<comment><USER3> Heh I probably should've gone with squashy or washy, but whenever I try to pick a rhyming word, I take the suffix syllable and prepend every letter in the alphabet until I come up with a word (aashi, bashi, cashi...). Kashi won... :\

</comment></comment></comment></comment></comment></comment><comment><USER6> Use a backpacker for the mascot. It matches what the product does better. Homeless people dont have much stuff. Backpackers have and take their stuff everywhere. Which is the spirit of what you are doing. Have your stuff avaiable everywhere. So, a backpacker.

<comment><USER7> I'm having trouble understanding your recommendation. Vagrants take ALL of their belongings with them, they have little where else to store any items they. Backpackers couldn't possibly take everything they own with them or they would by definition be Vagrants.

I think having a Vagrant as the mascot for Vagrant is the only obvious option.

<comment><USER6> Ok, my point is that both take their belogings with them. Backpackers take the stuff they need to travel around. Same as Vagrants, as you mentioned. But, to the market, having a Vagrant as a mascot _might_ be seen in bad taste. Thus, to reduce the chance of rain over his parade, he could potentially just change mascots. That way, people who get _easily offended by anything_ won't have an excuse to say anything. Plus, when this product gets more and more traction, people _will_ question the mascot choice. That's why Frostred Flakes has Tony the Tiger, and not Bad Luck Johnny that lives under a bridge. Its all about perception. Though this is an issue some hacker don't get, because to them the world is black and white. Not saying it is _you_ , of course. Just talking out loud.

Also, why the only _obvious_ option?

Why couldn't it be a Puppy, Cat, Horse, Printer, Cloud, Keyboard, Fish, or anything else? Why the Vagrant? Its not obvious. For all the client know Vagrant might be an acronym or some made up tech name.

</comment></comment></comment><comment><USER8> @mitchellh Congratulations first! As I've been reading your tweets I've been guessing that you would starting, which focuses you on Vagrant.

I have a few questions: When did you think about the first time and when did you really decide to do this step? How do you start? Bootstrap it by your own or try to go with for a VC? How are you planning the addon open source/paid addon ratio will be like?

I wish you all the best for your company. And because I've been using Vagrant every day: Thank you very much.

<comment><USER2> > When did you think about the first time and when did you really decide to do > this step?

The inkling of a possibility of something like this only entered my head around March/April 2012. I committed to the idea in June 2012.

> How do you start? Bootstrap it by your own or try to go with for a VC?

I'm attempting to bootstrap it on my own for now, because I think I have a solid foundation so there is a clear line to revenue. Of course, my runway to do this is much shorter than if I had VC funding. On the other hand, I have a lot more freedom without VC funding.

> How are you planning the addon open source/paid addon ratio will be like?

There will be many more open source add-ons, and I think it should be this way.

Thank YOU for using Vagrant. :)

</comment></comment><comment><USER9> Can the first order of business be a renaming so the mascot of a useful and widely-used product isn't a homeless person?

<comment><USER2> The project won't be renamed, but it will be rebranded in the next few weeks. In the three years the project has existed I have only gotten two or three complaints about the mascot, but everyone has agreed that "Vagrant" itself is fine. Note that I've talked up to some pretty high levels of US government using Vagrant, and most are okay with it. One [fairly large/visible] organization within the US government has said they can't use it until the mascot is changed.

Vince the Vagrant is being retired.

<comment><USER10> Vince has a really good 401k plan, despite his scruff look. He's going to be sipping drinks on a Caribbean beach before we know it!

</comment></comment></comment><comment><USER11> Where can I go to find more information about Vagrant's plans for supporting more hypervisors than Virtualbox?

</comment><comment><USER12> Congrats! I should probably get around to actually testing Vagrant one of these days too...

Also, the website looks absolutely gorgeous. Fantastic work there.

</comment><comment><USER13> good luck! vagrant seems to fit a sweet spot in real world configuration management needs. i look forward to a future independent of oracle.

</comment><comment><USER14> Came here to say hi and congrats Mitchell. Was fun hanging out in CZ, we should do it again, this time, stateside.

</comment><comment><USER15> Vagrant is a VirtualBox with a bunch of packages pre-installed? Am I correct?

<comment><USER16> Nope - Vagrant is a tool for managing VM providers.

Virtualbox has been the main provider it manages. Part of this announcement includes adding support for more providers!

</comment></comment><comment><USER17> Just a heads up: Your favicon is almost identical to <http://gree-corp.com/> , big social game maker in Japan.

<comment><USER18> It's a cube

Surely you can't trademark a cube?

<comment><USER17> Fair enough. It's maybe not such a problem in the U.S. where the logo isn't in the media much, but to me the blue hexagon immediately triggered recognition. I'm only passing on the info.

</comment></comment></comment><comment><USER19> Any plans for helping unit test vm creation? One of the biggest problems I've had is trying to verify that my Chef installation works after each change

</comment><comment><USER20> Excellent. I've been watching Vagrant from the sidelines. It's looking great, but it's useless to me until it gets a KVM backend.

<comment><USER21> Until it does, you might want to try McCloud.

<https://github.com/jedi4ever/mccloud/>

<http://jedi.be/blog/2011/09/13/libvirt-fog-provider/>

</comment></comment><comment><USER22> Congratulations and best of luck Mitchell!

</comment><comment><USER23> Congrats! Looking forward to see how Vagrant grows over the next couple years.</comment>


Show HN: Pocketwatch Free Demo – Recurring Job Scheduling as a Service - <AUTHOR> https://pocketwatch.xyz/fancy.html <comment><AUTHOR> Hello all! I built Pocketwatch as a simple solution for web applications to schedule recurring tasks. It lets you schedule a recurring series of HTTP requests, spaced by an interval you choose, for a duration you decide, back to your application, with an optional MIME payload.

It can be an alternative to running your own systems like Sidekiq, Celery, or Quartz and the operational overhead that comes along with them. Systemd timers, cron jobs and cloud provider tools like CloudWatch Events are also used for job scheduling but this is a scalable, fault-tolerant system built just for this one purpose.

I've set up an API key just for HN users. You can use the linked console page above to test it out, or get the Node.js client library (link on that page), and use this API key:

      i_am_hn_and_proud

Questions and feedback are greatly appreciated :)

The current top Show HN post inspired my messaging. That poster really knows how to clearly say what this is about. Apart from their nicer interface, the difference I can tell is that Pocketwatch allows recurring tasks, while their one does not currently.

</comment><comment><USER2> what's the diff with [https://posthook.io/](https://posthook.io/) that offers me .5K / month free calls ?</comment>


Google+ Follow Recommendations Based your Facebook Profile - <AUTHOR> http://www.plusbuddy.com

<comment><USER2> Hi, are you associated with the Plus Buddy site? There are two typos on the frontpage: "... and provides recommmendations of who to follow..." and "We'll recommned Google+ users ...".

</comment><comment><AUTHOR> Thanks for catching this. We're on it. How do you find the tool working?

<comment><USER2> I don't have a Facebook account and I'm not on Google+, so I can't really evaluate the tool from a personal perspective. But I find it weird, that I get some recommendations if I click the "recommend" button without entering any URL at all or complete garbage. You could add some form of input validation to see if users entered a valid Facebook URL. If a user enters his Facebook URL in a wrong way, he will get some results, but these recommendations are not based on his profile.</comment></comment>