Obama's job aid plan - $10,000 to $13,000 in assistance for entrepreneurship - <AUTHOR> http://moneyland.time.com/2011/09/12/the-most-overlooked-and-important-proposal-in-obamas-jobs-plan/ <comment><USER2> Whoa, the article is ageist, and proud of it.

 _Though this program is geared toward people of all ages, young people are the best suited to maximize its advantages. Older generations tend to have families and other financial obligations, making it more difficult for them to transition into the roles of entrepreneurs._

I am married with a young child, and my salary covers all of my family's expenses, so my husband doesn't have the pressure to get cashflow-positive out of the gate. Contrast that with my younger, single self, when I burned through the start-up capital in a matter of months and had to take consulting gigs just to stay afloat on office expenses.

 _Young people can more easily adapt to less expensive lifestyles._

Young people care a lot more about what others think, the very foundation of "expensive lifestyles".

 _Further, young people have access to a wide range of resources, such as Income Based Repayment (IBR), SCORE, Startup America, [...]_

IBR is a student loan repayment program, nothing to do with entrepreneurship. SCORE is open to all small businesses (and a waste of time, in my experience). Startup America targets young _companies_ , not young people. And so on...

<comment><USER3> > Young people care a lot more about what others think, the very foundation of > "expensive lifestyles".

Speaking of ageist ...

<comment><USER4> Young people tend to be single, which means they have a lot more at stake in terms of public image than married people do.

</comment></comment></comment><comment><USER5> 1\. I run a business. Therefore I make jobs. Or don't.

2\. If I fire an employee, a portion of the cost of that person's unemployment claims is charged back to me. The employer. It isn't government largesse that funds unemployment claims. It's me.

3\. Will this program be yet another potential cost to me? Hard to tell from the PR and press-gab. We'll have to see the law and how it is implemented. Devil in the details, etc.

4\. My payroll is suddenly $100K/year lighter than it was. Am I going to replace that guy with another full-timer? Fuck, no. Hello, independent contractors.

5\. By the way. I pay 100% of the medical costs for all my employees.

<comment><USER6> "2. If I fire an employee, a portion of the cost of that person's unemployment claims is charged back to me."

Can you elaborate on this? It's something I've long heard and failed to grok. How can an employer, as normal business practice, have to still pay a fired employee any amount?

<comment><USER7> You have to pay for unemployment insurance. The more people who make claims against you, the higher your insurance gets. You probably aren't going to get charged 100% of the employee's unemployment, but you get charged a goodly chunk.

<comment><USER8> Seriously? I'm surprised anyone is still hiring _at all_ in the US! Sheesh, what a policy. "Hello independent contractors" -- I hear you.

<comment><USER9> The IRS is very picky about what constitutes an independent contractor. This has long been abused by companies trying to skirt employment law and avoid payroll taxes. They have a litmus test of sorts to determine whether someone is an employee or an independent contractor (tl;dr: if you treat them like an employee, they're an employee). And of course, there are significant penalties for getting this classification wrong.

For more details, go to the source: [http://www.irs.gov/businesses/small/article/0,,id=99921,00.h...](http://www.irs.gov/businesses/small/article/0,,id=99921,00.html)

<comment><USER10> My lawyer (a tax attorney) said this is rarely prosecuted on independent contractors who are themselves incorporated (along with things like actually have a contract etc). From my own experience this is true as well. Think about it, the IRS would have to give back all of the matching that the contractor (agent) did when they collect from the employer (principal).

Edit: talk to your own attorney though.

</comment></comment></comment></comment></comment></comment><comment><USER11> I like the spin on this. Sounds like something that could be very useful.

I must note, however, some phrases that set off my bullshit detector.

>SEA participants were 19 times more likely than eligible non-participants to be self-employed

Either I'm missing something or this says that people who are in a self- employed assistance plan are likely to be self-employed. Perhaps this is an editing error?

>In Oregon, nearly half of the successful SEA entrepreneurs have each created an average of 2.63 new jobs

Ok, but what kind of filter does "successful SEA entrepreneurs" imply? 1 in 100? 20%? Once again, the language is loose and circular.

Money is not an answer to everything. In fact, funding at high levels can be the worst thing ever to happen to a good team in a startup. At small levels, like this, it perhaps can make a big difference. Perhaps.

There is a great big giant humongous gap between something that sounds good in an editorial and something that actually does something useful. I'd want a lot more data on this before passing judgment one way or another.

<comment><USER12> _There is a great big giant humongous gap between something that sounds good in an editorial and something that actually does something useful_

I am reminded of "politician's logic" from _Yes Minister_.

1\. Something must be done.

2\. This is something.

3\. Therefore, we must do this.

</comment></comment><comment><USER13> The ignorance displayed in the comments on that article is scary. It's quite obvious a lot of people have never been in the position to actually need this sort of aid before, so it's easy to knock everyone using it as "an illegal" or "lazy."

Of course people will abuse this, too, just like they abuse the unemployment insurance we have now. But to me, the net positives that come out of this will outweigh the (probably minor) fraud that will happen. Adding benchmarks (e.g., you have to legally register a business, you have to prove some sort of business activity to a case worker, and so on) will keep a lot of the fraud out, even if they're token requirements.

<comment><USER14> First, who said "an illegal" or "lazy"? Searching the page I only find your comment using those terms.

Second, "the system is already being abused so lets allow further abuse" isn't really a great argument.

(For the record I'm actually in favor of this I just don't think your tone is necessary and I think it discourages anyone who might disagree)

<comment><USER15> 1\. Read the comments on the actual article, not HN.

2\. Unless you have another ingenious way to make unemployment money more efficient, I see it as a fairly decent argument.

</comment></comment></comment><comment><AUTHOR> To me the true significance, more so than this money, is the milestone of the federal gov't finally recognizing "entrepreneur" as a third category of employment status and not just the unemployed/employed binary.

Hopefully this leads to further help for folks starting a company (that will in-turn create more jobs when successful) like healthcare coverage.

EDIT: This will also help with mainstream cultural and social acceptance. Less weird looks when explaining to Joe Shmoe your employment situation!

<comment><USER8> It will also help massively to "massage" unemployment figures in a positive spin by reclassifying a million or two of them as "entrepreneurs". (And hey, the debt ceiling can be raised indefinitely so no problem re costs. We finally arrived in The Future: the perpetuum mobile exists.)

</comment></comment><comment><USER16> About time.

The policy of forcing a decision for laid off people between 1) sitting around doing nothing (i.e. "looking for a job") and being eligible for free money vs. 2) trying to start something which could have an an impact in not only getting that person back into a paying position but also on the economy as a whole (and thereby being ineligible for money) needed to end

<comment><USER17> > The policy of forcing a decision for laid off people between 1) sitting > around doing nothing (i.e. "looking for a job") and being eligible for free > money vs. 2) trying to start something

There was no such policy - there was no such "decision".

