ixmatus

The advice to just get an LLC going first then convert to a C corp is fine for their stage, I won't argue against it. However, what you're saying in opposition to forming a C corp early doesn't feel very rigorous.

From my limited experience as a founder, forming a C corp early has made some things easier. The time we had to convert a California C corp to a Delaware C corp became messy and I imagine converting a {whatever state} LLC to a Delaware C corp also has the potential for being messy.

The conversion cost us a lot of money to have done right when instead taking boilerplate docs and simply forming in Delaware first would have been much easier.

Angels and incubators will generally want you to be a C corp first or convert ASAP, too (which is a valid option but I feel like there are other more important things to be spending cycles and money on). Raising money without worrying about converting your corporate structure is a pretty big reason to just do it as a C corp from the start.

Getting into an accelerator or incubator (even if it's one that's not popular) can really help with the legal stuff since you'll be able to get more advice and they will always have those boilerplate docs for you.

Form a C corp in Delaware and get the ownership figured out ASAP. I also generally think that all of the founders should vest (no cliffs or anything, but a four year vest for everyone will keep the company safe in the event one of you leave, even the CEO).

I agree with cglee's comment that you don't need capital right now, get more traction and build more product. Then in six months revisit the topic and determine if your organic growth is enough to sustain further growth or whether you'll need capital injection.

Raising money, btw, isn't always just about the money - if you pick your investors correctly they can help you and your business tremendously.

The point went over your head, in any failed dynamic there are always mistakes made on both sides. I'm trying to encourage her to think deeper (not write) about it beyond not catching the "warning signs" which places her in a victim position. Whether she was or not, victim cycles create repeat patterns until the person sees their own role in it.

I'm encouraging psychological healing. I've very much been through a very similar experience.

[EDIT]

It actually sounds like it turned out well since she did end up with a solid co-founder relationship anyway. I'm leaving this up for posterity but now think my thoughts on this are unwarranted.

It's glossed over because it requires more than a single party to represent the "story" in a fair light and it would unprofessional for her to write about her biased emotional experience.

I think she is 100% in the clear for glossing over it and I personally would have left out bits like "backstabbing" &c... They may or may not have but describing her personal emotional experience while leaving out the hairy and sticky co-founder dynamics is a great way to share an experience of the "dark underbelly" [that is startups].

I experienced a co-founder split not too long ago and I can definitely tell you from my personal introspection that you may need to look deeper than "it was my fault for not seeing the warning signs".

It always takes two to tango and you're right to not bitch about them but then saying you were stabbed in the back is silly. Being a founder is tough, having co-founder problems is tougher, clearly understanding what your part in the dynamic is or was is even more difficult.

Sometimes, too, to get this level of internal depth takes distance from the people and the experience. It took about six to eight months for me to figure out what was rightfully my fault and what was rightfully my co-founder's fault - beyond "seeing the warning signs early".

Also, I don't know what your captable looked like but if you were the controlling interest you cannot and should not expect anyone to care about what position you're left in - you must be prepared to shoulder the burden on your own for a bit if they decide it isn't worth their time anymore. The more you own it the more you own it.

Hope you're okay and sorry if this comes off as admonishment, it actually comes from a heartfelt place. You're welcome to contact me personally if you want more support.

[EDIT]

Re-reading my comment, I might be coming off too much as an armchair psychologist, I'll leave the comment up for posterity and maybe you'll find something useful in it or not. Either way I think you've handled yourself well and hope that you yourself are doing well.

It's funny, strong type systems are really about explicit documentation. I'm sure the comments are good but translating a spec into Haskell types is a form of strong and explicit documentation that is also functional.

"Raise your rates" is excellent advice and, OP, you may or may not understand that it's actually more about psychology.

Higher rates help filter out demanding clients and also make it "worth it" when you do get a demanding one. Higher rates helps focus you, with 20 cheap clients you'll feel like going bonkers. With one or two high-paying clients you'll feel focused.

