Milestones for SaaS Companies - <AUTHOR> http://rein.pk/milestones-for-saas-companies/

<comment><USER2> This article must have been written with an implicit ARPU in mind. For lots of low ARPU companies, milestone 1 and milestone 2 are going to be inverted. That is, you'll likely get 10 paying customers before finding true product market fit.

Also, likewise, hundreds of customers will not equal $1M ARR for lots of SaaS companies. Even at 1000 customers, you'd need ~$100/mo or greater subscription price.

For SaaS companies with < $100/mo pricing, the equations and milestones are very different. For example, a $30/mo ARPU means having to get 3x more customers. So suddenly, hundreds of customers are not enough, you need thousands. That can mean the difference between a direct sales or white glove treatment to something slightly higher scale.

</comment><comment><USER3> I enjoy reading how he quantifies pm fit - different people have different approaches. Another guy, can't think of his name, said 40%+ would be "very disappointed" if business shut down. Think they're all useful signals.

</comment><comment><USER4> I find it hilarious that "profitable" is the last milestone.

<comment><USER5> Once you're on the investment treadmill, growth is everything. Every dime of profit is a dime not reinvested in growing the company. Early investors are making a tremendous commitment - they're not just investing, they're giving up liquidity on their investment. They can't just turn around and resell it to invest in something else, the way they could with publicly-traded stocks. Illiquidity is a largely alien concept to most people.

A little background. There are really three factors to any investment - risk, return, and liquidity. The more you sacrifice with one, the more you expect from the others. Startup investments are high risk and low liquidity, so they should generate incredible returns when they do succeed.

So no, your angels and VC don't _want_ profitability. They want growth. When you finally achieve a "liquidity event" (selling the company, or IPO), it's getting sold to the people who want profitability, and are willing to sacrifice returns for it. Different investors, different needs.

As a business, if you want control, you eschew investment and instead target profitability and stability. But you're greatly limiting your growth. That's fine, too.

Do you want to be rich, or do you want to be king? If you want to be king, avoid investors and build for stability. If you want to be rich, take the investment and grow as fast as you can.

If you want to stand on the sidelines, that's fine too. But don't laugh and mock business decisions by smart and determined people. Maybe they're trying to solve a problem you don't understand.</comment></comment>


China bans wild animal trade until coronavirus epidemic is eliminated - <AUTHOR> https://www.washingtonpost.com/world/asia_pacific/china-bans-wild-animal-trade-until-coronavirus-epidemic-eliminated/2020/01/26/0e05a964-4017-11ea-971f-4ce4f94494b4_story.html <comment><USER2> Well given that Ebola, Coronavirus, etc have been sourced from people eating these infected animals, this 'wild animal trade' in China and similar should be permanently banned to reduce the risk of another situation like this.

</comment><comment><USER3> It seems like this will do practically nothing. Akin to locking the barn after the horse has bolted.

The ban needs to be permanent.</comment>


I'm a Black Police Officer. Here's How to Change the System - <AUTHOR> https://www.nytimes.com/2020/07/16/opinion/police-funding-defund.html <comment><USER2> >"Police academies must change, too. Police are taught that the enemy is "out there." When they arrive at work with that mind-set, they don't know who wants them in the community, and who wants to kill them. It's no different than troops in Afghanistan or Iraq. We are patrolling the streets of our own cities as an occupying force.

Our training also focuses on worst-case scenarios: how to arrest someone, how to fight, how to use a weapon. Instead, it should emphasize preventing escalation. Once you get to the point where you are having to fight, you've already lost. The question after a shooting by the police should not be "Was it legal?" but rather "Was it necessary?""

Opinion: Promote this man (David Hughes) to Chief Of Police.

He is very, _very_ wise!

He totally understands the tremendous, tremendous responsibility of what it is to be a Police Officer!

He _gets it_!

Article favorited.

<comment><AUTHOR> Read about Daytona Beach police chief Mike Chitwood in this piece:

[https://projects.tampabay.com/projects/2017/investigations/f...](https://projects.tampabay.com/projects/2017/investigations/florida- police-shootings/why-cops-shoot/)

</comment></comment><comment><USER3> Paywall.

<comment><USER4> [https://outline.com/ZEkhYF](https://outline.com/ZEkhYF)</comment></comment>


How we might abolish Cabal Hell, part 1 - <AUTHOR> http://www.well-typed.com/blog/2014/09/how-we-might-abolish-cabal-hell-part-1/ <comment><USER3> Why do we keep running into this problem over and over again? Why do we need one package manager per programming language? Why is software distribution so damn hard?

<comment><USER4> Because general purpose package managers suck at dealing with the concerns of individual programming languages. E.g. installation paths, virtual environments, different compilation methods, etc.

There is also no single cross-platform package manager. Mac has macports and homebrew, windows barely got one, linux has yum, apt and others. As a language designer, you don't want any part in this, you want your code to work. So you make your own.

edit: To clarify, I'm suggesting that we're stuck in a local maximum - <USER2> that all these systems already exist and have widespread adoption and tool dependency in their own environments, there isn't much of an impetus to use Nix or something similar even though in the grander scheme of things it'd be way nicer.

<comment><USER5> Haskell folks seem to be gravitating towards the Nix package manager, which is general-purpose. We need to stop the proliferation of a package manager per programming language and make systems package managers capable of handling the use-cases of pip, bundler, npm, cabal, etc. Nix and Guix are the only 2 general-purpose package managers that I know of that can do it.

<comment><USER6> > Nix and Guix are the only 2 general-purpose package managers that I know of > that can do it.

For anyone constrained to GNU/Linux, right?

<comment><USER5> > For anyone constrained to GNU/Linux, right?

I don't feel constrained by a free software operating system. Besides that, a bunch of people use Nix on OS X. On Windows I suppose you're stuck with the inferior package managers.

<comment><USER7> _" I don't feel constrained by a free software operating system."_

I appreciate the sentiment, but there's a substantial difference between "constrained to" and "constrained by".

</comment></comment></comment></comment></comment></comment><comment><USER8> Cabal is by far the worst thing about Haskell. With no other programming language have I ever had to deal with these difficulties. It made me stop using Haskell.

<comment><USER9> Mostly because these difficulties are front-loaded by the Cabal system. Version/implementation conflicts are faced by all other package managers, but most solve the problem by (a) waiting until you notice your program has broken and then (b) suggesting you nuke your package sandbox.

Cabal just tells you up front when this will happen which can be annoying. That said, the prior mechanism requires that you notice when version mixes are causing issues.

<comment><USER8> I understand that is's a very hard problem to solve, but there has to be something better than the Status Quo.

A couple of months ago, I wanted to write a simple Web App using Yesod. The only way to get a working installation of yesod and all the dependencies was by using the sandbox thing. This however meant, that after every code change, you had to wait ~10 secs for the project to rebuild. That doesn't sound like much, but it gets annoying very quickly.

<comment><USER10> That's not a sandbox problem, that's the cost of developing in an AOT-compiled language. Sandboxes do require you to recompile Yesod and all its dependencies (> 10 minutes) every time you start a new project though, which is pretty annoying.

<comment><USER7> I agree that it's not a sandbox problem, but it's not inherent to "an AOT- compiled language" \- builds of my yesod projects take disproportionately long compared to my other development, almost all of which takes place in compiled languages.

</comment></comment></comment></comment></comment><comment><USER11> I was wondering if someone could explain something to me. I understand the issues involving inconsistent environments, but bad constraints don't really seem like a particularly challenging issue to me.

If you have libraries A and B which each require mutually exclusive versions of library C, what is stopping the compiler from adding both versions of library C to the compiled code for A and B to call separately?

Obviously this would result in larger binaries and should generate a build/install warning, but it seems like this would solve the overwhelming majority of Cabal's dependency resolution issues.

There's clearly something I'm missing since this has been an outstanding issue in Cabal for quite some time. Would someone with a better understanding of GHC/Cabal's compilation/linking/installation steps mind shedding some light on this?

<comment><USER12> I maintain the package manager for the Dart language. This question comes up all of the time. The problem is that these libraries may interact at runtime:

        * A gets a value from its version of C.
        * It passes that to your app.
        * Your app gives it to B.
        * B gives it to its incompatible version of C.

Haskell may handle this scenario differently because of its type system, but in Dart, this would cause lots of user problems.

<comment><USER13> Anyone know if there's a formal name for this situation/problem?

Thanks for the clear explanation BTW.

<comment><USER9> You probably would have good vocabulary for this in the _ML family languages. You 're essentially talking about existential type mismatching—a core component of how modules work in _ML family languages.

It's just hard to read that into Haskell since "modules" are not as well represented in-language and exist somewhere between Haskell-the-language and Cabal-the-package-manager/ecosystem.

</comment></comment></comment></comment><comment><USER14> The first thing that needs to be done is to acknowledge its existence. Often Haskell zealots pretend it's not a Cabal problem but a user problem. So this article is indeed a very good start.

<comment><USER7> I think it's _not_ "a cabal problem", in the sense of cabal being somehow awful and "doing it wrong" where other systems "do it right".

The symptoms are a result of the confluence of a few things (mentioned elsewhere in this discussion), some of which are quite positive, which make the problem substantially harder. Which isn't to say there's no problem, or that nothing could or should be better - I'm glad it's getting attention and I'm glad people have ideas for improvements, though both of those have been true for a while.

</comment></comment><comment><USER15> > The feeling of powerlessness one has when Cabal does not do what one wanted > and one does not know how to fix it.

I experienced this immediately after I read Learn You A Haskell and it made me give up on the language. I develop on Windows (currently?) and I was passionate about creating my first hobby project in Haskell. But every direction I turned, I ran into an issue where a dependency or transitive dependency expected some linux library to be there and I couldn't install.

Maybe I'm just spoiled and need to be more open minded. I come from Java-land where I take "write once run anywhere" for granted. I eventually switched to Clojure but that was unsatisfying for different reasons. I wish there was a language with Haskell's purity and type system but Java's ability to "write once and run anywhere".

I think Frege is very close, but I feel uncomfortable learning something with such a small community (damn... I am spoiled).

<comment><USER16> >I develop on Windows

In my experience, this sucks in basically any language.

<comment><USER17> Then your experience is rather limited.

As a counter-anecdote, my experience is that Windows is frictionless for developing PHP, Node.JS, C#, Java, Scala, Elixir/Erlang. It's also close-to- first-class for Python. Ruby to a lesser extent, with a lot of the community just assuming you're on OSX, period.

I've often been impressed by how, despite the hacky nature of the Node.JS community, a lot of stuff simply just works there. For example, getting PhantomJS, a full-fledged scriptable headless browser, available for a project is a single "npm install" away on _all three major OSes_.

<comment><USER18> That is definitely impressive of the Node.js community! Good on them. Also great to know Elixir is working well on Windows, yet another feather in its increasingly-well-plumed hat!

I remember a get-Windows-working-better rallying call at a Ruby conference I was at 4 years ago, and as far as I can tell, things have not changed much since then. The OSX thing isn't quite fair though - everything works on linux too, because that's what people deploy on. In fact the trend seems to be toward developing against containers running your production version of linux, rather than OSX directly.

</comment></comment></comment></comment><comment><USER16> I had no idea people were having problems with Cabal! It's always worked very well for me. It seemed like one of the better build systems out there.

I suppose a lot of the issue comes from the fact that Cabal is very careful about everything. It seems like most package managers I use have a "try and maybe fail" attitude, while Cabal seems to have more of a "guarantee success or fail" attitude.

</comment><comment><USER13> Nix is getting mentioned a lot in this thread. If anyone's interested in NixOS feel free to email me. I switched to it on my main computer about a month ago and might be able to give some perspective on what it's like.

My config is here: [https://github.com/seagreen/vivaine](https://github.com/seagreen/vivaine)

<comment><USER19> Could NIX be used as a _language_ package manager? Does it allow installing on cutting-edge code from random repositories? Can you only download something, without installing it? Can you access multiple versions of the same library from a single "project" (e.g. by using different aliases for different versions)?

<comment><USER13> Yes and with ease for the first two. Yes, but you may have to write some Nix code for the last.

</comment></comment></comment><comment><USER20> As someone who has tried to compile pandoc from source, I welcome this.

</comment><comment><USER21> You know you play too much Destiny when...

But seriously. It's so difficult to realize how much of a game changer a great package manager can be. I've never tried Haskell, but is this really THAT much of a problem? I hear so much praise and worship about Haskell...

</comment><comment><USER22> I think the Haskell folks would do well to consider a complete rewrite of Cabal and look at something like Leiningen, Npm or even Opam as a base from which they can start with their new version.

<comment><USER23> Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.

<comment><USER7> I think that's only a part of it. I think that it's also the case that the Haskell ecosystem has more breaking changes at the root of diamonds in the dependency graph - which isn't something a build tool can solve (or at least isn't something any build tool _does_ solve).

<comment><USER10> In my experience the dependency graph often has many more nodes as well. I'm not sure if this is because Haskell code is especially reusable or Haskell developers are especially lazy.

<comment><USER23> There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.</comment></comment></comment></comment></comment>


Vampire myths originated with a real blood disorder - <AUTHOR> https://theconversation.com/vampire-myths-originated-with-a-real-blood-disorder-140830 <comment><USER2> He should have least mentioned the Carmilla story, which was the origin of the Vampire story. From an porphyria autopsy report from Graz, Austria about a dead noble girl from Eastern Styria, which a horror writer in England caught up by a popular press report from Vienna, and then wrote the erotic/gothic Carmilla novel, about lesbian night creatures longing for blood. [https://en.wikipedia.org/wiki/Camilla](https://en.wikipedia.org/wiki/Camilla) (Btw Wikipedia doesn't know the real background story for this)

Which Stoker mixed with the Romanian Vlad Dracul story, who was not blood obsessed, but obsessed with anal torture. But he beat the Turks and therefore he was quite famous.</comment>


Purser.js: A JS library for preserving user data from first visit to signup - <AUTHOR> https://github.com/bilbof/purser <comment><USER2> This seems like it's just a serialized cookie, am I missing something?

One thing that would make this insanely valuable is if you had the option to follow the same rules that google analytics uses to store UTM cookies.

Since the release of analytics.js they no longer allow you to ask the ga object what it thinks the current utm variables are (as they can be overwritten, expire, etc). One might want to do this to track stuff in their own database, etc.

That means one has to attempt to model their algorithm to get it to work, and lets just say thats super annoying:

[https://lh3.googleusercontent.com/8EiYEKczs9NLsuKkZjRmeygRZ1...](https://lh3.googleusercontent.com/8EiYEKczs9NLsuKkZjRmeygRZ1DjP2NWTI5BQ2_3n8iOjfsbb3GjL4ETu241M5gZEOs=w721)

<comment><AUTHOR> Thanks your suggestion. That's pretty much what the library is doing. One thing the library does is if on their first visit a user has utm codes in their URL (e.g. utm_medium) it'll store this and make it available via pursor.convert() & pursor.fetch().

Currently the library looks for 'utm_source', 'utm_medium', 'utm_name', 'utm_term', 'utm_campaign', and 'utm_content' in URL.

If I understand correctly you would like additional data collected by analytics.js made accessible via the library? I created an issue for your idea here ([https://github.com/bilbof/purser/issues/1](https://github.com/bilbof/purser/issues/1)).

</comment></comment><comment><USER3> This is pretty cool, but it seems like it doesn't store data for multiple visits. Say I land via Google yesterday, come back today via HN, then sign up. I'd like to know all that.

<comment><AUTHOR> Thanks. Do you mean track additional UTM codes etc. for each subsequent visit?

Is having the following data included in the object returned by purser.fetch() what you're after?

        "visits_before_conversion": 2,
        "subsequent_visits": [
          {
            "referrer": "news.ycombinator.com",
            "utm_source": "hn_post"
          }
        ]

I added this as an issue here [https://github.com/bilbof/purser/issues/3](https://github.com/bilbof/purser/issues/3)

</comment></comment><comment><USER4> Thank you for your contribution to building a surveillance state.

<comment><USER5> if anything OP is helping dismantle it by releasing OS code that we _need_ but isnt maintained by a massive conglomerate that is literally integrated with the US Federal Government.</comment></comment>