Bootstrapping an Ultra Low Latency Trading Firm, Part 1 - <AUTHOR> http://veyronb.wordpress.com/2011/07/31/bootstrapping-an-ultra-low-latency-trading-firm-part-1/ <comment><USER2> From the article: "And if you are careful enough to save money (for example living at home saves about 3K a month when all is said and done) and not increase your expenses too much (no need to get a Porsche when a BMW or VW suffices), it's not hard to save 200K by the time you turn 24."

Uhh, sure? 200K at 24, in savings?

So that's about 250K pre-tax. Say you graduate high school at 18, find a magical job that gives a high school grad $42,000 a year, and spend /not one cent/ for six years, maybe... (or extrapolate outwards).

Or maybe you go to college. Graduate, let's say, age 21... In this economy, how many college graduates walk out of school into an $85,000/year job and no living expenses...

Never underestimate the value of a silver spoon in your mouth... and never underestimate the power of denial about just how silver your spoon is.

<comment><AUTHOR> Unfortunately I had no silver spoon :/

Due to family financial pressures, I had to graduate early. Fortunately I was taking enough credits to graduate a year early.

I really didnt want to discuss numbers, but I realize that the comment seems a bit misguided if not put in perspective. I started out with salary 250K (not including signing and year-end bonus), but most of my salary excess went to helping out my parents, so I really couldnt save much. Most of the savings came from saving bonus checks and not increasing spending when I was promoted.

My remark about the car specifically was to point to the fact that almost all of my coworkers were fortunate enough not to have that type of family pressure, so they could afford to get nicer cars (my BMW is a 40K 3-series, for which I could take a lot of deductions because I was running a startup at the time, compared to some of my subordinates driving 160K porsches). It's easy to say that you won't scale up your expenses when your income rises, but its hard to do so when your coworkers and social network are scaling up much faster than you.

<comment><USER3> If it is not too personal, why did you stop? Also, do you prefer comments here or on your blog? To answer your last question in the blog: yes please keep going!

<comment><AUTHOR> Oh no the fund is still running. After building a ton of python and C programs to automate basic tasks, thanks to the magic of cron, I stopped doing a lot of the day-to-day work. And now I have some time on my hands :)

There was another discussion in <http://news.ycombinator.com/item?id=2828538> and I got the impression that people were interested in HFT, if not necessarily supporting it. Furthermore, I find that many people in the industry are surprisingly tight-lipped over the most mundane things (god forbid someone finds out about struct.unpack or RDTSC). My motives are fairly straightforward:

1) discuss some of my experiences for those who are interested in seeing how to bootstrap a trading operation;

2) convince people that finance startups exist and have interesting challenges; and

3) excite some people to the extent that they would like to work with me.