With higher rates and therefore more focus you also provide better customer service during the day. That will help reduce the amount of off-hour communications (this is also a boundary thing that Patrick already mentioned, be firm). Clients that understand that they get what they pay for and are comfortable paying a higher rate usually let you do what they are paying you to do and only communicate on the set meetings over minutiae.

Once you've learned Haskell, actually, you can be far more productive in it than most other languages. The only piece of your statement that I'll agree with is that Haskell doesn't really have any great numerical or scientific tooling (like Python).

As languages go, Haskell out paces (not just in elegance but pragmatism too) most of the mainstream imperative languages.

The tooling for scientific computing does need to catch up though.

Well, that project, Q just doesn't even share the same thesis of Haxl. At all. Two completely different projects, Q couldn't be used for what Haxl is intended.

If you had posted the link asking for a comparison, that would've been different, but your ignorance seemed obvious to me because of the haughty wink at the end of your posted link implying we were being let in on some kind of secret.

Which bodes extremely well for them. They may quickly become the PayPal of bitcoin for providing a solid service allowing businesses to interface with BTC; as PayPal did for giving businesses and individuals a solid service to transact using the internet.

You can do "kind of" dependent types in Haskell too but it's an ugly mess (like trying to do it in Scala). Idris handles it really well for general programming tasks.

To each his own. I rarely hear fluent Haskellers say they don't care for the syntax though; if you haven't really gotten far enough to write production code in Haskell that leverages Haskell's powerful abstraction features, then you should and you might find the syntax growing on you.

The syntax is nice because it enables the programmer to express software in a terse way, generally favoring the types as documentation and a strong mental model to understand the abstraction.

You obviously don't understand what Haxl is for.

Yeah, in the future don't delete your comment unless you've been convinced that you really were being a troll or asshole. Stimulating discussion is what makes this site great and don't let the wannabe hackers that don't know how to have such a discussion deter you from posting.

Hacker News is a funny place and you'll find contrarian points of view tend to be "jumped on" unless you use difficult to refute language that pulls your disagreeing commenters or downvoters into a logical argument.

The other guy that commented on yours is a good example of language that's less "enticing" for trolls and still provides an interesting counterpoint to the original article.

It's really amusing to me that FreeBSD Jails have existed for quite some time already. I think the novelty though is "shared configurations" and shareable environments that are not VMs.

Right now "cloud" stuff is looking a lot like Subversion back in the day - I'll love it when the "distributed cloud" arrives (mesh networks are kind of the first iteration of that but they won't catch on until more people have fiber internet and there comes a commercial use for it like what Kickstarter did for crowdfunding).

[EDIT] The downvote trolls have been out recently - this guy has a legit comment; it's not detracting and it provided an interesting point of discussion that I myself took up. There's no real foul in his comment.

Yeah I'm aware of Chicago Boss and have used it, but like most "frameworks" websockets are bolted on and you have to write special handlers for them.

I have yet to see frameworks offer routing coming in from the websocket connection itself because it also requires non-standard javascript to send the route requests through a parent websocket connection.

Which is why I was thinking that it's the way this framework was designed.

So, it's a web framework that receives route requests and sends responses over a WebSocket / Comet connection?

I've had a similar idea for something in Haskell and it's cool to see someone doing this.

Not wasting but you'll think you're a functional programmer, hit Haskell, then realize you were barely a functional programmer.

I used to feel as you did, until I started thinking more mathematically; the idea behind composition and clarity. Erlang has amazing properties but Haskell can, honestly, do much of it better and faster and safer.

Erlang has Dialyzer and type annotations and quickcheck. Use it all religiously because your Erlang programs will get big and messy fast.

What made me switch? STM > message passing actors, Haskell's type system is incredible, and the libraries / tools available are also pretty amazing. Programming in a way that encourages me to think mathematically is just so much more natural, personally.

Composition + a strong type system is an incredible experience. If you want more personal war stories we can do it over email?

I've built very large and performant Erlang software in production and very large and performant Haskell software in production for two of my own startups.