The standards for "looking for a job" are/were low enough that one could be trying to start something at the same time. (I know - that's what I did.)

While we like to talk about starting companies, ie we like startup porn, the vast majority of the long term unemployed won't start anything. More to the point, the folks who would are unaffected by this proposal, so there won't be any benefits received for the costs incurred.

How do I know this? The folks who would start do start and are doing so already. (Yes, I read the SEA stats.)

<comment><USER18> There is such a policy, at least in New York State. Any time spent on "self- employment" activities reduces the amount of unemployment insurance money you receive.

<comment><USER19> all activities, or activities with associated revenue streams?

<comment><USER20> There are precedents for it being _all activities_. Particularly anything you're doing that would be in line with your usual profession, whether you're getting paid for it or not.

The rules vary by state, though.

<comment><USER21> So a laid off programmer could be penalized for working on an open source project to keep their skills current? Incredibly idiotic if true, but it wouldn't be the first time we've created screwed up incentives for the lower end of the income scale. I'm becoming more and more convinced that we should replace most of the welfare bureaucracy with a negative income tax.

<comment><USER20> Potentially, yes. In the case law I remember, exceptions were explicitly carved out for "hobbies", so if you can show that it's something you usually do as a hobby and that it's not interfering with your job search, you can probably avoid penalties, but I could see it being a major pain in the ass.

In reality, enforcement of UI regulations is somewhat spotty, and at least in California, a tech worker who's only on it for 2-3 months is unlikely to have any trouble. The risk isn't nonexistent, though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> _In essence, the president's plan will create a guaranteed source of startup capital..._

Is that necessarily a good thing? I was under the impression the whole "trial- by-fire" of a business plan looking for funding was a valuable testing grounds for the business-to-be.

<comment><USER23> Well you still get to do that when your $10,000 runs out.

<comment><USER12> At which point you've already wasted $10,000 of someone else's money.

There's also the good ol' sunk cost fallacy. The longer you've spent working on your dumb business plan, the less likely you are to change it to a smart business plan.

</comment></comment></comment><comment><USER24> Then, if you become successful, you can be labeled as one of the hated rich and they'll put you out of business with crushing regulation and taxes.

Excellent.

<comment><USER25> "Crushing regulation and taxes" generally hits small businesses hardest.

<comment><USER24> According to descriptions of what "rich" seems to mean to most, small businesses are the largest part of that heavily disliked group.

In the recent English riots the prevailing thought seemed to be that simply owning a business meant you were rich.

<comment><USER25> It's hard to imagine this being the case. When I think of "has way too much money" I think of big corporate fat cats. Never small business owners. I don't know anyone personally who sees small business as hated rich either.

Perhaps this is some kind of cultural thing in the UK?

</comment></comment></comment></comment><comment><USER26> genius. who needs voluntary transactions live venture capital or angels, what have they ever done? instead lets take money from everyone (if they don't like it we can lock them in a cage) and then give it to others who we decide are worthy.

<comment><USER27> Other option for people who don't like it: leave the country.

You wouldn't know it listening to most people complaining but unemployment insurance was not something implemented in 2008, it goes back to the 1930s. That should have been plenty of warning for you to find a place with a tax rate and entitlement system to your liking. Sorry, there aren't a lot of options in the 1st world without taxes and entitlments, but that must just be a coincidence.

<comment><USER28> I'm conflicted on the idea of leaving the country as a solution. Its not enough to simply live and work in another country -- you're still liable for taxes. You have to fully expatriate and renounce your citizenship. This is often very difficult and time-consuming to do, and near-impossible if you're not in a skilled line of work.

<comment><USER29> I'm still a Canadian citizen, but because I don't live in Canada, don't have assets in Canada, and don't earn income in Canada, I don't pay taxes in Canada.

As far as I know, being taxed on worldwide income is just an American thing.

<comment><USER30> It is just an American thing. And it's a great example of why "if you don't like it, leave it" is bullshit _particularly_ when spoken in the context of American politics.

<comment><USER31> If you don't like it, leave it and then renounce your citizenship.

<comment><USER30> Clearly you have not been paying attention.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> This seems really cool and all, but what are we talking about in terms of wait time and hurdles to jump through? Anyone know details?

I've looked into and seen others go through grant processes and they are often terrible. Hope it isn't similar.

<comment><USER33> This isn't a grant. It's a modification of the rules for unemployment insurance. It's a good change.

It allows you to use unemployment insurance to pursue your own business for about half a year. Of course, for you to be eligible for unemployment insurance, you had to have been employed at some point and gotten fired. It's also a paltry sum. But, again, any movement in the right direction is a plus.

<comment><USER34> Strange question, but couldn't you always do this?

From my understanding, unemployment insurance only required that you take no/low salary from a company. You were still able to receive money from capital-gains/investments.

Start a consulting firm/startup, pay yourself a $1 salary with stock options. Don't exercise these options for a long time (when you stop UE). I read the UE stuff time and time again in Massachusetts and kept looking for something to say that I couldn't do this but couldn't find anything that said so explicitly. I didn't end up doing consulting (just more learning/studying), but it would have worked and been legal right?

<comment><USER33> > Strange question, but couldn't you always do this?

No. For you to receive unemployment insurance you must prove that you are actively seeking a job.

I suppose you could have invested the time into looking for a job while spending the rest of it starting a business, but this will provide you with an _explicit_ option to start your own business. That will encourage more people to do so.

<comment><USER34> Right. Let's say I was searching for a job, but doing Rails work on the side (not a startup per-se, but you know... doing startupy like work). I could spent 1 day per week looking for a job, and 4 to 6 days a week coding for people. All the proceeds go into a consulting firm which I hold ownership of.

But yes, it is good for this to be official now.

<comment><USER35> If you do this you are probably violating the unemployment rules in your state[1]. If you reported this income with the unemployment office you will most likely have your benefits reduced or eliminated. But most people don't report this income and get away with "double dipping" which was heretofore not allowed. Technically if the government found out you did this they could penalize you retroactively. But this is a hassle and most people just get away with it unnoticed.

Even more technically, some states will even deny unemployment benefits if you are working without pay such as in a startup situation (and you are honest enough to admit this). It's not about income or full utilization, it's are you working at all.

The change in the law makes getting paid for self employment legal. Although if your self employment included revenue I assume it would still count against the amount you received from unemployment, again depending on your state.

[1] [http://career-advice.monster.com/salary-benefits/benefits- in...](http://career-advice.monster.com/salary-benefits/benefits- information/unemployment-benefits-part-time-work/article.aspx)

</comment></comment></comment></comment></comment></comment><comment><USER36> This article does not mention that in order to qualify for unemployment insurance you have to have worked for a certain period of time and then been laid off.

This program will not help a college graduate (or dropout) that wants to start a business right away.

It's a great program, but unemployment should be expanded to include people who are first time entrepreneurs that have never had a job and been laid off.

</comment><comment><USER37> Seems like there are some states that have this program in place- Delaware, Maine, Maryland, New Jersey, New York, Oregon and Pennsylvania.

<http://workforcesecurity.doleta.gov/unemploy/self.asp>

Unfortunately, not California

</comment><comment><USER38> incidentally this has been done in Australia under the auspices of NEIS apparently over the past 20 years (link to monthly success story here: <http://www.nna.asn.au/success-stories> )

On top of it, there is a layer of mentoring as well:

      To be eligible for the NEIS Small Business Course,
      you must be in receipt of a Benefit and must have a   Jobseeker ID Number.

[http://www.becnorthside.com.au/index.php?option=com_content&...](http://www.becnorthside.com.au/index.php?option=com_content&view=article&id=60&Itemid=68)

</comment><comment><USER39> Is this just PR releases or is the full text of the bill out? After the pre- press on the health care bill versus actually reading the thing, I really want to see the actual text (and the follow-up rule making).

<comment><USER40> The bill's been sent to congress this morning, if you can't find it on their website yet, you'll be able to soon. (Haven't gone looking myself).

<comment><USER39> isn't there yet - hope they put it up sometime tonight

<comment><USER39> here is a link: [http://www.whitehouse.gov/the-press- office/2011/09/12/messag...](http://www.whitehouse.gov/the-press- office/2011/09/12/message-president-congress-sectional-analysis-and-text- american-jobs-act)

</comment></comment></comment></comment><comment><USER41> Who cares about these proposals? They might be good ideas but the Republican House is never going to pass this.

</comment><comment><USER42> I found the link for a list of unrelated things 2 paragraphs in quite jarring.

</comment><comment><USER43> Starting a tech company is so cheap that funding should never be the bottleneck. If your idea is too expensive to start with a laptop and cheap hosting, think of another idea.

<comment><USER22> I rue the day when "tech company" came to equal "software company"... there are so many other kinds of tech, too.

<comment><USER44> Web software at that. HNot to pile on (I saw the comment below about sloppy wording), but there are a lot of other business models besides 'online service that does one thing really well'. If you want to create the next Photoshop or Excel, for example, you need to deliver a lot of functionality right from the get-go, which will take longer to build.

</comment></comment></comment><comment><USER45> where the hell is the TLDR?

i just want a place to submit an idea and prototypes and get cash ....

</comment><comment><USER46> US need a win-win proposition with Chindia

<comment><USER47> I know this is getting downmodded, but hes somewhat right.

"Chindia" is draining our economy, by "draining our economy", I mean its destroying the people who actually do the work.

For every job that is sent overseas, not only does it result in someone, an actual real person, losing their job, but a form of slave labor in a foreign country "hires" the replacement.

If I was President, honestly, I would push for a 0.5% tariff on all goods and services from countries that are not considered first world countries.

I may be unable to improve the conditions of slave laborers in foreign countries (especially China and India due to massively corrupt governments that are doing everything possible to widen the gap between the poor and the rich instead of closing it), but I don't have to support doing business with those who make this possible.

0.5% would result in hundreds of millions of dollars in recaptured revenue, which could be instead spent on trying to preserve jobs in the US instead of exporting them, but it would also be low enough that the consumer would not bear the brunt of this.

<comment><USER48> >If I was President, honestly, I would push for a 0.5% tariff on all goods and services from countries that are not considered first world countries.

An alternate statement of that idea (which I'm not sure I agree with either), is a tariff on goods and service in the amounts required to bring the hourly foreign labor costs up to the US federal minimum wage with no exemptions.

<comment><USER47> I was actually considering something similar. Instead, define "first world country" as a county who's median yearly pay is at least half of hours, recognizes basic human rights, recognizes democratic voting, and doesn't punish their population for speaking out against the government or any government sponsored religion (such as the Muslim religion in various middle eastern countries), and also recognizes the rights of women.

As in, fellow countries that believe in life, liberty, and the pursuit of happiness.

Attempting to tariff any harder can have extremely adverse effects. The rich wish to remain rich at all costs.</comment></comment></comment></comment>


Building DistributedLog: Twitter's high-performance replicated log service - <AUTHOR> https://blog.twitter.com/2015/building-distributedlog-twitter-s-high-performance-replicated-log-service <comment><USER2> This work seems to be pretty interesting. It turns to me that I/O isolation, durability and consensus are the top 3 concerns that leading to choose BookKeeper as the storage backend. It also mentions about Kafka, raft/paxos. It would be nice that those engineers could dump more details (architecture, performance considerations) comparing to Kafka, and maybe raft/paxos too.</comment>


Show HN: String diff online tool - <AUTHOR> http://stringdiff.com/ <comment><AUTHOR> Made it because I sometimes need to diff strings and I never remember how to do it from command line. And partially as an experiment of how important the url is to get traffic.

</comment><comment><AUTHOR> Any tip on how I should host this site as cheap as possible? It's just html,css,javascript

<comment><USER2> If you're checking your code into GitHub anyway, you could turn on GitHub Pages [1] for your project and serve it from there.

[1] [https://help.github.com/articles/configuring-a-publishing- so...](https://help.github.com/articles/configuring-a-publishing-source-for- github-pages/#enabling-github-pages-to-publish-your-site-from-master-or-gh- pages)</comment></comment>


Ask HN: How can I get my co-founder to stop coding? - <AUTHOR> I run a small startup with my co-founder.
Things are going pretty well, I built the product myself and my co-founder has found a customer and sold it to them. We haven't taken any loans, accepted any funding or given away any equity.
We are currently preparing to launch in the new year.
My co-founder has some experience coding, and sometimes takes it upon himself to dive in the code and make changes.
This causes a couple of problems:
* He doesn't understand the stack well, and has introduced bugs
* We have lost potential opportunities because he has told customers that the product doesn't have features it actually does. When asked why, he will say things like I didn't see it in the code
* He has a tendency to take out his laptop when meeting potential customers, bring up the codebase, and try to talk them through it
On the plus side, he has found us our first customer, and I have no doubt that he can find more (he's very salesy, and well connected) but I really need him to step away from the code!
I'm just not sure how to raise this with him without damaging the relationship. Any advice, HN? <comment><USER2> Instead of pointing out what is wrong with him, you could highlight his strengths - sales and ask him to build on that. You could tell him that it'd be beneficial for your startup if you both concentrate on each of your strengths. You - the technical aspect and your co-founder finds ways to bring in mullah.

You must have a sit down and make sure you are both on the same page with respect to the capabilities of the product. If you don't have relevant documentation for the product you've built, perhaps he can work on that. This way he would understand the product inside out and at the same time have some material when presenting to prospective clients. Going through the codebase with clients is a big nono. Alternatively, you could ask him to prepare a demo of the product that he can use when presenting to prospective clients.

Congrats on building a product and selling it without taking loans and giving away equity! Great going

<comment><USER3> "I can hire someone else to help with the code. I'm not sure I can hire someone else who can sell as well as you can."

</comment></comment><comment><USER4> There is probably something else here that you need to talk to him about.

Why does he feel the need to code up a feature _right now_ , without talking to you about it?

Why is he having trouble keeping everything about the product in his head, with looking in the code as the only fallback?

Why sort of gaps are there in the demo that looking at the code is the best way to address it?

This is not a problem with him, though it's also not a problem with you. It's a problem with the business where the founder who talks to customers feels he has to come back and bang out features. Worst case, he's just bad at his job, but the likely reason for this is that there's a mismatch between you two in terms of stability, urgency, or prioritization.

You're adults. Talk it out.

</comment><comment><USER5> The hell is he taking out the code to explain it to customers? Are you sure he's "salsey"?

<comment><USER6> I second this, it sounds cringey on the face of it. Maybe it works for non- technical customers, but I imagine technical customers would immediately be taken aback.

The only exceptions might be cases where very specific behaviors or implementation details are in question.

<comment><AUTHOR> My main issue here is that we have a technical product, and the people we are selling to are developers.

If they could build it themselves, they wouldn't be talking to us, but my co- founder doesn't seem to get this.

It reminds me of this Silicon Valley scene - [https://www.youtube.com/watch?v=JlwwVuSUUfc](https://www.youtube.com/watch?v=JlwwVuSUUfc)

<comment><USER5> Hmmm...The evidence is: he's made one sale. Any person can talk the talk. He's clearly doing things a salesperson shouldn't be. You, a non-salesperson know this. But perhaps he will shine through when the product is released. But to iterate, thus far, he has made one sale, that doesn't make you a salesperson. Yet.

He may be showing people the code because he's proud of it...

Speak to him.

</comment></comment></comment></comment><comment><USER7> Require that a person besides the author has to review code changes before they are allowed into a code base. Do it under the guise of 'transparency' or 'being on the same page'. Don't let him see your post.

</comment><comment><USER8> We had problems similar to this, but we were all technical and we were all opinionated about the ways we code. We solved it by having a code review process. Setting up a review board ([https://www.reviewboard.org](https://www.reviewboard.org)) is a good start. To create code co-ownership and keeping all the people on the same page, code review helps you communicate better, and get familiar with the code base. You, as the more technical one, can ask your co-founder to review your code as well.

</comment><comment><USER9> If he is smart enough to code, spend an hour with him walking through each folder of the source code and then draw a diagram of your stack and also walk him through it. He can use the drawing to walk your clients through so it is prettier than the code. So, you have to go to "sales side" and put yourself in his position and then help him there (maybe even pretend to be a client by role-playing) so you can see what he is trying to do. I'm assuming showing code is not the end goal but something else.

</comment><comment><USER10> Here's an important thing to think about, and to find a way to address in your team, on an individual and interpersonal level.

Founders/leaders have a far greater chance of success if they have the ability to be completely honest with themselves, and teams have a far greater chance of success if they can be completely honest with each other.

I can't find any links to specific excerpts now, but it's worth reading Ben Horowitz's "The Hard Thing About Hard Things" for insights about this alone; about the degree to which he and Marc Andreessen have an honest relationship with one another, and about how much value they place on self-honesty in the founders they back.

The thing is, it's very rare and very slow and difficult to accomplish.

Most of us have some ego fragility, and find it very hard to confront the truth about ourselves, and for that reason most of us generally avoid making fully honest comments to our friends, colleagues, partners, etc, until things get to breaking point, by which time it's often too late.

But it can be accomplished with a lot of commitment and personal development work over a long enough period of time (different methods work for different people, but practices that focus on ego detachment are the right approach), and if/when you can do it, you should see power-law improvements in your outcomes.

</comment><comment><USER11> It sounds like what you really have is a code management process problem. Remove him from commit access the repo, force him to submit PRs, review his PRs, provide feedback so he gets better but can't break things. Tell him this is "best practices" which is basically is. You could also take a less draconian approach and tell him that PRs and code reviews are required before merging. If he doesn't do that, then you can remove his commit access.

<comment><USER12> This would work (albeit in a demoralizing way) in corporate America. I don't think it's going to work when his cofounder also owns the code base and the OP doesn't really have a right to restrict him. This is a communication problem, not a technology one.

</comment></comment><comment><USER13> Get a copy of the book "Getting to Yes." It's a quick read and should help you figure out how to approach him.

My guess is that since he is "salesy," he is the kind of person who values social capital and he thinks the way to get your respect is to prove he is good at code. One of the takeaways from negotiating studies is that value lies in your differences. If you were both good at the same thing, you wouldn't really need him as a cofounder.

So, maybe get better at praising him for the things he is good at and making him feel like you are awed by the things he can do that you can't.

Also, you need to make sure he understands the product better. His lack of understanding of the product is a serious issue, even if you can get him to stay out of the code base.

Do try to approach this diplomatically, but also recognize that this is a make or break moment. Either the two of you will hash this out and your ability to communicate and your trust in each other will grow, making the company better in every way, or it will break you two up. And it is better to lose him early so you can go find someone else than to keep this limping along out of fear that any confrontation will be a dealbreaker.

Cofounders need to be able to hash things out in a serious way. This is one of the reasons it gets compared a lot to marriage. If you can't "fight it out" so to speak and come up with a real solution, the two of you do not have what it takes to grow a company together. (You should try hard to not be too fighty about this, but you also need to make sure you aren't erring on the side of being too much of a conflict avoider. That is actually worse.)

<comment><AUTHOR> Will check out that book, thanks

</comment></comment><comment><USER14> A thing about long lasting relations is, both parties are comfortable discussing anything under the sun. So you must open up a channel around this and express your concerns.

In my first startup , my cofounder was interested in design and would spend needless amount of time on it while his core job was to go out and sell. Honestly I couldn't get my thoughts across to him and left the startup. Probably a noob move now I think about it.

Have a discussion about mutual exclusivity to get most done as a team. Tell him you believe in MECE and what his thoughts are about it.

Also sometimes you can be more accepting to his coding interest and let him do a few stuff. But you must remain gate keeper for the final version of product. Have processes setup for this. You could mention that you are not comfortable having more than one person handling releases.

I have learned from my experience that it's important to have most difficult discussion early on with your cofounder.

</comment><comment><USER15> I think you need to be honest. Do a 'shit sandwich': complement, air grievances, complement again. ex.`

Hey, I think you scoring our first customer is probably the most important thing either of us has done, and I'm really excited about sales starting to roll in. I know that I'm not very good at that kind of thing, and so I should focus on the codebase. Because you're much more effective at it than me, I wonder if you should allocate a higher proportion of your time into sales and business development.

As a two-person company, we need to be as smart as possible with our most limited resource: time. I appreciate that you're making an effort to contribute to our codebase, but I have a few small concerns:

\- Your commits have introduced a number of bugs. It takes me twice+ as long to fix a bug you wrote than one I did because I need to understand what you did. I think we both agree that we want to make sure that X and Y features are done as soon as possible, so please be very cautious about committing any code that could introduce bugs that will block progress. Once we get better unit testing, it will be easier for you to contribute code more safely, so lets think about improving testing after X and Y.

\- It was disappointing that we didn't land Z customer because of an internal communication failure on what features had been implemented. I think we need some documentation about what the product is capable of. If you could take this on, that'd be awesome. I'll try to do better at communicating what I've implemented with changelists or 'new feature' emails.

\- I know you like to show customers the codebase when walking them through the product. I'm worried this is too technical, and perhaps documentation or a pared down marketing 'fact-sheet', or 'user stories', or something like that could be a more effective visual aid for these meetings.

I really appreciate your spirit and effort in everything we've built together. Your code has been helpful, but we have _SO_ much to do that isn't purely code that I think we should 'divide and conquer' for the next few months: I'll try to finish X and Y features, and you get another couple of customers. I think if we accomplish that, our company would be in a really strong position.

What do you think?`

Make it clear that his bugs are introducing operational costs, and that you want to mitigate that cost.

Don't use the 'stick' to keep him away from the code, but rather dangle 'carrots' in all of the other parts of the business that need work.

<comment><AUTHOR> Great advice!

</comment></comment><comment><USER12> Bring it up as a discussion topic, not a criticism. Ask how showing code to clients is beneficial if they don't understand or care, but in a more diplomatic way.

You could also ask him to develop in branches and give you time to look at it before pulling into master so you can get up to speed on changes and help catch any bugs. Offer to do the same yourself in reverse.

It also sounds like as the developer, you need to better at communicating what you're building and what it features. If your cofounder isn't even sure what all it does, you can be sure your customers don't.

</comment><comment><USER16> You guys need to sit down and have an honest talk. Just don't tell him you slept with his wife.

</comment><comment><USER17> Cut off his access to version control and set him up with one on a "fake" vc. Demand he make big changes to the underlying structure and give him a unrealistic deadline. Constantly ask him if it is complete, and when he says no, ask why. Then task him with even bigger changes with tighter time frames.

He should tap out within a couple of weeks and resort to selling.

Problem solved.

</comment><comment><USER18> Talk more. You guys should both be giving honest feedback to each other. Figure out how you can do more of that in a way that strengthens the relationship, by communicating both respect (you clearly believe he can be valuable in areas other than coding) and your needs (you think the company would benefit more from him focusing on testing the value proposition and growing sales than on directly implementing features).

</comment><comment><USER19> There's a lot here...

* He doesn't understand the stack well... If you can't get him to stop coding, Get him on source control and branching, but do peer reviews into master, by which I guess I mean keep that power for yourself, or, if that's contentious, keep a separate branch for yourself, and if you see bugs discuss them with your partner. Dialogue is the way to help here, unless he's willing to defer to your expertise, but good code management and practices will help, and keep him engaged. If he's set on it, he may as well contribute properly.

* Re: not seeing features in the code This is an odd one. What is the proper way for you all to discuss features? If you're not both power users or both completely familiar with the code base then how should he know about a particular feature? Is your documentation air tight? Probably best to agree to a stick-to-it answer, if he doesn't know or thinks a feature doesn't exist... this is true for all salespeople who, as you grow, will grow increasingly unaware of features. Something like "let me take that back to our developers -- if we don't have something that precisely does what you want, we can add it as a feature request" or even "they're constantly adding capability and I may have even missed it in our latest version" or any variation. Again, discuss it, though.

*re: taking out his laptop... If he's the sales guy, and this helps him sell it, then I don't see the problem. If this is costing you sales, and you're sure that's the reason, then that's a different discussion. While this isn't an approach I'd take, I'm not "salesy". Again, discussion is your best option, but if you're asking him to stay in his swim lane, then consider whether or not this is wading into his. Better you're both on the same page, I agree -- if the issue is letting clients see trade secrets then, as before, agree with your partner on a party line: "if we can get an NDA in place, maybe a developer and I can sit and walk you through the code if you have a question about a particular piece, if that will help make the sale".

re: damaging the relationship.... just talk to him about it. Raise concerns -- point out bugs and use that to justify asking him to be more diligent, or pass code by you; point out lost sales and discuss what you think may improve. Approach it as a collaborative effort to solve problems, and hopefully he will take it well.

<comment><AUTHOR> > Re: not seeing features in the code

The issue here is that we will discuss this in advance, I will say _Yes we have this feature_ and then afterwards he will tell me that he told the prospect that we don't, because he couldn't see it in the code.

> re: taking out his laptop

The problem I have with this is that we have quite a technical product, and are selling it to other developers. If they could build this themselves, then they wouldn't be buying it off us, so I don't want them poking around our code in a sales meeting! It reminds me too much of this Silicon Valley scene - [https://www.youtube.com/watch?v=JlwwVuSUUfc](https://www.youtube.com/watch?v=JlwwVuSUUfc)

Thankyou for the advice, much appreciated.

</comment></comment><comment><USER20> If a founder and a co-founder can't communicate with each other and agree on goals and processes, you will not succeed.

You need make sure you're both on the same page. One way to do this is for you to list out the features in a presentation or deck. He can "sell" from that, not the code.

</comment><comment><USER21> Make official titles today complete with business cards. You are CTO and VP of Product Management. He is VP of Sales. Communicate and agree upon these roles clearly.

</comment><comment><USER22> The problem may be you. He closed the first customer.

</comment><comment><USER23> Real question, how is he able to introduce new code with bugs in it? How do you know the bugs weren't yours and they were waiting to be awakened?

</comment><comment><USER24> WTF?!? What kind of co-founder is this where you can't sit down and have a honest talk? You two should be able to tell each other this kind of things directly in the eye, without thinking about it twice. Just imagine when you start having real problems o.O

<comment><USER25> Second this. Advice: if you don't have the ability to tell your co-founder exactly what you just wrote here then you're in for a very stressful time ahead.

</comment></comment><comment><USER26> Talk to him, not HN.</comment>


What color is the dress – demographic collection - <AUTHOR> http://digitalorchard.co/dress/survey.html

<comment><USER2> I already proved it using computer vision that it's not black and blue :)

Stop this madness!

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

<comment><USER3> [http://www.wired.com/2015/02/science-one-agrees-color- dress/](http://www.wired.com/2015/02/science-one-agrees-color-dress/)

</comment></comment><comment><USER4> I see light blue and gold.</comment>


W3Fools – A W3Schools Intervention - <AUTHOR> http://www.w3fools.com/ <comment><USER2> This has been posted many times. And each time, I never truly understand what's wrong with w3schools. I used it when I was much younger (although I've switched to MDN now) and I haven't found very much wrong with it. Can someone please enlighten me?

<comment><USER3> It seems that W3Fools has changed recently since it was popularized in 2011, but the page used to have a very lengthy list about the recommended bad practices or flat out inaccuracies of W3Schools.</comment></comment>


Work Doesn't Happen at the Computer - <AUTHOR> https://thefocuscourse.com/work-doesnt-happen-at-the-computer/ <comment><USER2> Of course work DOES happen at the computer -- a lot of it. I've always been a bit annoyed with hyperbole.

That being said, I liked this article; it has some good, practical ideas for ensuring that your day will be productive.

WIN THE DAY: Before you switch on your computer, determine for yourself what 3 (or fewer!) accomplishments this day would constitute a win, a successful and productive day.

The other thing is to ask yourself the question from time to time throughout your day: What am I doing right now? That is, which of my to-do's am I working right now? Unfortunately, the answer is often: oops -- actually something else entirely.</comment>


Time heals all wounds?  I seem to be returning to Windows (just a little bit). - <AUTHOR>

I made the move to OSX a few years back and never looked back.  I was sick of Windows crashing, its spaghetti registry, its many many many ways of doing the same thing - all implemented differently by whichever third party hardware vendor wrote the drivers.  So I was happy to wave bye bye to Windows.
But recently I have found that I prefer doing development on Windows - somehow it feels more "precise", in an intangible sort of way.  Certainly Windows feels faster.  Much as I love my Mac, it has always felt sluggish and never felt super snappy like Windows.
So just for software development I have found that I have gone back to Windows. <comment><USER2> I've actually had the opposite impression; I couldn't believe how little Windows actually came with for development.

While I'm not a fan of everything that comes with the Mac, I've never felt that it had any _gaping holes_ like Windows does (e.g. Windows doesn't come with SSH or Perl or Python or even a reasonable shell and terminal, much less other useful utilities). In fact, sometimes the Mac has almost too many options; the Mac ships with something like 5 text editors, and that's before realizing there are excellent 3rd party ones too.

It's clear that Windows _can be made_ tolerable with some effort, but I've sort of lost patience with having to do what a company with Microsoft's money should be able to provide by itself.

My last exposure to Visual Studio was version 2005, and it started with the realization that the program was basically incapable of saving to the previous version of its own file format (which completely threw off my version control on a project where all other team members were stuck with older IDEs). I also remember with disdain opening Visual Studio 2005 and being given about 15 characters of space in which to type a series of "#include" search paths; I kid you not, it was faster to mount a network drive, open Linux and "vim", and edit the project XML file directly, than it was to futz with Microsoft's poorly-thought-out GUI to perform the same tasks.

I'm willing to allow that I've just had some bad experiences, and I hear so much praise for Microsoft's environments that I constantly feel like I must just be missing something. Yet everything I've seen doesn't make me think "snappy", it makes me think "kludgey, buggy, poorly-conceived mess from company with enough money to do much, much better".

</comment><comment><USER3> If your serious I'll post my windows story...BUT this is the giveaway ;)

"Notepad++ on Windows"

<comment><AUTHOR> I don't get it. What's funny about Notepad++? It's a great programmers editor.

<comment><USER3> Nice the ref to "Notepad++ on Windows" is gone.

You know S Balmer throws a chair against the wall and breaks into the "Monkey Boy dance" every time he reads a post like this?

</comment></comment></comment><comment><USER4> haha nice joke.

<comment><AUTHOR> No joke. Maybe it's the Mac keyboard too which I'm not as fast on as a generic PC keyboard. Also the availability of Notepad++ on Windows.

<comment><USER2> No such thing as a Mac keyboard really...you can replace it with any USB keyboard you want.

Then again I like the default one, it's very silent and the flat keys are kind of unique. Only stupid thing is that some important keys are too small, like function keys and sometimes the arrows.

<comment><USER5> As a many year Windows programmer I _love_ typing on my 2011 MacBook Pro keyboard _except_ for the cursor movement.

I can't seem to train my fingers to handle the different combinations of Alt/Opt/Cmd/Ctrl/Shift and the arrow keys. The lack of discrete page up/down and home/end keys really affects productivity.

<comment><USER2> You can use Control-down-arrow and Control-up-arrow to move by pages, and Command-up-arrow and Command-down-arrow like Home/End.

But note it is technically possible to remap key bindings for text fields in any way you want. Here is one article about it: <http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html>

Basically, Cocoa methods exist for almost any imaginable text editing action (such as pageDown), and they can be mapped to any keys. I would also imagine there's a way to map them to gestures on the MacBook's trackpad.</comment></comment></comment></comment></comment>


Ask HN: Why are there so few Show HN threads on homepage these days? - <AUTHOR> Is this a trend that only I feel or do others find it too? There is none at the frontpage at this moment. Could it be that:<p>1. We are busy this time of year 2. The bar of approval at HN has raised higher 3. It is just you. Data shows that it has increased. <comment><USER2> Last July, "Show HN" got a dedicated page in the top menu:

[https://news.ycombinator.com/show](https://news.ycombinator.com/show)

There have been 33 new submissions in the past 24 hours.

<comment><USER3> Frankly, I'm not sure this answers poster's question. While Show HN submissions are visible and volume is high, quality isn't so much. Maybe this explains why Show HNs don't make it to the front (not worth voting up).

I'm suspecting folks aren't submitting to Show HN anymore. They'd rather someone else submit their project for them once it's out of MVP/beta and matures a bit more. It has a much better chance of being noticed and gaining traction then. I also noticed Show HN volume is much higher a day or two after YC-rejection emails are out.

<comment><USER4> Show HN shouldn't be a platform for advertising startups anyway. Too many submitters try to "show" landing pages which are nothing more than subscription forms, or services which have no published source code and require signing up to even see what it is and how it works, to get viral and get traction.

Being a place for people to show off their _code_ and their (possibly incomplete, and not necessarily for profit) projects is what makes Show HN unique, on a forum otherwise biased towards startups and SV culture.

Of course, I recognize my personal opinion on the matter is not really relevant, but I don't think low volume is necessarily a bad thing.

<comment><USER3> I'm not against what you're saying w.r.t it being a place to show code and interesting not-for-profit projects, but we can't force Show HN to be that and only that. Forcing an open-source only culture on Show HN is no better than startups/SV forcing a for-profit culture on Show HN. I think we're better off with an open place that's balanced and healthy.

<comment><USER4> That's a fair point.

At the very least, though, I think users be able to do something with a Show HN submission besides just sign up for the beta. There should be content worth building a discussion around, even if it's just a mockup or preview of features.

<comment><USER2> HN agrees with you. The rules try to address that.

> Show HN is for something you've made that other people can play with.

> If your work isn't ready for people to try out yet, please don't put "Show > HN" in the title.

> For example, blog posts, sign-up pages, and fundraisers can't be tried out, > so they don't count as Show HNs.

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

</comment></comment></comment></comment></comment></comment><comment><USER5> 4\. Maybe there is just more traffic generally, so this slice of traffic is simply a smaller piece of the pie.

5\. Some other explanation.

 _You never step in the same river twice._

People always bellyache about changes in a forum. They change. Time moves on. They weren't static creations to begin with. Plus, there are always random fluctuations that are just a blip and mean nothing in the grand scheme of things.</comment>


From "happy hacking" to "screw you" - the story of Meraki - <AUTHOR> http://virishi.net/from-happy-hacking-screw-you-story-meraki <comment><USER2> _"... We immediately ordered 9 of the first beta units to try out. The technology was cheap ($50/unit) and it worked but what prevented us from going any further with it was the pricing model that they decided to adopt - $5/node/month for access to the "dashboard" - the real-time monitoring software that they were developing for managing the networks. ..."_

One of the bits I didn't like about the Meraki model was the requirement for all traffic to go back through the Meraki _"back-end"_ service. You might get _free_ access but at the price of centralised control. Google & Sequoia are backing this effort so you have to figure how the "do-no-evil" bit fits in with the centralisation of _"network analysis"_ ~ <http://meraki.com/oursolution/hostedservices/>

One other interesting tidbit is RM is a technical advisor ~ <http://meraki.com/about/>

</comment><comment><USER3> I'm a great fan of mesh networks, but...

How using 802.11a/g to build mesh networks of tens or houndreds of nodes is going to scale in a few years, when more people will need e.g. a 10Mbps+ access to Internet? I know - in developing countries there is no Internet access at all, so _any_ is better than nothing, but I wonder what will happen with all the deployed gear in US in a few years.

The radio has to be software-defined and flexible enough to improve it without replacing the whole gear, IMHO. We have to free the air to let such projects like Meraki build the Internet which won't suck in just a few years.

<comment><USER4> Sounds like a business opportunity to develop what was Meraki's original vision, with improved hardware and a software-defined radio.

</comment></comment><comment><USER5> The $50 price was obviously unsustainable; consider that a high-volume, non- mesh WRT54G sells for ~$45. The other parts of the story are certainly worrying, though. I wonder if this was driven by a change in management or if Meraki just said to themselves, "time to stop fooling around with open source and make some money".

<comment><USER6> I agree - we thought about doing a VoIP startup last year that involved some hardware similar to Meraki, and our costs came our to around $50 in the best case (not including the startup costs).

Looks like the management team is the same founding team of MIT PhDs, so my guess is they realized they needed to make money to stay alive and that open- source hobbyists aren't a good market in the first place.</comment></comment>


Red Hat Acquires Codenvy - <AUTHOR> https://blog.codenvy.com/redhat-acquires-codenvy-c84e1202a042 <comment><AUTHOR> Hey everyone. I am the founder and CEO of Codenvy. Today is one of the most exciting of my professional career. Five years ago we started Codenvy with a simple mission to simplify the lives of developers. Our services are used by 100s of thousands of developers online, and in numerous enterprises on- premises.

We began our collaboration with Red Hat a couple years ago, and our aligning on building software the open source way has lead to multiple collaborations.

Red Hat is acquiring Codenvy, expanding the team, and working with us to make Eclipse Che ([http://github.com/eclipse/che](http://github.com/eclipse/che)) stronger for everyone. To our nearly 50 employees around the world and shareholders, congratulations on this major achievement.

For the community - we are not disrupting the services and support we provide today. Looking forward to the discussion with you here.

<comment><USER2> Hi Tyler, since first reading a thread on your IDE-as-a-service on Hacker News I have consistently wondered, who could possibly be using this product? I have tried it, enjoyed learning about Docker and containerization and makefiles, but have found it basically useless for anything like "real developing." The localhost pipeline is just too effective on a reasonably priced machine with a good editor and a browser. Throw in stuff like ngrok for secure tunneling to localhost for demos, and it's basically over.

Maybe it's just for the people who are doing elaborate clusters/containers/orchestrator configurations. I have no idea.

I'd love to hear stories from the community about uses for this product. I'd love to hear reasons for Red Hat to care about acquiring such a thing beyond, maybe, shoring up a new piece of the Linux ecosystem in some tangential relationship to Docker? Everything about this feels like overreach and products in search of problems.

</comment></comment><comment><USER3> Congratulations to Tyler and the rest of the team. This is a great addition to Red Hat's portfolio</comment>


Chinese defector virologist Dr Li-Meng Yan publishes report Covid-19 made in lab - <AUTHOR> https://www.news.com.au/lifestyle/health/health-problems/chinese-defector-virologist-dr-limeng-yan-publishes-report-claiming-covid19-was-made-in-a-lab/news-story/36decb0c2bca253b696dec0cb665c970 <comment><USER2> I will be counting how fast this will be flagged/dead/dupe. Starting from the time it has been posted.

EDIT: Marked as [dupe] without a link to an original? Close enough though in 2 hours.

</comment><comment><USER3> I guess I know what to expect seeing being posted on Facebook soon.

<comment><USER4> What are you expecting to be seeing being posted on Facebook soon?</comment></comment>


Why I rewrote the mesh generator of Dust3D from Rust to C++ - <AUTHOR> https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/ <comment><USER2> " _When you implement an algorithm using C++, you can write it down without one second of pause, but you can't do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving._ "

Yeah...

On my last C++ project, one very productive co-worker kept disabling -Wall, etc., because "nobody has got time for that." I periodically fired up valgrind and chased down assorted memory issues.

So, yeah...

<comment><USER3> Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.

<comment><USER4> I've found that more often, it should be reworded as "unsafe fast, painfully maintain without the resources to ever fix later".

<comment><USER5> The number of TODO's that litter code in general, or issues file to "cleanup" are generally significant. You're making a great point that accruing technical debt at the cost of safety, is quite possibly technical debt, like all other, that will never be paid down over the life of the software.

I completely agree.

</comment></comment></comment></comment><comment><USER6> /r/rust thread: [https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_...](https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_the_mesh_generator_of_dust3d_from)

You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..

<comment><USER7> > _You 'll notice the top rated comment, & majority of comments, agrees with > their decision to switch to C++. Yet we'll persist that Rust is an elitist > community._

Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " _If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make this code "safe" regardless of language. _" , elsewhere " _I get that this project probably values developer efficiency over safety or correctness, and probably makes sense in this use case._ ", etc. Still smells kind of elitist to me.

<comment><USER5> How would you describe the trade-off between safety and the developer productivity listed as the reason in the article?

The comment seems to just be saying that it's reasonable for someone to make this trade off when they are more knowledgeable and familiar with one language rather than another.

I think your reading quite a bit into that comment to take it as elitist.

<comment><USER7> > _I think your reading quite a bit into that comment to take it as elitist._

" _... there is a long way to go to make this code "safe" regardless of language._" and " _...values developer efficiency over ... correctness ..._ " are somewhat uncomplimentary additions to their main points, no matter how you look at it.

</comment></comment></comment></comment><comment><USER8> The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author.

I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common.

Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, error free and perfect at time of production.

The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. Coupling components by types propagating through software, increasing time and effort to make changes to your software, increasing the overhead for others to contribute.

In my opinion the dominant metric to evaluate the usefulness of a language's type system should be its overall effect on cost, time spent, productivity, ease of development and capacity to change. Everything else is very subjective or just an aesthetic concern.

<comment> loup-vaillant > _The downside that the author points out seem to be often neglected. > Constant interruption and battling with the type system during development, > when mental overhead is a problem._

Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system _reduces_ my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined, so I don't have to be.

In practice, with few exceptions, when the type system is refusing to compile something I just _screwed up_ , and I'd better fix my mistake right away. I'd wager that with few exceptions, when Rust is refusing to compile something, you are making a mistake that in C++ would have bitten you down the line.

What you call "fighting the type system", I call "fixing bugs".

<comment><USER9> I worked professionally in Haskell for a long time and I cannot disagree with you more. This is always the promise of strict functional languages but in a business setting where the very nature of what you build has to be arbitrarily mutable at the whim of competing interests between stakeholders, engineers, customers, etc., it just doesn't work.

You end up with the same spaghetti code messes, unexpected runtime errors, indecipherable crashes, etc. no matter what degree of strict verification tooling you use. The introduction of lazy evaluation, difficult to debug tail recursion implications on memory consumption, elevating IO into the type system, burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell... it becomes the same shit code mess as any other paradigm.

<comment><USER10> Interesting. I would be interested to know more details about what you worked on and with whom. This hasn't been my experience in any of the four jobs I've used Haskell at.

I don't deny that Haskell leads to spaghetti code messes, unexpected runtime errors, and indecipherable crashes, but the Java that I've previously worked with and the Python I currently work with suffer from those to a degree greater by an order of magnitude.

<comment><USER9> It was first for a bank, later for a data analytics start-up, and then also for an education technology company. I had many skilled functional programmers on my team too, including a few people who had done work on GHC itself.

I've also see code messes in many languages. It's a business culture problem, has nothing to do with the language or paradigm.

I'll greatly dispute with about Python though. It has been a language that facilitates notably cleaner and more extensible implementations in my experience. Seen messes in Python too, but absolutely no way it's "an order of magnitude" worse. That's simply ridiculous. The only way that's happening is if the programmers are exceptionally bad to the extent that it would not matter which language they used.

<comment><USER10> Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions.

To give you a Python example, it encourages stuff like:

        def send_email(recipients, contents):
            if type(recipients) == str:
                send_one_email(recipients, contents)
            else:
                for recipient in recipients:
                    send_one_email(recipient, contents)

That is a flavour of convenience that people commonly implement in Python. People like it because it allows both

        send_email("tome", contents)

and

        send_email(["tome", "mlthoughts2018"], contents)

and saves them from typing two square brackets. The problem is when you call

        send_email(u"tome", contents)

It tries to email "t", "o", "m", and "e". This kind of stuff is endemic in Python. Yes, this did happen in practice in a company I worked for (a company that was responsible for trading hundreds of millions of dollars of securities every day). Call the programmers exceptionally bad if you like, but they were among the brightest minds graduating in my country. It was Python that allowed them to be sloppy.

<comment><USER9> I disagree very much. The Pythonic way would be to do something like map(send_email, list_of_addresses), and have send_email raise an exception if not passed precisely a single string, and presumable raise exceptions when you validate that the email address is of an acceptable format, etc.

It would not be Pythonic to make the function superficially handle different arities of argument through explicit handling on the list type with isinstance, precisely because you'd need to handle different meanings of different types that implement the Iterator Protocol. That's not something Python generally encourages, it's just a mistaken implementation. And particularly not making careless assumptions when basing branches on isinstance behavior (for example, you could always encounter custom classes that have overridden __instancecheck__ or __subclasshook__ special methods.

<comment><USER10> It's certainly a poor use of Python's flexibility, but I've seen that kind of thing written at two completely different companies by completely different, yet smart, people so I suspect it's prevalent. Haskell does a much better job of nudging smart people to write good code. Gabriel Gonzalez explained it better than I could: [http://www.haskellforall.com/2016/04/worst-practices- should-...](http://www.haskellforall.com/2016/04/worst-practices-should-be- hard.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Three problems with this:

1\. You still have to fight with borrow checking in Rust as in C++, it's just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you're used to writing C or C++, it's going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn't make mistakes the same way a human does, and that's value added not detracted.

2\. Having the benifit of actually having a package manager, Rust is much easier to download and use dependencies with. That said, I agree with the general premise of not using Rust if you have an immediate business need and it's missing a core library. My issue is that it should be fairly apparent before you start a project what dependencies you need, so a rewrite back to C++ seems odd. Also, Rust is an open source ecosystem, and people using it should feel compelled to consider writing the missing pieces they need for the benifit of the community. It's also odd to say that Rust doesn't have what you need, it sounds like there are C libraries that already do what you want, and Rust can wrap C.

3\. If something is written in C and you don't have time to replace it, just wrap it in unsafe and make a safe interface over it. Rust is exceedingly good at interfacing with C, so any library you can use in C can potentially be used in Rust.

<comment><USER12> > As the author points out, if you're used to writing C or C++, it's going to > take a while before responding to the borrow checker is second nature

I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I understood why it couldn't tell. Usually, when I hit it, it is because I forgot a case and am grateful for it. I know of at least one optimization I've made that I would never have bothered with without the borrow checker. It would have been too much bother for me to reason about everything. Even if I did, it would have been even worse to maintain.

<comment><USER13> Were you trying to write GUI code?

Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought.

Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.

<comment><USER12> No, I have not written a GUI in Rust yet. I've been doing libraries and CLIs so far.

But I find the standard approaches to GUI broken: inheritance and shared mutable state. i think Rust does a service by highlighting the brittleness of this pattern via syntax / libraries.

I've not dealt with elm-like GUIs. Probably my natural inclination would be to use an actor framework. And to be clear, I am speaking from having written non-trivial GUIs with both GTK and Qt (I miss the Maemo days).

</comment></comment></comment></comment><comment><USER14> > As the compiler will stop you from borrow checking or something unsafe again > and again, you are being distracted constantly by focusing on the language > itself instead of the problem you are solving.

While anyone is obviously free to use any language he or she likes the whole article comes across to me as someone arguing why they dont want / need seatbelts: "They constrain my movement, I'm a good driver, etc.".

These are also the same kind of arguments one could make for wanting to use a weakly typed language instead of a strongly typed language.

Personally I like my types strong and my memory safe...

<comment><USER15> Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)

<comment><USER16> Most of those langauges don't have the perf of rust or cpp.

<comment><USER17> Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

<comment><USER18> > Most programs don't need C++ performance. Java is usually within factor of > two and usually fast enough.

Meshing software is a typical program where you need C++ and where Java is a terrible choice.

By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.

<comment><USER15> The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world:

Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.

In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language.

In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.

<comment><USER19> I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.

<comment><USER15> You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.

<comment><USER18> > And you would probably want to focus on parallelism, where C++ again is not > the best.

Here again, this is wrong.

99% of highly scalable parallel code that run on supercomputers is C++ or Fortran.

And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.

<comment><USER13> Yet Julia and Chapel are winning hearts of HPC researchers.

Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.

<comment><USER19> But the GC is frowned upon a lot in the D community. A lot of D programmers try to make everything they write @nogc.

<comment><USER13> A GC in a systems programming language is there as a productivity and safety mechanism, by no means as the only way of doing 100% of memory allocations.

A vocal sub-community of D programmers argue for @nogc due to GC phobia, as ex-C++ devs, and a GC implementation found lacking. A situation that might improve with the recently released GC pluggable API and a new precise tracing GC.

Many devs that prototype their apps in D without doing premature memory optimizations, end up realizing that for their use case it actually good enough.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings.

In other words, C++ is utterly entrenched in that space like Fortran is for HPC.

<comment><USER20> Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.

<comment><USER19> And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.

<comment><USER13> The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C.

The industry always needs some pioniers willing to do the investment regardless of the naysayers.

<comment><USER21> Note that the game industry avoided C++ for a long time because those early C++ compilers produced code which was very large and quite a lot slower than you'd get from C, so C++ was kind of a non-starter when you were writing code for the consoles of the day which had slow processors and only a few megabytes of RAM. You just couldn't afford the overheads of C++ or your competitors would eat your lunch.

It wasn't about needing a pioneer to show us that we'd been wrong; we _weren 't_ wrong. C++ just wasn't ready for the particular set of requirements that games imposed, yet. Once the state of C++ compilers began dramatically improving in the late 90s (by the criteria of optimisation and executable sizes), most studios moved over to the language pretty quick. Or at least that was my experience.

<comment><USER13> The pioneers were the studios using Watcom C++ on MS-DOS, while others were still being dragged into Windows with plain old C, while complaining about losing hardware access until Wing was released.

And the studios that were forced to adopt C++ when the PlayStation SDK required it.

So nothing speaks against other languages getting over the same kind of acceptance issues.

</comment></comment></comment></comment></comment></comment><comment><USER17> "As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving."

This is very much true while learning, and very much not true once you finished learning. It would be very concerning indeed if it were otherwise. As is, it is very concerning for Rust adoption, as this post evidences.

</comment><comment><USER22> This is why I gave up on Haskell. Code is still (currently) written by humans. Sure the code was more terse, but I had to expend more time thinking about every tiny piece of that terse code. I've been programming for 36 years. Just as some people think out loud, I think by shaping and reshaping code. Top-down doesn't work for me, although I know there are other developers for whom it does. I like to build bottom-up by fooling around with little pieces. I have no experience with Rust, but fooling around in Haskell just took all the joy out of programming, for me, while adding frustration.

EDIT> I would rather have better CASE tools / an AI pair-programmer than be straitjacketed into a top-down correct-first then code way of working.

<comment><USER23> Even with a top down approach you can end up with insane type level machinations or group/category theory that only the best Haskell developer can decode. Sure it's elegant, but damn near indecipherable.

</comment></comment><comment><USER24> I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be honest, the tools available are enough to make you figure out any issue: gdb/core dumps/valgrind, when combined with good software practices and unit tests seem to work ok for the rest of us. The compilers now have sanitizers, and new versions of gcc actually tell you what your template errors are. It's 2019, not 2005 for C++. Smart pointers are now available: use them! Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions? Not everything a program uses is memory: we sometimes need sockets! In C++ using RAII works well, does the Rust Type System statically error/type check non- memory resources automatically, or is that out of scope?

<comment><USER25> > _I wonder how many of the Rust defenders in this article actually know C++ > and have written a production used Rust system, instead of a side-project on > github, so that they can compare in an informed way? The author certainly > has, but who else has?_

Hello. :-) I started writing C++ around 1992, and was lead programmer on various C++ production systems from 2002 until 2011. I worked with valgrind, unit tests, and boost/std::tr1 C++, but not C++14 or 17.

For the past three years, I've been writing production systems in Rust. Here are some things I've observed:

\- If your C++ code relies heavily on complicated webs of objects that all mutate each other (as found in many game and GUI designs), you'll have a bad time translating that code to Rust. If your C++ code tends to be more functional, idempotent, or transaction-based, and if it has clear ownership of objects, then translating to Rust will be much easier. For example, Rust seems to work better with ECS-based games and React-like GUIs.

\- Rust is significantly weaker than C++ for designs which use integer template parameters (e.g., "vec<3>") or partial template specialization.

\- Modern C++ allows you get ownership 99% correct, if you throw enough tools at it. Rust gets ownership 100% correct by default. If you're dealing with situations where that 1% matters (complex threading, or decoding hostile data), then it's a much bigger difference than you might think.

\- Not counting Rust IDEs (which are only borderline OK by static language standards), Rust tooling is _great_. Dependency management is solid, linting is good, automatic formatting is good, etc.

\- I've been working with nightly and experimental builds of Rust async code, and I think that Rust will soon give C++ a real run for its money in this space. Multithreaded async executors (where you mix "green" threads with OS threads) rely _very_ heavily on precise tracking of who's allowed to mutate what, which Rust is excellent at.

> _Finally, if a Rust veteran could let me know: how does Rust deal with > general resource management in the presence of exceptions?_

Rust does not have exceptions. Instead, it uses `Result<T,E>` and the `?` operator to propagate errors. Ownership and RAII are 100% idiomatic and fully checked by the same systems as memory management.

<comment><USER26> > If your C++ code tends to be more functional, idempotent, >or transaction- > based, and if it has clear ownership of >objects, then translating to Rust > will be much easier

That's exactly the kind of c++ code you probably don't have to refactor/move to another language at all

</comment></comment></comment><comment><USER27> One thing that I don't see pointed out is that Rust is a _nightmare_ if you are dependent upon mutable algorithms.

I suspect that mesh generation is very much a mutable algorithm domain and probably a high impedance mismatch with Rust.

For example, simple things like mapping a struct of three elements to a vector of three elements were, at one point, very difficult if not impossible in Rust.

</comment><comment><USER28> My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt.

Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for greenfield projects. You'd want to fight your problems, not your problems plus Rust. On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite.

Personally I don't think Rust is that hard to learn and some of my side projects are being written in Rust. But if I ever had a business with Rust as a main language, I'd be worry I could find enough Rust programmers. Fortunately the community is addressing its ergonomics and hopefully one day its approachability and learning curve will also gain more attention.

<comment><USER16> > On top of my head right now I couldn't think of any famous Rust projects > which aren't a rewrite.

Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes on.

</comment></comment><comment><USER29> One day, social anthropologists will read these Hacker News message forums to learn about tribal warfare among programmers. What will they say, considering their entire new world was based on Rust?

Kidding. Stop fighting, people. You're all on the same team.

<comment><USER30> My theory is that there are two basic ways of understanding the world around you and solving problems. Statistically and structurally.

Everyone can do statistical problem solving. At least everyone who can talk. What you do is that you start making sounds when you're an infant and then you receive positive or negative feedback. This continues until suddenly you know how to talk.

Similarly, in industrial chicken raising you need to differentiate between male and female chicks right after they're born. However, there isn't any guide to determine the difference. Instead what you do is that you take one person who knows how to do it and pair them with someone who doesn't know how to do it. The person who doesn't know how to do it will guess at the sex of the chick and they will be corrected by the person who does know how to do it. After enough time you have two people who know how to do it.

Sounding familiar yet?

Most people learn programming languages in a statistical fashion. They try a bunch of stuff and get positive or negative results (compile fails, runtime errors, etc). However, just like determining whether a chick is a male or female in the chicken raising industry, nobody can really give you the specification of how to program. All they can do is tell you that you are doing it wrong or doing it right for any given scenario.

Now of course there are problems with the statistical method (also benefits, but we're interested in failure right now). 1) You can't say why you're right [in order to do that you have to sit down an analyze what you've been doing in a structural fashion]. 2) The only teaching method you know involves telling people they're wrong when your gut tells you they're wrong. 3) You'll have a terrible intuition for any situation that only causes a failure after a period of time or some of the time (think undefined behavior in C).

If you have only learned programming statistically and haven't sat down and reflected on what the structure of what you're doing actually is, then when you are faced with information that is contrary to what you know your natural reaction is going to be to listen to your gut (even if your gut is wrong) and provide the same negative response that you got when you were first learning.

Additionally, the only "reasons" that you'll be able to give are paper thin metaphors and thought terminating cliches that don't stand up to even the smallest amount of examination.

The end result? You get a bunch of programmers that freak out every time a new language comes out.

</comment></comment><comment><USER31> ...hasn't Swift become a viable alternative in this space by now? I see it's getting used in ML a bit, and looks nicer than D and easier to learn than Rust.

<comment><USER13> Just like Objective-C, Swift is mostly a thing on Apple platforms.

</comment></comment><comment><USER32> Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong".

I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.

<comment><USER33> > the only response we are seeing is "you're holding it wrong".

We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're _very_ interested in improving them; if you have good ideas about it, you'll get heard out.

<comment><USER32> Can you point me to a document listing the changes from this effort?

<comment><USER33> Probably the closest is [https://blog.rust-lang.org/2017/03/02/lang- ergonomics.html](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html), which laid out the plans to do so. That being said, there wasn't a single real document I can point you to: it was a label attached to a number of RFCs, and not really tracked as one thing. Some stuff that ended up landing under this banner was:

Non-lexical lifetimes

"Match ergonomics"

Implied lifetime bounds

The anonymous lifetime

The question mark operator

Async/await (this one is still in progress)

The removal of "extern crate"

... and some other things I'm sure I've forgotten. I also said "last year" but that blog post is from 2017, and that's because it took a long time for RFCs to be created, accepted, implemented, and stabilized; a lot of this stuff landed in the latter half of last year, though some before then too.

</comment></comment></comment></comment><comment><USER16> "As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background."

To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed.

Here is a good article that arrives at the opposite conclusion: [https://kyren.github.io/2018/09/14/rustconf- talk.html](https://kyren.github.io/2018/09/14/rustconf-talk.html)

I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.

<comment><USER34> XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs.

I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community.

I am sticking with rust for now because I feel like there is a bandwagon and there might eventually be money in it, but I am certainly not a convert.

<comment><USER16> > XML didn't work? use more XML. Everybody has a breaking point, and they > reached theirs.

This argument could be applied to anything.

What's crazy about Rust stack organization? What are the issues with the community?

<comment><USER17> There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision- making people. [https://github.com/rust- embedded/wg/issues/64](https://github.com/rust-embedded/wg/issues/64) details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.

</comment></comment></comment></comment><comment><USER35> As someone who never learned C++, I keep hearing about how today's C++ is much better than the C++ of a few years ago. Can anyone recommend a resource for learning some C++ basics using today's modern C++?

</comment><comment><USER36> Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.

<comment><USER37> "completely unusable"

You forgot to tell Microsoft (biggest software seller on earth)and they decided to use it in actix

<comment><USER13> And are proposing it alongside C# and Core Guidelines compliant C++ for new systems software.

<comment><USER16> Do you have a link?

<comment><USER13> Sure. Check the presentation slides.

[https://github.com/Microsoft/MSRC-Security- Research/tree/mas...](https://github.com/Microsoft/MSRC-Security- Research/tree/master/presentations/2019_02_BlueHatIL)

</comment></comment></comment></comment></comment><comment><USER38> I was a fan of rust when it first started. i wrote some consensus algorithms and metrics packages in rust. i also hosted a rust podcast. I now believe Rust has failed. Mostly because of the arrogance of organizations like the rust community and the inability to form stronger relationships with companies like apple. I now think that people should focus on swift and soon it will have the same native code support and a borrow checker. I think we all learned a lot but it's time to realize people still don't understand why not go and swift. C programmers continue to prefer c and more and more people are shifting back from rust to c++. rust will never provide enough</comment>


10 Tips to Stress Less - <AUTHOR>

The Techology

    * Ruby On Rails
    * Gems & Plugins:
          o asset_packager
          o acts_as_list
          o clearance
          o declarative_authorization
          o facebooker
          o formtastic
          o hoptoad_notifier
          o paperclip
          o sanitize
          o will_paginate
          o vote_fu
    * rSpec, Cucumber, Selenium
    * PostgreSQL
    * jQuery and a range of plugins
    * Facebook Connect, XFBML, FBJS
    * Heroku with the RPM add-on
 Things I learned:

    * Facebook Connect is awesome
    * Ruby on Rails continues to be awesome
    * Heroku is awesome times infinity
    * http://topsecretproject.finitestatemachine.com/tag/ruby/
 <comment><USER2> > * Facebook Connect is awesome

Beg to differ (IMHO of course): their willingness to change core parts of their API without much (read: any) notification, and their inconsistencies between documentation and implementation caused me much pain. It's awesome that you have access to such a wealth of information, but it's not a mature platform, which it definitely should be by now.</comment>


Sleep-deprived writer raising money for charity with websockets (tech demo now) - <AUTHOR> http://www.100hours.tv

<comment><USER2> We're currently trying to load test the web app. Feel free to come and check what's going on in David's mind as you see him typing in real time, so that we can get an idea of how much traffic we can sustain. If it's for a good cause, also.

</comment><comment><USER3> Pretty sure it's impossible to stay awake for 100 hours without some serious drugs. Good luck either way!

<comment><AUTHOR> Almost definitely, but it will be fun to watch him try!

We're working on an AirHorn that users can trigger if he falls asleep. Make a donation and press the button remotely!</comment></comment>


Meet instacompo.se before everyone - <AUTHOR> http://instacompo.se

<comment><USER2> "there is no unique music composition :)

<comment><AUTHOR> in fact there is a unique melody for every singing,other music is just the extension

<comment><USER2> seems that much interesting app coming soon, good luck :)

</comment></comment></comment><comment><USER3> What is this exactly?

<comment><AUTHOR> It is a music composition application.It takes your singing and makes a beautiful music for it automatically!

</comment></comment><comment><USER4> I like the idea!</comment>


Unreal Networking Architecture - <AUTHOR> http://unreal.epicgames.com/Network.htm <comment><USER2> This is a fantastic article - as are most of the technical materials that Tim Sweeney wrote way-back-when. The Unreal system was my first introduction to the architecture of "real" object oriented apps and I refer back to these articles from time to time as a sanity check.

<comment><USER3> Link to those articles?

<comment><USER2> Checkout the Programming category (on the left frame) from 2000: [http://web.archive.org/web/20001203052300/http://unreal.epic...](http://web.archive.org/web/20001203052300/http://unreal.epicgames.com/)

His article on the scripting language was also my first realization of the power of DSLs.

I should also say that most of my learning came from studying the header files in the SDK and imagining what the various implementations would look like. The SDK is still available: <http://www.udk.com/download>

I even taught myself how to write a decompiler so I could see those implementations. This taught me about the PE format, C++ name mangling, and, of course, x86 assembler. Heady stuff for a 20 year-old. :-)

And then he posted this darned screen shot: [http://stackoverflow.com/questions/2791787/what-was-tim- swee...](http://stackoverflow.com/questions/2791787/what-was-tim-sweeney- thinking-how-does-this-c-parser-work) and taught me about C++ metaprogramming.

And then this presentation: <http://www.cs.princeton.edu/~dpw/popl/06/Tim- POPL.ppt> which made me spend months learning what these stupid Monad things are and having to learn Haskell, ML, and Common Lisp in the mean time. (What? C++ isn't the best programming language available?)

While some people learned to program by going to college, I learned by studying _everything_ Tim Sweeney and John Carmack wrote (and practicing, practicing, practicing). Mr. Carmack's release of old id source code is a huge gift to the world.

<comment><USER3> Thanks

</comment></comment></comment></comment><comment><USER4> The Quake 3 network architecture is also a fantastic read. Anybody wanting to learn how to implement netcode should definitely read them.

The first time I implemented a UDP gameserver, they were invaluable resources for the logic required if you don't already understand how it works. (Selective msgs require acks, most don't, most don't need resends, etc).

</comment><comment><USER5> Just keep in mind -

> _Last Updated: 07/21/99_

<comment><USER6> It's been maintained:

The latest version of that document: <http://udn.epicgames.com/Three/NetworkingOverview.html>

How Unreal's content packaging relates to its networking architecture: <http://udn.epicgames.com/Three/PackagesAndNetworking.html>

How the game state is replicated: <http://udn.epicgames.com/Three/GameStateReplication.html>

How that packaged content is streamed to the client: <http://udn.epicgames.com/Three/ContentStreaming.html>

And somewhat older:

How events are simulated on the client: <http://udn.epicgames.com/Two/SimulationReplication.html>

How variables are replicated: <http://udn.epicgames.com/Two/VariableReplication.html>

How functions are replicated: <http://udn.epicgames.com/Two/FunctionReplication.html>

</comment></comment><comment><USER7> Wow, thanks for the link!

<comment><USER7> Good, downvote positive feedback. Great idea.</comment></comment>