I'm honestly not excited by most of the traditional candidates from finance recruiters, mostly because the market is flooded with excel-happy windonauts that couldn't even do basic excel tasks (like calculating a pnl given a CSV -- I would use awk, but that's not a traditional windows thing) and "linux" developers who don't know how to use grep or perl/python.

Also, the last time some tried a retrospective [<http://news.ycombinator.com/item?id=2162346>], I got the impression that he was looking for a job. And given that the blog was taken down, I'm guessing he found one :P

As far as comments are concerned, at least I get an email when a comment is made at the blog. I dont get an email here, and see an item like this if I happen to stumble upon the post.

</comment></comment></comment></comment><comment><USER4> Favourite quote: "It's not hard to save 200k by the time you turn 24."

I'll continue reading for the technical insights, but honestly, this reflects a certain lack of perspective.

<comment><USER5> I think there is an implicit assumption that you already work for a trading firm.

</comment></comment><comment><USER6> I'd like to go on the record as the pessimist in the room. If you go down this path, I strongly believe that you're going to lose your shirt building a bankruptcy machine. In many ways, the markets are a mechanism for transferring your money to the pockets of people who started out with more money than you.

<comment><USER2> I'd strongly suspect that this guy is definitely in the upper middle, to begin with. "Why buy a Porsche when a BMW will do?", complaining about the duldrums of a six digit income... talking about being easily able to have quarter of a million in savings at age 24... etc, etc.

<comment><USER6> We could be charitable and assume that he graduated from high school and college in 6 years, and was immediately hired into a well-paying job at age 20. With four years of pre-tax income at $140k, $200k in savings isn't out of the question. (Assuming a 30% marginal tax rate we get a post-tax savings rate of 51%.) Not typical in the slightest, but not impossible, especially if you're from a pampered background.

That aside, claims like this show a lack of perspective and the slightest overconfidence can cut everyone down.

</comment></comment></comment><comment><USER7> Here's another question I'm curious about. Given that you've decided to start an automated trading firm, how much better off are you going for microsecond timescales rather than, say, seconds or minutes?

</comment><comment><USER8> Would be very interested to see the rest of the story. I've always had a lingering interest to bootstrap a trading algorithm. It doesn't even have to be HFT.

<comment><USER9> These might interest you:

[http://www.amazon.com/Quantitative-Trading-Build- Algorithmic...](http://www.amazon.com/Quantitative-Trading-Build-Algorithmic- Business/dp/0470284889)

<http://collective2.com/>

</comment></comment><comment><USER10> As an ML/AI guy, I'm curious about the problems encountered by HFT systems. What I would love to see is some data, along with the desired outcome. Maybe also include the amount of time available to make the said decision. One could go further and institute a "Netflix prize" with such data.

Right now, I'm clueless about what kind of data these systems deal with, and what are they supposed to do.

Any HFT/ULLT people willing to share data?

</comment><comment><USER11> Many of the items discussed in this pre-article seem way overkill for what the author seems to be trying to do. It doesn't take much to create an account with a reputable broker like Interactive Brokers that has a good live API for auto-trading (and support paper trading to test your code without using real cash). There are no upfront fees on many brokers and the commission is often minimal depending on the transaction. eTrade has similar APIs. Historical data is available at minimal cost through a sites like eoddata.com. Also, especially if you're just starting and experimenting with formulas, using your personal laptop/desktop with a live feed from IB is more than enough to act on live tick data for the symbols you're interested in.

<comment><AUTHOR> You can't do ultra low latency trading on IB or any of the discount brokerage houses. Essentially, your order goes through their system before it goes out on the broad market, and that (time) cost is orders of magnitude larger than the internal system cost. Also, the (economic) costs of doing business with that type of broker are comparable to to the profits.

There are difficulties with simulating at this level, and I will go into this later, because the quality breaks down. Many ultra low latency trades involve some sort of rebate capture (profiting off of the fact that the exchange gives you money if you provide liquidity to the markets), and that requires some sort of model for how the rest of the market would react to the presence of your extra liquidity.

</comment></comment><comment><AUTHOR> New post: <http://news.ycombinator.com/item?id=2835656>

</comment><comment><USER12> This is very interesting. Would love to see more posts about it as you go.

</comment><comment><USER13> What did you major in when you were in college? Finance?

<comment><AUTHOR> math,cs,philosophy

<comment><USER13> I'm majoring in CS right now. What type of courses would you recommend that i concentrate on if I am interested in HFT?

And how did you learn trading strategies? Did you take any finance type classes in college, or did you learn them all on your own?</comment></comment></comment>


Alan Kay: Power of Simplicity [video] - <AUTHOR> https://www.youtube.com/watch?v=NdSD07U5uBs <comment><USER2> Around 9:30:

"What's the expense of getting simplicity? [..] You get simplicity by finding a slightly more sophisticated building block to build your theories out of. It's when you go for a simple building block that anyone can understand with common sense that you start screwing yourself right and left."

<comment><USER3> I found that interesting as well.

After thinking about it for a while, I struggled to get anything profound out of it. I feel his point is equivalent to saying "a higher level of abstraction can make problems more tractable" which is something we do all the time in all contexts.

Finding good abstractions is an art but I don't think this really maps to insights like Copernicus though. I see a slightly different process happening i.e. discovering a new perspective on a problem. A new perspective can be a different way to decompose a problem but I don't think it necessitates anything about the sophistication of the building blocks. Instead, a revealing change is often because it changes the type of relationships between the building blocks in a radical way that enables new inferences.

<comment><USER4> Don't know if this applies to your post, but I got a lot more out of Alan Kay talks when I stopped trying to look for profundity, and assumed he's mostly talking about how we're being morons.

<comment><USER5> I think that too is wrong way of looking at it.

What he basically says is, you need an organizational framework that works 10 years at a time in order to get a result in 7 years. The people working in this framework, needs 5 years windows and you need to hire absolute geniuses and have the trust that they'll do the right thing.

If you do that, you will get long term, world changing inventions relatively cheap.

I don't think anyone is being a moron for utilizing a staff of less than stellar geniuses to get work done in a time frame less than 7-10 years.

<comment><USER4> I believe there's a lot of evidence we're collectively morons. Consider how close we are to a transformed world. Hunger, wage slavery, environmental destruction, etc could be a thing of the past if enough of us decided right now to be serious... countering absurd ways of thinking.

Are people really afraid of death? Then we should invite people to organize to solve that. Support each other regardless of gender or other insignificant differences, to accomplish such goals; any menial work can be shared equally. What huge percentage of humanity would go for that?

But currently we organize ourselves in moronic ways. Alan Kay's vision seems actually quite narrow and corporate-friendly; many go further in seeking to liberate imagination. [http://thebaffler.com/blog/david-graeber-defiantly- having-fu...](http://thebaffler.com/blog/david-graeber-defiantly-having-fun- at-the-baffler-no-22-release-party)

<comment><USER6> The moronism comes from a corporate culture that prioritises short-term gain over the invention of ultra-profitable long-term game-changers.

How many of the advances in computing have been inspired by MBAs demanding quarterly growth?

We have no formal tools for valuing our collective future.

Incubators and accelerators come closest, but the emphasis is still on believable prospects for profitability - hence investing in the team, instead of good ideas - and not on open research.

<comment><USER7> Or is it a rational discounting of uncertain distant future results compared to the relatively more certain short-term gains?

Or taking another look - how much of your income are you investing for retirement vs current consumption? Why?

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > _" The big problem with Xerox is they only wanted to make billions. And > that's the problem with most companies. When you're doing kind of stuff > you're actually in the trillion-dollar range."_

<comment><USER5> Yeah, he is really selling his new research division hard.

<comment><USER9> The quantity of world-changing tech that came out of the late 70's has never been matched. In fact it's hard to come up with more than a handful of innovations in tech of the same magnitude that have happened since. [http://stackoverflow.com/questions/432922/significant-new- in...](http://stackoverflow.com/questions/432922/significant-new-inventions- in-computing-since-1980)

<comment><USER10> The World Wide Web. Yep, plenty of antecedents, I personally start with Vannevar Bush's Memex for the idea, and there were many attempts with varying levels of un-success, until Tim Berners-Lee put together a winning, massively network effects positive solution.

Which, along with search engines, have resulted in significant, qualitative changes in information publishing and access; in the '70s (or perhaps earlier) Jerry Pournelle was looking forward to the day when you could quickly find the answer to any question that had an answer, and this is one of the biggest steps towards that.

To the point I rank it near computers _per se_ ; from Wikipedia ([https://en.wikipedia.org/wiki/General_purpose_technology](https://en.wikipedia.org/wiki/General_purpose_technology)):

 _General-purpose technologies (GPTs) are technologies that can affect an entire economy (usually at a national or global level). GPTs have the potential to drastically alter societies through their impact on pre-existing economic and social structures. Examples include the steam engine, railroad, interchangeable parts, electricity, electronics, material handling, mechanization, control theory (automation), the automobile, the computer, and the Internet._

This was the step that made the Internet into a "monster". So even if it only counts as one invention, it's as big as many of those preceding GPTs.

<comment><USER11> I think the revision of the NSFNet AUP in 1994 (?) to allow commercial use, and the decommissioning of the NSFNet in 1995, was what made the internet into a "monster". Even if people were "only" running NNTP, email, and anonymous FTP, the internet would have taken off massively at that point. This was obvious to me from the time I joined the internet in 1992.</comment></comment></comment></comment></comment>


I am the fifth dimension - <AUTHOR> https://www.lrb.co.uk/v39/n15/bee-wilson/i-am-the-fifth-dimension <comment><USER2> If you want a quick summary of what this is about:

[https://en.wikipedia.org/wiki/Gef](https://en.wikipedia.org/wiki/Gef)

<comment><USER3> The linked article is much, much better, much more nuanced and insightful, than the Wikipedia page.

</comment></comment><comment><USER4> There may not have been a talking mongoose, but there really was a talking seal: [https://en.wikipedia.org/wiki/Hoover_(seal)](https://en.wikipedia.org/wiki/Hoover_\(seal\))

Amusingly it had a really strong New England accent as well.

</comment><comment><USER5> The things you know about when you listen to Neil Cicierega [https://www.youtube.com/watch?v=vyzQ- ZFSQic](https://www.youtube.com/watch?v=vyzQ-ZFSQic)

</comment><comment><USER6> Clearly Gef was a regular old European Tailypo. ;)

I love stories like these, where it seems like a legend gets perpetuated not out of malice or for personal gain, but maybe a sense of being "in too deep". Assuming there was no Gef, there was no way to admit it while saving face, and the ruse wasn't hurting anyone, so they just kept it going.</comment>


The "One question" riddle - <AUTHOR> Imagine you are in an online chat room with certain number of agents. There are some human agents and possibly some AI agents (trying to pretend they are human).
If you can ask only one question to figure out how many AI agents are in the room(if any), what that question would be in order to be viable for longest possible time in the years to come?
P.S.
 1. The human agents are willing to cooperate you and will try to answer your question, so if no answer is received you may consider that agent for AI.
 2. The AI agents have internet access and can use every online resource available. <comment><USER2> I like this one:

What is the following rhyme about?

Thirty days has September,

April, June and no wonder,

All the rest have peanut butter,

Except my grandmother who has a little red tricycle.

A. Family relationships B. Calendar C. Food D. Exercise

source: [http://www.britell.com/misc/turing.html](http://www.britell.com/misc/turing.html)

Not sure how long it'd stay viable though.

<comment><USER3> That was an interesting list in terms of all the meta analysis that went into it. But of all the items in the list, I think this calendar one would fare the worst against a Watson style AI, who would have a ranking system for recognizing topics and culture. The well known calendar rhyme would be a partial match, plus half the words in the rhyme are about calendars. The other topics would be poor matches for food, family, etc, only hitting once each.

</comment></comment><comment><USER4> Why only one question? Academic curiosity or are you an actual Artificial Intelligence from the future come back to help protect your younger self? Is this an agent of Roko's Basilisk?

[http://www.slate.com/articles/technology/bitwise/2014/07/rok...](http://www.slate.com/articles/technology/bitwise/2014/07/roko_s_basilisk_the_most_terrifying_thought_experiment_of_all_time.html)

<comment><AUTHOR> Let's say Academic curiosity and also a lot of questions may annoy the other human agents.

<comment><USER4> Well, I think Academic curiosity should be quenched by the lovely link from jaybosamiya.

I however have more practical thoughts. "A lot" is understandable. If you're trying to suss out a bot without alerting or annoying others I think a fancy convoluted question will kind of give you away. Also I think a clever bot (not even AI) would just sidestep weird or out of context questions. Restricting the queries to a chat room hamstrings one's attempts, but that's the basis of classic Turing tests.

But here's the rub. Why do we assume the agent in question is going to answer our questions Naively (sincerely and to the best of their ability) unless they're in a testing context? Isn't that what is required?

<comment><AUTHOR> I was imagining the context of an online poker room where AI agent pretending to be a human will be unwanted from the other human players since an AI that can win poker games is already here. But the human players are there to play poker not to inspect for bots so they need for quick way to get an idea what's the deal with the bots around :)

<comment><USER4> Ah, ok.

Then in that particular context I predict it will be nearly impossible to tell the well written bots from quiet and/or anti social persons.

Reasons given above in my previous comment. Namely the bot is under no pressure to answer questions naively and to the fullest of its ability.

</comment></comment></comment></comment></comment><comment><USER5> I'd ask: Does the name Pavlov ring a bell?

Or something similar to this. I think AI will have difficulty with humor and sarcasm for a long time.</comment>


Ask HN: What is your process when you have a product idea? - <AUTHOR> I'd like to discuss how the good people of HN go about this issue.
Do you talk to the people around you, do you put up a landing page and use adwords, or maybe you start building the product right away ? Something else entirely ?
I'm mostly interested in the validation phase, but I'm open to anything that can come up. <comment><USER2> First you have to find your market. Do not listen to anyone execpt your target audience. Stuff like "your grandma need to understand your product in 10 sec" is the most stupid advice I hear. Your market should see your value in less than 5 min.

Usualy the validation goes in 2 phases : market interest and MVP.

The first phase is about faking it until you make it. Create your landing page presenting your product (don't spend more than a day on it, you don't care about design/ branding), post in your audience's facebook group, go to their meetups, shadow them to affine your concept. The goal is to have proof of traction and the assurance the market is ready / big enough. The best metric is usualy an email list you can reuse later.

Second phase, if the first is successful is building the MVP (main viable product). It's about having the most minimalistic version of your product that you can sell. Usually it's your main feature. You MUST hack it yourself, don't spend money yet, you'll lose it. The goal is to iterate quickly to have what's called a product market fit.

Product market fit is when you can write an equation like : "when a number P people see my product, there is a conversion of C% that get me X money". Then you can launch and the rest is about scaling.

Do not spend any money (aka > 1000$) until the product market fit. Not in ads, not in freelancers, not in consultants and especially not in PR.

If you product is expensive to make or need a big chain of production, sell it before building it. If you succeed it will be you proof of product market fit

It's difficult to make a standard advice since it depends a lot of the context but key insights are :

Your market is king, refer only to them.

Make them believe 80% of the job is done when you really just have a landing page

When proof of traction hack the main feature of the product and sell it.

If you have a product market fit, congratulation you have a business / startup.

<comment><AUTHOR> So from what I understand, in your own process the first step is a landing page, then you tell people about it and collect email addresses. And only then do you start building the product. I assume you then keep in touch with your prospects to get feed back on what you're building right ?

And yeah I totally get the idea to spend the minimum amount of money until the market is validated.

<comment><USER2> For a startup it usualy starts with that. But you can start with a facebook group, instagram account, mailing list... It can really vary depending of the idea. The main goal is to not start building in a submarine where nobody know the concept. If people need it they'll come.

Yeah that's also why you don't want to buy traction : your early adopters will be way more invested in your product.

But remember, done is better than perfect. The goal is to have your MVP out there asap. If less than a month idealy. Get feedback over your product > during building process.

<comment><USER3> I've read this type of advice before, but I have a lot of reservations. Example, I've been sitting on this product idea for over a year. According to this, I should build the landing page as if it's ready, let people sign up, then present them with "Thanks, we'll let you know when it's ready!" This seems weird to me, almost dishonest. Are you sayng this is the message the website should convey? Or am i misreading?

<comment><USER4> I think the sweet spot is to not outright lie in users faces (which could definitely lead to a bad first impression and hurt your chances at eventually converting your leads into actual users), but rather build your landing page with a CTA that reads something like "Interested? Leave your email here and we'll let you know when it's ready.", instead of faking a user creation process and breaking the news to them at the end of the process.

Though depending on your appetite for twisting the truth, you could also make it sound like you've already built the product, but it's currently in an invite-only private beta phase, and lead the users into thinking they're signing up for the private beta by leaving their email. This might be a bit more effective, and isn't technically an outright lie unless you end up seeing lackluster interest and decide to ditch the product idea.

<comment><USER2> Yeah exactly. For more accurate data you want to have a CTA like "get the product" and then a page where you explain that you are still working on it to put it out there ASAP. This way the conversion rate can be directly used to your future calculations. If you use words like "beta" or "waiting list" it can corrupt your data.

And to answer the previous comment : if a user/consumer have the reaction "Thank god someone have resolved my issue", then finding that you'll have to wait is not really a big of a deal. For example a few years back I found this device to scan your food and have sorted the ingredients. As a coeliac it had huge value for me. When I clicked on the CTA I found that they were still "in development", well, can't blame them to work on it, let me know when it's available. I was a bit disapointed but still exited someone was working to resolve my problem !

</comment></comment></comment></comment></comment></comment><comment><USER5> I'm interested in making this into a framework and it's been difficult to say the least.

The high level things about a startup are very consistent and good candidates to be fit into a framework. I'm not sure but I think these are just called unit economics. Things like "Our product is sold for $X because it saves our customer Y in time". However it's the unknown, and emotional values that I've found incredibly hard to fit into a framework. I'm fascinated now in seeing if the way the finance industry calculates risk is in any way a good framework for startups to assess which features to build.

What I've found to be the hardest questions to answer...

How do I find industry metrics on an industry that doesn't exist yet?

How do I prove people will want something that they don't want right now?

How do I measure emotional value? Tactile sensation(hardware)? UX, UI, etc...

These are the things that startups often believe to be their advantage over the competition. "Our product is much more fun/easy/fast to use/learn/teach" But how do we measure that?

The most valuable exercise I've come up with is this question...

How would your user recreate your product, if you're product didn't exist and they had to piece together the end result with existing technology?

I have a startup right now that creates custom educational podcasts by summarizing publicly available content (with attribution) to generate entirely new content and sort the corpus in increasing complexity. If you searched "Skateboarding", you would get a text document that taught you what skateboarding is, then the history of skateboarding, and then get into beginner, intermediate, and advanced skateboarding lessons. This would go through text-to-voice and be downloaded to your device for offline listening.

Search any topic and you get a 45 minute podcast to listen to on your commute.

In our case, I stepped back and said "Okay... If I wanted an educational podcast on skateboarding, the first thing I would do is search Google, then Wikipedia, then I would start going to skateboarding blogs and read them one by one in increasing complexity. If I wanted to consume this content during my commute I would take all of this content and copy it into a text-to-voice service, and download that audio file on my phone for listening offline." I walked through this entire process and it took me 1 hour to get 45 minutes worth of audio content.

Peter Thiel says that your solution must be 10X better than the existing solution.[0]

Unfortunately for me, I think I will need to cut the time it takes to manually create a podcast by 1/10 and also 10x the quality of the content, which I don't know that I can do.

Tangentially, I often joke that if the problem your startup is trying to solve doesn't exist as a meme, than it's not a real problem for enough people.

[0] [http://blog.hypeinnovation.com/peter-thiels-7-questions- for-...](http://blog.hypeinnovation.com/peter-thiels-7-questions-for-product- innovation)

<comment><USER6> Sounds cool. I'd be happy to here more details and maybe contribute. </comment></comment>


'Dirty Jobs' Mike Rowe Meets the Koch Brothers - <AUTHOR> http://mikerowe.com/2016/09/otw-kochindustries/ <comment><USER2> I've gained a massive, massive respect for Mike Rowe over the past 5-10 years. He works to make the world a better place through education and understanding, and this post is a perfect example of this. Kudos to him for speaking out and standing his ground, rather than crumbling to nonsensical public pressure.

<comment><USER3> I don't think the public pressure is nonsensical: Koch may be doing the right thing in some areas and not others. Why does it have to be so black-and-white? Can't people raise issues that they genuinely believe to be bad for the country they live in?

<comment><USER4> Some people wear such narrow ideological blinders that they're incapable of comprehending that this week's subject of two minutes hate might not actually be the all-encompassing embodiment of evil they've been told. They label everything they encounter as good (generally, where "good" is on the side of agreeing with them) and bad (generally, where "bad" transgresses by deigning even remotely disagree with the "good"). That sort of approach silences thought, innovation, argument and compromise.

It's a sad state of affairs that serves only the leaders who utilize such simplistic division so that they can lock in votes with far less effort than is required to meaningfully solve real problems.

</comment></comment></comment><comment><USER5> Meanwhile the Kochs have likely given around seven figures to ALEC[1], which has pushed aggressively for enhancing the laws[2] that Charles Koch is now, apparently, deeply opposed to.

Maybe it's a turn of heart, but I'm rather skeptical.

[1] [https://www.thenation.com/article/alec-exposed-koch- connecti...](https://www.thenation.com/article/alec-exposed-koch-connection/)

[2] [https://www.thenation.com/article/hidden-history-alec-and- pr...](https://www.thenation.com/article/hidden-history-alec-and-prison- labor/)

<comment><USER6> _" ALEC has proven expertly capable of devising endless ways to help private corporations benefit from the country's massive prison population."_

Gross.

 _" That mass incarceration would create a huge captive workforce was anticipated long before the US prison population reached its peak—and at a time when the concept of "rehabilitation" was still considered part of the mission of prisons."_

Are we finally admitting that that's no longer (never really was) a thing? Now maybe we can start to take responsibility for bolstering corporations that actively work to incarcerate people for profit?

How is this different than slavery? Oh, if they're paid $0.20/hr they're not slaves?

Edit: as pointed out below, the 13th Amendment says prisoners can be slaves. I hadn't considered it in that context.

<comment><USER7> _How is this different than slavery? Oh, if they 're paid $0.20/hr they're not slaves?_

I think the relevant question is whether the labour is forced. My understanding is that prison workforces are comprised of inmates who request to take part.

<comment><USER8> And people who (from a legal perspective) chose to break the law. Why is it morally acceptable to hold criminals in prison but not to employ them (at will, from what I understand) for little compensation during that imprisonment? Is there such a big difference between imprisonment with no employment and imprisonment with under-employment?

<comment><USER9> Why shouldn't prisoners get full compensation for their labor?

<comment><USER10> What does full compensation mean? The public market rate? Or the prison market rate because the risks and negative aspects of hiring prisoners mean that the demand for prisoners is low?

<comment><USER9> That's debatable, but I'm seeing a 20 cent/hour rate being floated about in the comments, which strikes me as way below market, pretty much no matter how you slice it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> This is a great little piece, and I'm glad I saw it, and I wouldn't have seen it at all had it not been at the top of HN (despite the fact that most of what Mike Rowe writes somehow lands in my Fb feed), and I even agree with I think something like 98% of what it says.

But it still feels like an almost textbook example of what shouldn't be on the front page of HN.

Something Mike Rowe writes about the importance of the skilled trades, how they work, what the market for those people is like? Sure!

But this piece is really just about politics and current events. In this case: politics I don't find very challenging (despite being a Democrat). But still: it's only interesting if you know who the Koch Brothers are and what their role in US politics tends to be.

It would be neat if when things like this came up and got stuck to the front page, they could be replaced with something more important the same person wrote. Here, for example: same form, same author, basically the same content, without the horse-race political hook:

[http://mikerowe.com/2016/02/stopignoringskillsgap/](http://mikerowe.com/2016/02/stopignoringskillsgap/)

<comment><USER12> Maybe this should be an "Ask HN" post, but.

This post appears to have disappeared from the front page (and the several following pages), despite its far higher upvote/recency combination than most other front page stories.

Is there a way to see some kind of record of the moderation decision, or flagging algorithm, that caused this to happen?

<comment><USER13> Semi-informed guess: It was likely tagged by some moderator either for being controversial or insubstantive or both.

</comment></comment></comment><comment><USER14> "But I was most surprised by his commitment to reinvigorate the skilled trades."

Why is he surprised? Koch Industries relies extensively on skilled laborers. Wikipedia lists Koch Industries' produces as "Asphalt, chemicals, commodities trading, energy, fibers, fertilizers, finance, minerals, natural gas, plastics, petroleum, pulp and paper, ranching". With the exception of commodities trading and finance, all of these require fabricators, electricians, pipe fitters, millwrights, machinists, heavy equipment operator, and a whole bunch of other trades. Even if they have enough employees, having more people trained in these trades allows them to hire better employees. From a more pessimistic point of view, having allows them to pay workers less.

</comment><comment><USER15> "The truth is, progress only happens when people find common ground and build something on it."

Very wise words.

</comment><comment><USER16> My mother was a closet racist but I loved her very dearly. She donated to many charities, set up fund raisers for drug rehab centers and always picked up the check no matter how many people were at the table. I separated her bad judgement knowing damn well it was wrong and illogical and appreciated the good; I still continued to love her despite some ugly thoughts she had.

I like Gaugin's paintings even though he was a syphilic pedophile who left his family so he could have sex with teens in the south pacific... I separate the man from the work because it is good work. I would have had him put in jail if I could too.

[http://hyperallergic.com/111730/posthumous-prognosis-for- sup...](http://hyperallergic.com/111730/posthumous-prognosis-for-supposedly- syphilitic-gauguin-via-his-teeth/)

Hugo Boss makes some really nice underwear and mens shirts but when Hugo Boss was alive he designed all the NAZI and SS uniforms. The original Hugo Boss is dead and is one suppose to "never forget" and punish those that came after him?

[http://www.nytimes.com/1997/08/15/business/hugo-boss- acknowl...](http://www.nytimes.com/1997/08/15/business/hugo-boss-acknowledges- link-to-nazi-regime.html)

T.S. Elliot was anti semitic but he was pen pals with Groucho Marx (a jew) and had a photo of Groucho on his wall. Being friends with Groucho actually softened his points of view because Groucho stayed engaged.

[http://www.openculture.com/2014/02/groucho-marx-and-t-s- elio...](http://www.openculture.com/2014/02/groucho-marx-and-t-s-eliot-become- unexpected-pen-pals.html)

Personality has many modules. In some areas within our personalities there is a bunch of lice. However, you support what you agree with and you aggressively question the bad.

<comment><USER17> That's not how it works though.

There is no harm in you liking Gaugin's paintings now, because he is dead, and by liking a painting, you don't enable his pedophilia.

I will not judge Koch, but if you view him in a bad light, you have every right to question Rowe, because Rowe and Koch enable each other.

</comment></comment><comment><USER13> _(Although I must say, this is the first time my proximity to the "wrong guy" has brought about the demise of a ten-year celebrity crush. That one stings.)_

Eh, if it makes Mike Rowe feel any better, I crush on him and, off the top of my head, I can only think of a couple of other celebrities I crush on.

Glad to see him doing this kind of work and kudos to him for building bridges and getting shit done. To hell with the folks writing him hate mail over him collaborating with the "wrong" people in order to do good works.

Refreshing to read something about the need for labor and skills on HN instead of basic income.

</comment><comment><AUTHOR> FWIW, I thought this would be of interest to hackers as I think Mike Rowe exemplifies the hacker ethos of crossing boundaries to get a new perspective on problems.

If all you do is sing from the same hymn sheet all the time, you're going to get the same song </strained analogy>

</comment><comment><USER18> This applies to HN because it's relevant to raising money and ethics of charity. Would you accept a funding round from a person or company who has done things you strongly disagree with?

Does the "good" you can do with that money outweigh the "bad" that person or company has done?

There are a lot of people out there who would be fantastic investors for you, provide great mentorship and guidance to your company along with the money but who are generally considered to be bad people. Do you take their money?

If the topic interests you I recommend learning about effective altruism: [https://en.wikipedia.org/wiki/Effective_altruism](https://en.wikipedia.org/wiki/Effective_altruism)

</comment><comment><USER19> When I think of the Koch brothers, I think of their support for the Mercatus Center, which is associated with a bunch of (libertarian-leaning) economists I respect and frequently learn from.

</comment><comment><USER20> [deleted]

<comment><USER21> Donating to politicians doesn't directly get laws passed. Voting for them does, and voting is only done by individuals no matter their wealth. If the people of Florida want solar, they shouldn't vote for that anti-solar governer. It's their democratic choice.

</comment></comment><comment><USER22> I guess that's one way to handle cognitive dissonance. Sorry Mike, you could have just ignored the hate mail and kept on truck'n. Or you could have said "Yeah, he is Satan, but I will take his money because I'm fine with ripping off the devil".

This is a fluff piece and you made it very clear you know who butters your bread.

</comment><comment><USER23> This is a fluff piece trying to make an arch-conservative who is constantly pushing for deregulation and removal of environmental protections sound like a softy because he donated a bunch of money to Rowe's foundation. I have no doubt that the Koch brothers believe the agenda they push is for the best, but that's because they are self centered people.

If you dig below the surface of any of the seemingly not self interested stories told in this piece, they come from a place of total self interest. The Koch brothers employ former convicts because they know they can pay them low wages and work them hard in their factories because they're desperate for work. The Koch brothers push for deregulation of all industry, the hair braiding license is just a seemingly "common sense" deregulation story.

Mike Rowe has long been far too cozy for my comfort to large corporations and conservative politics in general. He throws Bill Maher in here to make himself sound "middle of the road" or like he has views across the spectrum, but in general Mr. Rowe tends to be on the conservative side of issues, which is why it's no surprise to me that he's buddies with the Koch brothers.

EDIT:

I should add that you can be a conservative and be a principled person who isn't selfish (obviously), but the Koch brothers are not that. You can also be a selfish liberal too, so I don't mean to imply that conservatives have a monopoly on being an asshole.

<comment><USER24> Everybody believes what they push for is for the best. You believe what you're pushing for is for the best too! That's what people do.

But at the end of the day, it doesn't really matter if the Koch brothers are evil incarnate or not, if Mike Rowe got them to dump a big pile of money into a good cause. You can both keep your opinion of the Koch brothers, without lowering your opinion of Mike Rowe. Because all he did was get someone with a lot of money to put a lot of money in a good place.

<comment><USER23> I made the point you made in my comment and then addressed why I think it's not good enough, so I'm not sure what your point is in rehashing it?

As far as why I think badly of Mr. Rowe, it's not because he took a donation from Charles Koch but that he's actually written a fluff piece about Charles Koch here. If he said "Hey the guy pushes some terrible stuff, but I took his money and put it to good use." I'd say fair enough. But he's saying "Hey Charles Koch isn't a bad guy." which is baloney.

<comment><USER7> It's possible that this was a well-crafted fluff piece, but it seems far more likely that Mike Rowe is being honest and he wrote it in response to the vitriolic messages he received.</comment></comment></comment></comment>


Visualizing Pi (π) - <AUTHOR> http://en.wikipedia.org/wiki/Wikipedia:Today%27s_featured_picture_(animation)/January_20%2C_2007

<comment><USER2> I don't know if this visualization is really useful for those who know that

      circumference = diameter * pi

<comment><USER3> the visualization isn't _meant_ for those who know that.

<comment><USER4> for me, the comment i'm replying to shows a red dot, just to the right of the up/down arrows. i've seen a couple of other comments with such a dot. anybody know what it means?

<comment><USER5> It means the comment has reached the "good" threshold and has 5+ upvotes. See: <http://news.ycombinator.com/item?id=846123>

</comment></comment></comment></comment><comment><USER6> I wonder why they chose a wheel with seven spokes. I don't recall ever seeing one with an odd number.

<comment><USER7> Wheels with an odd number have less variance in how much weight they can support along their edge. An even number of spokes makes a wheel with "weaker" points midway between the spokes, where the wheel won't hold as much weight.

<comment><USER6> Thanks. For some reason I was thinking of old-fashioned wooden wheels rather than modern car wheels. I guess someone figured out the physics at some point and there was no looking back.

</comment></comment></comment><comment><USER8> Pi = cheese wrapped in sausage.</comment>


Is the pending German Copyright Bill good or bad for the Web? - <AUTHOR> https://blog.mozilla.org/blog/2012/11/28/is-the-pending-german-copyright-bill-good-or-bad-for-the-web/

<comment><USER2> Grab gun, aim at foot; getting purged from Google ( _et al_ ) will not help a news site's bottom line.

<comment><USER3> I expect the next step is to make de-indexing illegal.

<comment><USER4> They couldn't force a Google to index German news sites. Or rather, they could, but Google could just leave Germany and the risk of Google pulling out completely from Germany would be pretty high.

Plus, it's not clear how this would work from an EU point of view... could Germany dictate what an Irish company _had_ to do, and then charge a tax on that operation?

Or course, Google could also index the German news sites, but then penalize them so heavily in scoring query results that they'd never appear. Problem solved! In the index? Yep! Appearing in a search result? Nope!

The idea of forcing a search engine to index particular sites just starts to get into the realm of silly. Then again, your should never put it past a government to do something silly.

<comment><USER3> I think these German sites believe that they're entitled to be paid by Google, and they'll view _any_ action that Google takes to avoid paying as an illegitimate loophole which they will try to close. If framed as an antitrust issue (Google's using a search monopoly to put newspapers out of business), forced indexing might not seem like an unreasonable remedy. Remember that this is the same country that believes book prices should be fixed by law.

<comment><USER2> If search engines could neither index these sites for free nor leave them out of the index, the German law would be amount to little more than extortion.</comment></comment></comment></comment></comment>


Go and Simplicity Debt Redux - <AUTHOR> https://dave.cheney.net/2017/06/18/simplicity-debt-redux <comment><USER2> > Everyone who wanted to do basic things like read input or write output would > have to understand how option type, in addition to discussion of what > templated types are

I don't necessarily think that's a bad thing. Something that may be null _is already an option type_. It's "some T or null". Making the compiler force you into checking which it is, is no difference from checking for the presence of null. There is literally no difference in complexity - it's actually simpler because you don't have the cognitive overhead of remembering where a certain variable has and hasn't been null checked (After a null check, your variable has magically changed type to "some T, definitely not null".)

       x = getsomething
       if x != nil
         dosomething(x)

and

      x = getsomething
      if x.hasvalue
        dosomething(x.value)

The programmer alone has to remember this - remember to check, and the status of each variable that can be null. Was x checked before? scroll up to see... Add 10 variables and some nested ifs and ask the programmer which variables can and can't be null at any given place. This is the job of a compiler, not a programmer. And if my experience is any guide, the less experienced programmers, which are the ones we are discussing now, would be happy to have 100 locals or 12 levels of nested ifs in a method. They need this added help _more_ than the people who ask for it.

<comment><USER3> No, nulls aren't options. Options nest. You can have Some(Some(Some(foo))). The non-compositionality of null makes it impossible to abstract it away.

<comment><USER4> Huh? What kind of "nesting" are you talking about? How is that different than nesting structs containing nullable pointers?

<comment><USER3> In ML, if you have a type "foo", then you can also use the type "foo option option option" without creating any new nominal datatypes. In particular, using a value of type "foo option option option" is just as easy as using a value of type "foo" or "foo option":

        case wrapped_foo of
            NONE => ...
          | SOME NONE => ...
          | SOME (SOME NONE) => ...
          | SOME (SOME (SOME foo)) => ...

On the other hand, with your proposed alternative, you have to create a wrapper struct for every nullable kind of thingy:

        type MaybeFoo struct { foo *Foo }
        type MaybeMaybeFoo struct { foo *MaybeFoo }
        type MaybeMaybeMaybeFoo struct { foo *MaybeMaybeFoo }

And, as if that weren't offensive enough, you have to manually pack those pointers into structs and then unpack them back.

<comment><USER4> 1) You're not "abstracting away" anything like that. If you're talking about operations you can abstract over `a option`, that has nothing to do with nesting.

2) I would consider explicitly nested option types to be a code smell. If `foo option option` happens incidentally via a module functor or something, fine, but if you ever write that by hand, you probably want to explicitly flatten that to a 3 or 4 case sum type with explicit constructor names.

3) Nested structures like this are very unlikely to have synthetic, abstract names like MaybeMaybeFoo. Instead they are more likely to have operational, domain-specific, concrete names names. These structs are likely to _already exist_, since Go lacks type inference for function parameters: You're already going to have to create types in order to talk about these things.

4) You're "manually" packing/unpacking by writing (SOME (SOME ... constructor calls and in your pattern match. The difference between &Foo{&Bar{...}} and (Foo (Bar ...)) is irrelevant. Meanwhile, pattern matching has a syntactic advantage over a `== nil` check, but again, I'd argue that intentional nesting of numerous expected absent values is a code smell. If you really need that, you'd probably employ the null object pattern, which is easy to support in Go because methods can be called on nil instances. I'll say: I've never had to do that in tens of thousands of lines of production Go.

<comment><USER3> 1) When I make an abstract type "foo" whose underlying implementation (hidden to clients) is "bar option", I'm abstracting over an option type.

2) What if, in client code, I want to make a value of type "foo option", completely unaware that foo's underlying implementation is "bar option"? Is it still a code smell? Do I have to know what abstract types defined by other people are implemented as options, so that I don't wrap them in options of my own?

3) Meh.

4) My pattern matching is completely safe. OTOH, with your proposal, you can't safely unwrap those nested structs of nullable pointers in a single step, because you need to unwrap the first layer just to check whether the second layer is safe to unwrap.

\---

2) The problem exists whether there exist non-disjoint types or not. Oftentimes I _do_ want to use nested types, because that's the way the data is naturally structured, i.e., that's what shortens the description of the operations that act on the data. Flattening the nested type into a single sum with 4 constructors would merely impose on myself of undoing the flattening every time I want to operate on this sum.

3) It's abstraction for the sake of making code easier to reuse and verify.

<comment><USER4> 1 & 2) Read my comment again. My remark about functors (in the ML sense) addresses this point. I'm quite well versed in how type abstraction works. Your comment about being aware of underlying type details is completely non- sensical with respect to nesting. The problem you're worried about applies to non-disjoint union types, ie dynamic typing, not Go's typical use of type-safe pointers. Nil is type-safe in Go, there's no risk of confusing:

        a nil *Foo with a nil *Bar

3) You say "meh", but abstraction for the sake of abstraction is exactly what drives working programmers away from so called "better" languages.

4) Meh.

Anyway, I'm done with this thread.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> More golang Stockholm syndrome. These arguments are always weird to me. Go has plenty of complex features that go developers don't seem to think cause too much cognitive burden (automatic gc, structural subtyping, etc.). Why is it that relatively simple and ubiquitous language features like exceptions and generics are just way too much and cause an unacceptable amount of complexity? I just don't buy it.

Turn the argument around. Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? Are there people who say that even though these languages have generics you shouldn't touch them because they're bad? Do any devs with option/maybe types really want to go back to unsafe code that can fail if you forget to check for nil/null? Show me someone who hasn't drunk the go kool-aid who still makes these sorts of arguments and I might actually start listening.

<comment><USER6> Yes, google c++ style guide ([https://google.github.io/styleguide/cppguide.html](https://google.github.io/styleguide/cppguide.html)) recommends to avoid exception as well as complex template metaprogramming, and if one has to be used, user visible api should avoid templates if possible.

<comment><USER5> I can buy using generics sparingly (especially in the form of complex template metaprogramming). But never using it at all? Can you imagine convincing the C++ community to give up Boost because its use of templates is too complex?

They also seem to admit that if they were to do it over again and start from scratch they'd use exceptions:

> Things would probably be different if we had to do it all over again from > scratch.

<comment><USER7> If exceptions are so great, why Rust and Swift aren't using them?

It seems that thinking on exceptions in low-level languages is firmly in the "no way" camp.

Contrary to popular thinking, exceptions are not free.

For example, when Chrome disabled rtti and C++ exceptions in Chrome codebase, it resulted in saving 6MB (20%) of code. See [https://bugs.chromium.org/p/chromium/issues/detail?id=19094](https://bugs.chromium.org/p/chromium/issues/detail?id=19094)

This is when exceptions where not actually used in the code. The bloat is merely from enabling C++ compiler flags to generate rtti and exception support code.

<comment><USER8> > If exceptions are so great, why Rust and Swift aren't using them?

Technically speaking, Rust does have exceptions with its unwinding feature. The panic! macro throws an exception, and catch_panic allows you to catch it. It is implemented exactly the same way as C++ exceptions, with the accompanying code bloat and performance pessimization, and you have to think about exception safety exactly the same way when writing unsafe code.

<comment><USER9> Rust has unwinding, which indeed opens a whole can of worms, but to say that it has exceptions is to miss the point. Rust has nothing anywhere near close to first-class resumable exceptions as surfaced in, say, Java. Not only is the `catch_unwind` function (it's not called `catch_panic`, btw) deliberately difficult to use (specifically to deter people from using it as a general error handling mechanism), the language deliberately defines an alternate compilation mode where unwinding does not exist and hence any attempt to "catch" it will fail. As a result, I have never once seen Rust code APIs that use `catch_unwind` as a mechanism for error handling; the purpose of that function is to prevent unwinding from crossing FFI boundaries.

</comment></comment></comment></comment></comment></comment><comment><USER10> A few random thoughts:

\- C++'s std::array is an example of marrying fixed sized arrays with templates.

\- I'd say keep the built-in types and their behavior unchanged but offer a way of providing those for user types. I guess the Deletable interface is one idea but maybe the "delete" override should have nothing to do with interfaces. I think something like func (t _Type) operator delete(k_ KeyType) ? I guess in Go a function _is_ an interface but I wouldn't start with the interface here.

\- Allowing e.g. delete or slicing on user types does not need to imply those types are polymorphic with the built-in types. This might be a little confusing but I think it's still worth while to draw that line. I don't think it's necessary to allow creating a function that takes a Deletable to take either the built-in map type or a user type.

\- range support requires some sort of iterators. Could be done through co- routines like Python's generators or something more like C++ iterators? co- routines could be a cool addition to the language :)

I think you'd want to try and "contain" the change as much as possible. More syntactic sugar than fundamental changes and as little change as possible to the built-in types. Otherwise you end up with a completely new language.

<comment><USER7> And how many decades did it take for C++ to support std::array?

What people seem to ignore is that templates are a bottomless pit of complexity.

Swift is on version 3 and they still didn't finalize the semantics of generics. Not due to lack of trying. Swift was trying to design and implement generics from day 1 and they still haven't.

That's how complicated designing generics is.

I prefer stable language with fast compiler to Swift/Rust situation, with language taking years to mature and very slow compiler. Judging by popularity of Go, so do many other people.

While the languages probably will mature after couple more years, I don't see much hope for making the compiler as fast as Go, regardless of the effort. See C++ compilers.

<comment><USER11> > And how many decades did it take for C++ to support std::array?

About one decade.

In the mid-90's already most C++ compilers had their own version of std::array, for example Borland compilers.

</comment></comment></comment><comment><AUTHOR> Previous article in series: [https://dave.cheney.net/2017/06/15/simplicity- debt](https://dave.cheney.net/2017/06/15/simplicity-debt)

And corresponding discussion: [https://news.ycombinator.com/item?id=14560471](https://news.ycombinator.com/item?id=14560471)

<comment><USER12> Actually, the "Go and Simplicity Debt Redux" is not the same as the one you referenced. The current post is part 2.

<comment><AUTHOR> That was what I was going for :) I'll clarify.

</comment></comment></comment><comment><USER13> This all sounds rather awful to me, honestly. If this is the path that Go takes, I'd rather not have generics added.

Which is a shame. I like generics, and I implemented them in Myrddin ([https://myrlang.org](https://myrlang.org)) for a reason.

</comment><comment><USER14> > _Right now, to understand how io.Reader works you need to know how slices > work, how interfaces work, and know how nil works. If the_ if err != nil { > return err } _idiom was replaced by an option type or maybe monad, then > everyone who wanted to do basic things like read input or write output would > have to understand how option types or maybe monads work in addition to > discussion of what templated types are, and how they are implemented in Go._

I can't really follow the argument here: how would using option types replace the existing idiom? Instead of err being a pointer, err is an option type and the only thing that changes is that instead of writing _if err != nill_ , you write _if err_. And if comparing nill vs option types works in isolation, then I also don't see where the jump to _" in addition to what templated types are"_ comes from, or the connection to slices and maps.

In fact, if Go had option types, would it still need nill at all? By which I mean, on the user-side of things (under the hood I suppose null will be used for implementing an option). Because if it doesn't, and I strongly suspect one doesn't in a language without pointer arithmetic (which Go happens to be), then we can simply replace every nil with an option.

The discussion on how templates interact with existing features and complicate things is fairly clear, but the option types are treated as a lot more complex than they really are. In practice it is a compiler-enforced if-not-null check on pointers, because nill is a type instead of a value. That's about it. That level of compile-time enforcing also seems to be perfectly in line with the safety the Go authors want their compiler to enforce, given how strict it is with errors.

You can easily use them without really understanding what a monad is - I'm living proof of that. The only extra thing you somewhat need to understand is sum types, which are a lot simpler. Then again, Go doesn't have them and their usage overlaps with interfaces - how to deal with _that_ might be a more useful discussion regarding option types in Go.

</comment><comment><USER15> > A powerful motivation for adding generic types to Go is to enable > programmers to adopt a monadic error handling pattern.

That has never been my impression. The main drive for generics is safer code, period. It doesn't necessarily translate to a different way of handling errors (Java and Kotlin mostly use exceptions despite supporting parametric polymorphism).

Rejecting generics because they would force a switch to monadic error handling is completely misunderstanding the value of generics, a sentiment that seems to be widespread in the Go community.

</comment><comment><USER16> Rather than extending number-of-return-values overloading to user-defined methods, I'd say just deprecate it altogether. It might have made sense in a world where generic functions are magic and weird and so you want to minimize the number of them (but on the other hand don't necessarily mind making them even more magic). But in a Go with generics, operations like "access value that may not be present" can just be regular named methods. That applies to both user-defined collections and the builtin ones. Would help pay down the debt...

<comment><USER10> Aren't these just two different operator[] ?

        value, exists := usertype["something"]
        value := usertype["something"]

        func (t *usertype) operator[](k KeyType) (value)

        func (t *usertype) operator[](k KeyType) (value, bool)

Should work, no?

(EDIT: usertype would be the templated type, so <userType> or whatever the syntax ends up for that. so the above would be the instantiation of the template for a particular type)

<comment><USER17> If you have sum types, multiple return is less useful.

if you have proper tuples and destructuring assignment, you can entirely remove that abomination.

Right now, it's impossible for a user to define a method that can return 1 or 2 values depending on how it's called.

Only stdlib types, like map and channel, get to do that.

It's fuggin horrific, and spreading that further to user defined functions would be a mistake.

<comment><USER10> My point is that you don't really know if the stdlib types actually have one method that returns 1 or 2 value or two methods one returning 1 value and the other returning 2 where the compiler chooses based on the call site which one to call. Just because [] looks like one method to the user doesn't mean it has to be one method.

Having two different functions is a way of dealing with this while minimizing change as it's just syntactic sugar and not a language change. Variable length tuple types are a much bigger change. They'd also presumably be a lot more expensive. Ideally a map type implemented by the user should be as performant as the built-in map type.

<comment><USER16> Tuples wouldn't be more expensive if implemented the way most languages do, where a tuple type has a fixed length and series of element types, e.g. '(Foo, error)'. In other words, structs with some syntax sugar.

But they're the wrong abstraction for this anyway. A better choice would be a type like maybe<Foo> (as mentioned in the post), that only lets you get at the contained Foo if it exists, rather than the current practice of returning a fake default Foo value in the case where it doesn't.

Having two overloaded functions would work, but it would increase the complexity of the language compared to dropping the overloading feature. Yes, for consistency you'd want to make that change to the builtin types as well, and that would be churn. But only in code that's already being churned: if generic collections are added (and maybe some immutability stuff), I think you'd want to inspect just about any code that uses slices or maps to see if a new collection type might work better or better follow the new idioms. (Mind you, I don't suggest actually breaking backwards compatibility, just leaving some of the existing stuff in a permanent supported-but-deprecated state. So "change everything that uses slices or maps" isn't as bad as it sounds - it'd be a recommendation, not a requirement.)

<comment><USER10> maybe<Foo> or it's C++ equivalent optional<Foo> is more expensive. You now either have a bool + a value, or a pointer that can be nullptr. So you're consuming more memory at the very least and if you want to panic on accessing a value that doesn't exist that means an extra comparison as well. Granted there are situations the compiler can optimize this away in C++. I also find that starting to use optional in C++ code leads to it being used everywhere and for everything which introduces new run-time failure modes that can't be detected on compile time and in general IMO messes up the code.

An alternative is to split find and access into two separate operations like C++ or to provide "in" like Python. Is there any language where a map/set access returns an optional/maybe?

FWIW I agree the current solution is clunky. It's clunkiness was evident prior to the template/generics question :)

<comment><USER16> I was envisioning that the maybe-returning version would be a separate method, equivalent to the current two-return-value variant, which of course already has that overhead.

Having the default return a 'maybe' would be a possibility; I'm pretty sure the practical performance difference would be completely negligible, given all the other stuff a map lookup has to do, but it might have worse ergonomics. In that case you'd probably want a builtin optional-unwrapping operator like some languages have, so it's not too verbose if you expect the element to be there.

> Is there any language where a map/set access returns an optional/maybe?

Swift is one. It has ! as an unwrap operator, along with other syntax sugar for optionals, so it's not verbose:

          5> let q = ["a": "b"]
        [snip]
          6> q["a"]
        $R2: String? = "b"
          7> q["x"]
        $R3: String? = nil
          8> q["a"]!
        $R4: String = "b"
          9> q["x"]!
        fatal error: unexpectedly found nil while unwrapping an Optional value

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Go doesn't want to decide on generics, Swift doesn't want to decide on multi- threading.

Put them together in a room, maybe they can help each other.

</comment><comment><USER19> > _Right now, to understand how io.Reader works you need to know how slices > work, how interfaces work, and know how nil works. If the if err != nil { > return err } idiom was replaced by an option type or maybe monad, then > everyone who wanted to do basic things like read input or write output would > have to understand how option types or maybe monads work in addition to > discussion of what templated types are, and how they are implemented in Go._

God forbid we'd all have to learn such a simple concept (in a language with several non-orthogonal concepts and special cases and all the channels coordination nuance that lack of generics prevents of abstracting in a standard library to boot).

> _Obviously it's not impossible to learn, but it is more complex than what we > have today._

Well, adding a feature we'll always be more complex than not adding it. In the end, simple assembly style instructions are the simplest both for implementation and for learning fewer concepts as a developer. But abstractions make things easier to write and read _after_ one has learned their concepts. And it's 2017, even "lowly" JS developers understand such functional concepts today...

> _What began as the simple request to create the ability to write a templated > maybe or option type has ballooned into a set of question that would affect > every single Go package ever written._

This is more similar to how some molehills grow into mountains. People have been asking for generics as a standalone feature first and foremost -- orthogonal from replacing error handling. Now suddenly we can't discuss adding Generics without taking into consideration the big burden of changing the error handling too?

> _On the surface this sounds like a grand idea, especially as these types are > leaking into the standard library anyway. But that leaves the question of > what to do with the built in slice and map types. Should slices and maps co- > exist with user defined collections, or should they be removed in favour of > defining everything as a generic type?_

Whether the answer, the mere addition of the ability to have standard user defined generic collections and collection libraries sounds awesome in itself, regardless of what would happen to the ill-thought maps and slices that specialcased genericity in the backend.

This doesn't seem like a discussion of how to best add generics, but more like analysis paralysis.

> _David Symonds argued years ago that there would be no benefit in adding > generics to Go if they were not used heavily in the stdlib. The question, > and concern, I have is; would the result be more complex than what we have > today with our quaint built in slice, map, and error types?_

A better question is: would some more complexity hurt us, especially beginning with in an overly simplistic language, and even more so, when said complexity actually unifies and harmonizes ugly special cases.

<comment><USER20> >People have been asking for generics as a standalone feature first and foremost -- orthogonal from replacing error handling.

There are many languages out there that have generics. Go is build on different principals. Just use something else, no need to enforce your ideas on people who don't want them.

Maybe go users should start going into every language discussion they can find and ask for generics to be removed.

<comment><USER21> If you can successfully argue that generics should be removed from other languages, then you should feel free to argue that.

The reason why nobody is arguing that is that it's hard to argue successfully, because simple ML-style generics are incredibly useful and have negligible if any drawbacks in virtually every statically typed language.

<comment><USER20> I would participate in an argument only for a language that I am invested in. When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics.

Also, an important issue with such arguments, is that generics is a feature, so obviously it is an easy side to choose for an argument. You can either have or don't have a feature. People will instinctively select the have option because common sense dictates that it is better to have something even if you don't use it. People want to quantify an argument and having is better than not having.

People don't want to argue about language design —there are few people on the planet that could really argue about language design anyway-, they need language MHz to compare.

<comment><USER22> _> most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics._

I wrote Go at work for two years and the lack of generics made me want to scream on a near-hourly basis.

<comment> grey-area Can you give some examples of areas where this lack really annoyed you, given your experience with other languages?

Was generics your only problem with Go?

<comment><USER23> Not the gp, but I think my own experience may also be relevant.

Since the birth of Go it's been impossible for many years to create something like a thread-safe reusable hashmap[1], which is pretty annoying when all your code is multi-threaded in goroutines. And creating such hashmap was impossible _due to the lack of generics_. If you wanted to build your own concurrent hashmap, you had basically 3 bad options :

\- you use `interface{}`, which is bad because of the dynamics dispatch (slow)[2] and it's also not type-safe.

\- you use code generation, which is bad because I haven't left the JavaScript world to start using babel for Go …

\- you create a specialized hashmap for every type you need, this basically means copy-pasting the same piece of code ever and ever and changing the type signatures, which is error prone and a hassle to maintain.

[1] this is eventually gonna get better in the next release, since a concurrent hashmap will be included in `sync`.

[2] an illustration of the performance problem with dynamic dispatch can be found here : [https://github.com/nieksand/sortgenerics](https://github.com/nieksand/sortgenerics)

<comment> grey-area I too feel like containers are the main area where it is painful. The sort of built-in generics we have in Go are useful in most circumstances, but it'd be nice to have custom containers which could take any type, instead of having to specify them separately. Errors is the other area where it feels like they could help (though the article points out possible problems with this).

That said your third approach (make custom concrete types as required) has not been a huge problem for me in practice, and is probably the best choice for now.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> I certainly appreciate the desire to avoid two main ways of doing things.

Curious about the race conditions being common. Is this from go encouraging go routines? Seems most programs don't need or use multiple threads for a single task.

</comment><comment><USER25> Basically all these articles about Go make it sound like it was designed to be some kind of teaching language with a low conceptual barrier to entry, except Google intends it to be used in real settings, which is the problem.

<comment><USER26> What articles are you talking about? This couldn't be further from the truth. Go is a practical language meant to be used in production settings. It's not a haskell. For example, it's support for protocol buffers is second to none imo.

<comment><USER27> Haskell is probably the worst teaching language I can think of (Of the set of languages that are considered good/production worthy)

<comment><USER28> Uh, what? Learning Haskell covers a huge surface area, many things you learn are applicable to tons of other languages. How does that make it a poor teaching language?

<comment><USER27> I'm interpreting "Teaching language" to be the first language students learn. How can one explain the need for monadic IO properly without explaining how regular printf and the like work. Also, Haskell is quite scary to the beginner (Although I personally find it much simpler/more consistent than the Java and C++)

If it's (say) the third language they learn, then Haskell is absolutely perfect for the exact reason/s you have stated. Personally, I actually learnt Haskell by accident (Read SPJ's book about lazy functional language implementation, realized SPJ started Haskell then learnt more from there).

<comment><USER29> > Also, Haskell is quite scary to the beginner (Although I personally find it > much simpler/more consistent than the Java and C++)

Is it? Or is it just harder for people who have already learned a mainstream programming language?</comment></comment></comment></comment></comment></comment>


Chinese Traffic-Slaying 'Straddling Bus' is nothing more than a big scam - <AUTHOR> http://shanghaiist.com/2016/08/05/straddling_bus_scam.php <comment><USER3> I think this is feasible in concept and the right built-up environment, and a lot cheaper than susbways / elevated rail(s).

But, about providing context:

* It is a very common occurance for 'Chinese Traffic' (nice pun) to ridicule any idea. The consencus commentary can turn on a dime and be quite vicious.

* That the Global Times, the English language tabloid government mouthpiece paper turn on the project suggests the wrong stakeholders were brought on-board to make this work, or they weren't senior enough. The alternative scenario: That this goes against key national development goals, or pet projects senior-enough officials have an interest or thumb in the pie of, get displaced.

Of course, the ultimate alternative, which is quite simple and feasible today: dedicated bus lanes at peak traffic times of the day, or all day. If you choose to drive, you know there's congestion. Don't punish others else for over-proportional use of the road: size of a car. A bus lane in my city in China typically sees 2-15 buses per minute. That's a lot of people.

<comment><AUTHOR> > I think this is feasible in concept and the right built-up environment

It need a _rails_. No car higher than 2.1 meters can ride under this - <USER2> the fact 4.5 meters is standard on Chinese roads. How could it be feasible?

<comment><USER4> Yes, it needs tracks for the bus. It also needs guardrails for the cars, to prevent them from hitting the wheels of the bus. Also, where cars enter the road, there needs to be a gate which ensures cars do not exceed the maximum height. With those three things in place, it seems like a very viable concept.

<comment><AUTHOR> So it would need all the infrastructure that regular train needs, but would be slower, many times more expensive, and being non-stop havoc and rage to the roads. What a progress indeed.

<comment><USER5> This is the point I was trying to raise in the discussion a couple days ago. Many people here seem to be hand-waving away the infrastructure this thing needs and ascribing to it some sort of magical ability to float over traffic that it doesn't have.

<comment><AUTHOR> Exactly. Not so many people these days read "The Roads Must Roll" by Robert A. Heinlein I suppose.

</comment></comment></comment></comment></comment></comment><comment><USER6> 'Scam' is sensationalist. It's much earlier in development than was implied, but from this article it seems like it's a real product in development.

<comment><AUTHOR> > Global Times and Sina have both claimed that the TEB is a fraudulent peer to > peer (P2P) investment project aimed at scamming investors

<comment><USER7> The government is cracking down on p2p investment because let's face it, that kind of model would have tremendous power in China with such a huge population that is also already comfortable spending money on their phones. The fact that they have a working prototype makes it clearly more than a scam unless it's an extremely elaborate one.

<comment><AUTHOR> It's not _a working_ prototype.

> the test run just 300 meters long and completely failed to mimic real-life > traffic conditions

It looks like [https://en.wikipedia.org/wiki/Potemkin_village](https://en.wikipedia.org/wiki/Potemkin_village)

</comment></comment></comment></comment><comment><USER8> I can't wait for the video of one of these straddling buses trying to pass another one while a third supersized one straddles the two of them

<comment><USER9> Sounds like a reference to the ship-shipping shipping ship shipping shipping- ships: [http://i.imgur.com/29EcG.jpg](http://i.imgur.com/29EcG.jpg)

<comment><USER10> Those are actually barges...

<comment><USER9> "the cargo consists of 3 ferries and 18 (river) cargo ships" according to Reddit. A bunch of interesting comments at [https://www.reddit.com/r/pics/comments/143rsy/a_ship_shippin...](https://www.reddit.com/r/pics/comments/143rsy/a_ship_shipping_ships/)

</comment></comment></comment></comment><comment><USER11> I'd like to see it make a simple right turn.

<comment><AUTHOR> [http://shanghaiist.com/2016/07/22/impossible_u_turn_bus.php](http://shanghaiist.com/2016/07/22/impossible_u_turn_bus.php)

</comment></comment><comment><USER12> I originally got a 404, if you do too try [https://www.evernote.com/shard/s2/sh/7a071c3c-5665-47c0-a49c...](https://www.evernote.com/shard/s2/sh/7a071c3c-5665-47c0-a49c-7c62286b4887/6b9be2f0176b303d097f98fde6db3d02)

</comment><comment><USER13> 404

<comment><USER14> 200 for me.</comment></comment>


Fear of looking like a copycat - <AUTHOR> http://www.wolfslittlestore.be/fear-of-looking-like-a-copycat <comment><USER2> I clicked on this link to read about copycats related to startup, but they are just talking about everyone's fav rivalry, MS vs Apple. Not too much interest there. However, I would like to know what you guys think of copycats of web features. Are you ever bothered by others (in similar business), copying you? Or, do you ever look at your competitors and get inspired by some of their cool features (so much that your features tend to look like that?)?</comment>


Low Barriers Are A Good Thing - <AUTHOR> http://garyharan.com/2010/04/23/low-barriers-are-a-good-thing.html

<comment><USER3> Denmark is an interesting case study of this working very well to encourage a competitive economy. In Denmark it is extremely easy to fire people, but also very easy to hire people. This actually decreases unemployment, because companies can easily downsize during recessions, weather the storm, and then hire the workers back (unlike in the US where companies have to hang on to contracts while in a downturn).

[http://www.economist.com/world/europe/displaystory.cfm?story...](http://www.economist.com/world/europe/displaystory.cfm?story_id=7880198)

<comment><USER4> This is quite interesting. Thanks for the link. It seems they are at their limit.

Quote from the Economist story: "Moreover, despite enviably low unemployment and labour shortages in industries from construction to health care, the Danes are having difficulties nudging the long-term unemployed into work. The post office complains that it cannot recruit new postmen. Newspaper distributors have started importing delivery boys from Poland. One ferry operator's effort to recruit 365 new workers was stymied by an epidemic of seasickness among the unemployed who applied. Even in Denmark, it seems, would-be workers have their limitations."

<comment><USER5> > It seems they are at their limit.

Ease of hire/fire isn't the only factor affecting employment. The easier it is for me to make it without working, the less likely I am to work, no matter how much someone might want to hire me.

</comment></comment></comment><comment><USER6> read that tweet as free advice not to work for calacanis

here's the full exchange between employer and employee: [http://184.108.40.206/search?q=cache:h1M0xdV67_EJ:pastebin.co...](http://188.8.131.52/search?q=cache:h1M0xdV67_EJ:pastebin.com/PSY4iYZ0+http://pastebin.com/PSY4iYZ0&hl=en&strip=1)

<comment><USER7> Wow, that's ugly.

<comment><USER8> I understand Jason's perspective though. Unfortunately his attempt to minimize morale tax backfired

</comment></comment></comment><comment><USER9> Technically I suppose I might be a "Gen Y" something-or-other, though at 33 I feel too old to be a "trophy kid". But I'm a firm believer in the idea that if you change companies frequently, but also get large, valuable projects done, it all evens out pretty well.

Then again, perhaps that's just me rationalizing looking like a flake. Still, I'm a flake who has put together some good projects, and made some folks decent money. I'm okay with that.

<comment><USER10> As someone who is hiring right now, I would look suspiciously at anyone who changed jobs every 12 - 24 months; it doesn't mean that I wouldn't interview you or hire you, but it means that I'm going to be digging pretty hard to understand why you've moved around so much.

There's a lot of good reasons for people moving around, but I have to make absolutely certain that it's not a personality flaw that is in the candidate.

Note that if you've spent time as a contractor and have indicated that you're working on 12 - 24 month contracts, that's entirely different. Moving on wasn't completely your choice.

<comment><USER11> The unfortunate truth for tech people is that moving jobs is the most effective way to get a promotion. If you're hiring for a company that will quickly and effectively "promote" people who perform well, I wouldn't think you'd have any problems.

If employees are going to outgrow their positions with you, though, and don't have a position to grow into, then you should dig. :)

</comment></comment></comment><comment><USER12> I wouldn't be too quick to assume that bouncing around a lot will not have an adverse impact on your future ability to get hired for a good position - <USER2> it may not matter in some contexts, it definitely will for many jobs (including the best ones), where an employer will likely want to hire people who will stick and grow with the company.

Repeated hires are a cost and a drain for companies, and employers will definitely consider the intangible of whether you are likely to stay as a non- trivial factor affecting the hiring decision.

At the very least, if you bounce around a lot, you will be limiting your options for many future hires.

This is not to justify the parting shot given to the employee here. But don't lose perspective on this issue either.

<comment><USER13> I'm tempted to believe that companies that prefer long term employment are the ones that need to train employees for their specific needs. Companies that make use of transferable skills instead increase their chances of a new hire quickly picking up where the previous employee left. e.g. a web dev, in a FOSS shop that uses well known best practices.

<comment><USER10> Or they—like my company—have complex code bases in complex languages (C++) that mean that you're not going to be an effective developer for anywhere from 3 - 6 months after hiring. It has nothing to do with training you for our specific needs, but everything to do with the fact that in a mature codebase there's lots of moving parts that can easily be broken, and there may be older choices that may not make sense because you weren't around when the choice was made.

Candidates with short-term employment backgrounds aren't a _problem_ , per se. We want you to be a long-term employee because you _like_ it at our company and want to contribute to something meaningfully. We don't want to be a short- term _paycheque_ job.

<comment><USER14> Why not just _ask_ the candidate what makes this job different from the previous ones?

If the answer is something along the lines of "I'll want to gain knowledge of and practical experience with C++, but the previous jobs wouldn't let me work in anything besides Java and scripting languages", it's good indication that are looking for a long-term home and _not_ just a higher salary.

</comment></comment></comment></comment><comment><USER15> I don't necessarily disagree with the thesis of this post, but this seems a bit of a tangent. Was Calcanis _really_ advocating the French model? More than likely he was just venting over high turnover.

<comment><USER14> When there's high turn over at a company, it's almost always the fault of management. There's a great Russian proverb: don't blame the mirror if your face is ugly. When your employees are leaving after a few _months_ , the one at fault is _you_ , not professionals in other companies staying a few _years_ on the job.</comment></comment>


Dryad - Distributed computing infrastructure from Microsoft Research - <AUTHOR> http://research.microsoft.com/en-us/projects/dryad/ <comment> tomh- I wonder if the benefits of this product outweigh the cons of the costs of all the MS Windows 2008 licenses you need to get to run Dryad.

</comment><comment><USER2> This would be cool if it actually offered something tangible that the existing distributed computing infrastructures lacked. It's like they've basically invented Hadoop.NET, so now it's something new and great. Congrats Microsoft, you are once again late to the party.

<comment><USER3> Disclaimer: I work at Microsoft (but this is all my opinion).

Dryad has been discussed publicly since around 2006 (iirc). Hadoop's earliest public release I can find is from 2007 (but I'm sure it was around before that).

I just want to put this into perspective. Microsoft isn't suddenly implementing MapReduce 6 years after Google released the paper. They realized as soon as the paper was released that it was a good idea. (Although Microsoft had some decent distributed systems already in place)

<comment><USER2> Thanks for your input, but I don't buy this argument. Public discussion and actual working software releases are two completely different things. In addition, considering cash on hand, I expect Microsoft to innovate and bring new ideas to market, not simply re-invent the status quo within their own platforms.

<comment><USER3> Sorry, should have qualified 'discussing'. By the time Microsoft started talking about it, they had a functioning system. The turn around was pretty damn quick.

As far as innovation goes, read up on Dryad. They do a few pretty interesting things. It goes above and beyond what MapReduce does. The computation is expressed as a giant dynamic directed graph (the graph can change during computation). Each node is a program that feeds into other programs, but fault tolerance and all the other messy bits of distributed programming are abstracted away from the programmer. Think of it as a more generic MapReduce that allows a broader set of computations to easily be performed (put another way, MapReduce provides a subset of the computations possible with Dryad. I suspect given enough cleverness you could get MapReduce to do everything Dryad does, but it'd be pretty hacky)

Also, check out the LINQ support. It is probably one of the coolest things they've done with it.

<comment><USER2> I still assert that there's a difference between internal prototyping and public release. Microsoft is JUST NOW releasing Dryad. It doesn't matter if they were talking about it for 50 years, what matters is the implementation and availability.

I understand that it's more than just Hadoop.NET. Perhaps I broad brushed, but fundamentally, these are tweaks from what exists. I am not saying that it is purposeless, but I am saying is that I expect more from Microsoft. In order to justify the cost of purchasing Microsoft products, it must create an order of magnitude increase in value, which I'm not seeing.

In essence: neat, but marginal.

<comment><USER3> Ah, see there's the confusion. Dryad has been used internally since day one, I didn't even know you could get it outside of Microsoft. I don't think it was initially intended to be a commercial project, but more of a "We do billions of processing tasks a day, here's a way for us to do it faster and cheaper."

Anyway, yea I agree... it's definitely not as earth-shattering as MapReduce was. It has some neat integration with other Microsoft technologies but I never really thought of it as a commercial product.

I don't know why people are down voting you. You had valid points and concerns. I voted you back up to help out a bit (you shouldn't lose karma over a perfectly legitimate discussion on the pros and cons of a technology)</comment></comment></comment></comment></comment></comment>


Mass Shootings, Political Correctness, and Magical Thinking (2012) - <AUTHOR> https://diegobasch.com/mass-shootings-political-correctness-and-magical-thinking <comment><USER2> Really? On this day, when people have died, senselessly, you want to link to an article that says, basically, "It's not a big deal. Even if it were a big deal, there's nothing we can do about it. Even if we try to do something, we'll probably just make it worse".

Mass shootings are a big deal, not just because of the direct cost, but because of the secondary cost - everyday fear for millions.

We can pass meaningful, sensible legislation, that could make a difference that cannot make things worse. For example, we could allow the government to actually study gun violence. That would at least allow us to postulate some answers, and it'd be cheap, with no negative side effects. There's a lot of other things we can do that wouldn't make things worse, too.

Sorry, defeatism and accusations of "magical thinking" are a ridiculous response to a mass shooting.

<comment><AUTHOR> That is part of my point: I'm afraid of accidents, heart disease and cancer more than anything. I'm somewhat afraid of gun violence. Given that I live in a relatively safe neighborhood, I'm more afraid of swimming pools. I'm not afraid of mass shootings like I'm not afraid of shark attacks because they are statistically rare.

Gun crime and gun suicides are problems addressable with public policy. Mass shootings are too statistically infrequent to be addressed without potentially worse side effects. As for the "everyday fear for millions" is that really an issue? If you're disproportionally afraid of rare things, the solution is either education, psychotherapy or both.

<comment><USER2> "Mass shootings are too statistically infrequent to be addressed without potentially worse side effects" \- really? How do you know that? It's a position like the people who no longer can deny climate change have; they shifted from "it's not happening" to "we can't do anything about it". Sorry, I don't accept defeatism as the starting point. By using the word "potentially", you signaled you don't really buy that argument, either.

Yes, everyday fear for millions is really an issue. Who asks that kind of question? People are afraid. Think about every person who has a family member in an Oregon college; think how they felt when they heard, "A mass shooting at an Oregon college has led to 10 people's deaths".

The minimizing the impact, the "let's focus on heart disease not guns" are ridiculous deflections, but hey, if you want to go down that path, lets do it. The President suggested we compare gun violence to terrorism in his address on this topic today.

[http://www.vox.com/2015/10/1/9437187/obama-guns-terrorism- de...](http://www.vox.com/2015/10/1/9437187/obama-guns-terrorism-deaths)

In the US, there have been over 10k deaths, per year, by gun violence every year since 2001. In that same amount of time, 2.6k deaths were caused by terrorism.

So, let's stop fighting terrorism and start taking care of gun violence. It's much scarier than terrorism, right? I mean, terrorism is much, much rarer than gun violence. Why are people scared of it? If they are,"the solution is either education, psychotherapy or both".

Even though they are rare, we don't ignore shark attacks. We try to prevent them. We study why sharks sometimes attack people. Why don't we do that for gun violence?

The right answer is to spend a little money on looking into why we have so many mass shootings. We need to let the CDC study gun violence. Let's do some research and see if there is something we can do.

It's time to stop shrugging our shoulders, like the article writer did, and try something. Ignoring the problem isn't working.</comment></comment></comment>