Someone told me this: with Haskell you end up reading a lot more up-front than you do "playing around" up-front. The reason for this is the type system which can feel like a straight jacket at first unless you understand it well.

Don't read the monad tutorials. At all. Get a feel for the language with http://learnyouahaskell.com/chapters (you don't need to read the whole thing through, but probably should).

Once you've played with the basics then you should absolutely read the http://www.haskell.org/haskellwiki/Typeclassopedia which gives you a very thoroughly walking through of the Type System and is essential but heavy reading to be at all productive with Haskell.

After that make sure you are using Hoogle to search for functions that already exist!!! http://www.haskell.org/hoogle/

One strategy no one really told me about: search for functions based on their type and less their "name".

Then after that, Gabriel Gonzalez writes some really great noob-intermediate friendly tutorials on Haskell in-general: http://www.haskellforall.com/ (don't start with his stuff though as you should have familiarity with Haskell basics first!!).

Once you're proficient, having Hoogle built into your command-line, using CTAGS + codex, Lambdabot + Emacs, and GHC-mod + emacs is pretty crucial to my workflow.

Hoogle in the commandline is really powerful, CTAGS + codex is basically CTAGS for haskell source files (if you don't know what ctags are look it up), and lambdabot is a powerful tool that is tough to explain but it's the omnipotent haskell bot sitting in the #haskell IRC channel (but you can install it on your machine and query it from Emacs).

I'll second FPComplete - a lot of people seem to glom really well onto their web-based IDE.

Hipchat runs smoother than XChat for you? That's a first.

Hipchat isn't bad but I vastly prefer IRC, particularly with a good IRC bot.

Yeah, if you ever get a chance to build something for production in Haskell / Scala / OCaml you'll realize how little even Go (which is better than Python and Ruby!) does for you.

The funny thing is, I believe (from real-world startup building experience) that Haskell has allowed me to iterate / prototype my products faster than I ever would have with Python and Erlang (my old go-to tools).

Also, with Haskell, there's no late-night and weekend fires to put out :) Which makes me more productive and generally happier.

[EDIT] To whomever is downvoting these legitimate comments, speak up why you think they are inappropriate for this discussion instead of downvoting.

I do not consider Go to have a strong type system. It's static though.

Strong typing allows you to do a lot and it also solves the problem we fallible humans bring to the table. Humans are pretty good at being creative but extremely terrible with details, remembering things, and keeping track of "hairballs".

Strong type systems solve pretty much all of that.

Now, with some of Haskell's newest features (like Type Holes) it's starting to make dynamic languages look more like children's toys because you get all the power and safety of a type system with the same "do what you want, it will (usually) tell you what you're intending to put there".

Dynamic programming came from a need for rapid iteration of a program because that's how humans work, we "start" then iterate till we have a more complex and functioning program. The problem with that model though, is that the burden of correctness is on us in the end.

Programming in Python is like leaving your dishes pile up in the sink for a week, then spending two hours doing dishes on Sunday.

Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it.

It's the difference between Eclipse and Emacs. Haskell actually encourages "internalization" of abstractions through terser syntax.

Emacs is like that, you internalize the editor which makes you 5x more productive than you are with an editor that externalizes the abstraction requiring your brain to use another layer of translation (the visual one).

If you learn Haskell, you'll find it quite enjoyable (I do now). The way I think in that language is so much more abstract and precise than it ever was in Python / Scheme / Erlang / Ruby / Javascript.

[EDIT] To whomever is downvoting these legitimate comments, speak up why you think they are inappropriate for this discussion instead of downvoting.

I'm undoubtedly a Haskell convert (from Erlang / Scheme / Python) with little experience in Go.

The investment is pretty big, yes, but I also believe it is great from a commercial perspective because it really improves the result for End-Goal-Programming (end goal is to serve business needs, not technology for technology's sake):

    1. Time to market for a product
    2. Easy / clean refactoring
    3. Massive scale code base management
    4. Program longevity and maintainability

It also produces cleaner and less buggy product for the end-user. Which is so important!!! Particularly as a startup.

2) If you need to cleanup some technical debt from taking short-cuts or not accurately pre-planning architecture, Haskell's type system makes it so friggin' easy your eyes will bleed when you try to do the same in a Python / Ruby / Erlang program.

Additionally, it really allows you to respond to the market better too! If you have to pivot your product it's not "Oh shit, now we're going to have to take that duct taped sewage monster and turn it into a duct taped ninja turtle." it's "Hmmm, well, let's think through the new types a little bit and re-shape some of this code, I know the compiler will tell me when I'm being a silly human."

3. Python and Ruby aren't really appropriate for large scale code bases because dynamic typing means you need an equally massive amount of tests to ensure no one else in the org fucks shit up. It makes team based programming on the same codebase far more manageable!!

4. Once I've built my Haskell programs and wrote a few minor property tests with QuickCheck, they usually run forever. I've rarely ever had a case where I would get unexpected crashes (usually from my not understanding Haskell's laziness earlier on in my Haskell career).

Long-term maintainability is massive factor here too; it's so much easier to figure out what the damn thing and all of its constituent pieces do with the type system!!! It's like having an index and a table of contents for a book. Since most programmers forget their own code anyway (comes back to that fallible human thing), having a neat and correct abstract description of your program and its parts is invaluable to a commercial enterprise.

So, in short, I actually think Haskell is the best language a commercial enterprise could choose. All you need too is one really good programmer that can mentor, then train them as you go; the good news with Haskell is even when you write shitty Haskell code (un-idiomatic, mostly in the IO monad, and barring space leaks), it's usually better than even the good Python and Ruby code those people would be writing.

Awesome change, results are much improved too, using it as my default.

I know this is an answer most people don't want to hear, but why not build your own Ansible / provisioning workflow and use that to do everything these services do?

I have one built in Ansible for our Python webapp and the entire configuration is encoded in the playbooks, rolling up the application into a source distribution, pip installing it, and also installing the dependencies...

Very easy, dependable, and extremely flexible.

This is a case of "priming" the consumer, in some cases you don't need to prime them but those low-hanging fruit are rarely not served already and it's usually juicier and only slightly more time consuming to drive your nail in that "middle somewhere" spot that some businesses get lazy about addressing.

So, for myself as a generalization, I'm writing it down as prime your target with something accessible (free knowledge, free feature-set, etc...) and engage them early in the funnel so you can iterate the lead-gen and the resulting product early.

Lol at the downvoters. I'm sure you can build a lifestyle business around a CMS that spits out a static site but honestly, unless your audience is Hacker News, people don't care whether it's static or dynamic and often times they'll ask for that one thing that isn't static and breaks your ability to sell to them.

So yes, this is a feature and not a product as evinced by the numerous plugins and projects that take existing dynamic web application software and can produce static sites (Flask Freeze, Drupal's plugin, I think even WordPress has one).

[EDIT] Which means, what's to stop the existing "site builder" companies from doing the same? They don't sell the feature (static builder from a dynamic site), they sell the product (build yourself a site), and people buy it. The "background benefit" is a slightly faster site and who does that really matter to? Not the customer. The service - reduction of bandwidth and server resources; the could easily introduce the feature, cut resources, and keep the margin.

Here's the deal though, because I've wrestled with this myself and after being a founder of three startups this is my conclusion: being a good hacker is not enough - who ultimately is the recipient of a hacker's output? Always the human.

There are so many facets to this argument I won't attempt to cover them in this comment but people with solid social skills are not only easier and more pleasant to hire but are also better hires in many ways due to organizational social cohesion and the fact that the "hacker" may have a better understanding of the customer or recipient.

That's what I don't buy about his Xah Lee's argument that he's terrible at it - if he's written tutorial material that people find useful, he's more socially capable than he thinks. My suspicion is that his drop-out and autodidactic arc are social inhibitors for him; I think he lacks self-esteem due to it (no matter how well self-educated you are). I know that all too well because I wrestle with it myself as a highschool dropout and self-studied person.