Why I got kicked out of Seedcamp 2009 - <AUTHOR> http://blog.crowdstorm.co.uk/why-i-got-kicked-out-of-seedcamp-2009 <comment><USER2> From [http://uk.techcrunch.com/2009/09/21/seedcampweek09-recession...](http://uk.techcrunch.com/2009/09/21/seedcampweek09-recession- era-startups-emerge-blinking-into-the-light/)

"It's worth pointing out also that the slight ambiguity of past Seedcamp years has now gone. Seedcamp T&Cs now state that a startup cannot go into the programme unless they will take the investment offered. To remind you, that's 5-10% equity (stakes are flexible) for a 50,000 Euro investment. That's totally fine. They've assembled an awesome network of mentors. It would be a huge waste of everyone's time if a startup got all that great advice and then effectively threw it back in the faces of the organisers and didn't take the investment."

WTF?

I read that as saying teams _have to_ take investment if offered? Is that even legal? But why should "I just decided not to take investment" be " throwing it back in the faces of the organizers"?

Shouldn't each party enter a transaction because they think it is a good thing _at the point of transacting_? This looks like it is possible for a team to be saddled with investors they don't like.

( I could be completely off base. Please correct me. Thanks in advance)

<comment><USER3> from seedcamp site:

"It is important that if you decide to accept the invitation for Seedcamp Week, that you participate with the intention to accept a Seedcamp investment. We have streamlined this week and process to help entrepreneurs and speed up a historically unnecessarily lengthy investment process. As such we believe teams should provide the same good faith and participate with the intention of bringing Seedcamp on board as an investor."

<comment><USER4> How does one learn enough about the value of the seedcamp folks before seedcamp to know whether one would want their investment?

<comment><USER3> my guess: they don't.

but actually 5-10% stake and upper limit of 50000 should leave quite a bit of wiggle room...

<comment><USER5> It is extremely stupid, not to put too fine a point on it to accept any cat in any bag at any price. You need to _know_ your potential investor quite well before going with them.

That's also to the investors advantage, so to see a clause like this is a big red flag.

What if you really don't connect on any level and they still want a part of your company ? What if you feel you simply can not trust them ?

Better to have no deal than a bad one any day.

</comment></comment></comment></comment></comment><comment><USER6> Reshma outright told me that I had to leave the judging session as I had not put money into seedcamp, as had all the others sitting in that room. She asked me to leave before the next pitch began too. Mentors were not allowed in full stop.

<comment><USER7> According to Saul's post, you were not a mentor and you said yourself you were not an investor, so I don't understand the misunderstanding... Why were you there?

Is Saul's post true? Where's the ambiguity?

</comment></comment><comment><USER8> this kind of thing was why i moved from the UK to SV. the british culture is closed, there's a constant search for ways to exclude the majority for the benefit of an 'elite' minority. i found SV had no concept of the elite. could you ever imagine this kind of scene happening at YC?

there have been huge strides in the Uk scene since I left in '07 and it saddens me to see something like this happen.

<comment><USER9> this is exactly what happens at YC, I dont think anyone has demanded that they be allowed to sit in the yc interviews and participate in choosing the yc teams.

I think the confusion is over what the last seedcamp day is about, it isnt demo day, it is the interview process, seedcamp have just made the interview process more transparent and open to help others and not just the teams that get funded, which has obviously introduced some confusion.

Seedcamp holds 2 more open demo days along the same lines of YC, one at the middle and one at the end of the cycle

<comment><USER10> From what I understand, that's not the YC model at all. YC takes a bet on the team w/ zero prior coaching and the company can turn down YC - no obligation. If the company says yes, then dinners, coaching, etc. commence.

Clean, simple, no misalignment.

It seems that Seedcamp is goofy by front loading the deliverables but won't commit to the investment. That's awkward for the mentors and the companies that are accepted/obliged to take whatever deal is given to them.

That feels like a poor place to negotiate vaulation from, and a major misalignment for the non-investing mentors.

<comment><USER11> Saul Klein: "Y Combinator, by virtue of being in the valley, has a built-in network, a built-in infrastructure. In Europe, we got none of that ... We have a real problem of fragmentation, so Seedcamp was really trying to solve for that issue as much as anything else, bringing people together in a cohesive network." <http://tr.im/zLzH>

That's why there are lots of networking and mentoring events (local Mini- Seedcamps, Seedcamp week) up front that many dozens of teams profit from, even though only 5-7 receive an investment.

I'm sure the selected teams aren't actually legally obliged to take whatever deal is offered, at least it wasn't at all that way for us last year.

<comment><USER12> As I understand things, this was a change from last year, specifically because some of the teams rejected the terms that they were given in the past.

<comment><USER2> "some of the teams rejected the terms that they were given in the past."

If some startup founders rejected 50,000 Euros and great advisers, for a 5-10% share , there is something broken in the model. At least from the pov of the (vetted, chosen) people doing the rejecting if 50,000 Euros is not providing enough value they ae well within their rights to reject it.

Fixing the broken parts may pay off more than making arbitrary rules that people have to accept whoever puts up 50k Euros. This is like saying people have to accept jobs because "we put so much effort into interviewing you". Such rules are probably unenforceable anyway and make the proposers look like idiots.

<comment><USER11> Why would you say "whoever puts up 50k Euros"? Seedcamp Investments LLP does.

<comment><USER2> "whoever puts up 50k Euros" covers Seedcamp LLP.The key concept is putting pressure on people to accept.

My (simple) point is that people should be able to sign or not as they please, without psychlogical pressure to do so.

If people back off, figure out why and fix it vs "changing the rules this year" or whatever)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I can tell you for a fact that mentors were not allowed in that final day of presentation - only vc's and angels who had paid a large amount (50k+) into the "seedcamp fund" - whatever that meant. What you have is a project that is pitching as being a transparent ecosystem to help startups - when in fact it's just an investment vehicle milking the goodwill of advisors and mentors to serve the aims of those funds.

<comment><USER5> To put 50K into ANY fund is not a large amount, that's the little league (from an investors point of view).

From a startup point of view it is reasonably serious but for a single investor 50K is small, very small.

If a fund had an entry ticket that low I would definitely look elsewhere, I would be very worried about small time investors coming on board with very little experience and a risk profile that does not belong in the venture capital world, especially not the seed world.

<comment><USER13> The whole point is that there are a number of solid VCs with small stakes involved.

If it was operated by large investments by a small number of VC's, the model could provide problematic signals. Specifically, if those VC's get early and in-depth looks at these companies and choose NOT to invest, it would be a negative signal to other investors. By spreading this across a large number of VC's, this potential is diluted.

The investors in Seedcamp are well known and respected investors... they're not "small time" with "very little experience". And many of them are long-time seed investors.

<comment><USER5> A 'well known', 'experienced' and 'respected' investor would _never_ force their presence in a company onto a company that did not want them.

</comment></comment></comment></comment><comment><USER14> Bleating is easier than building.

It feels to me that there is something strangely self serving about this whole 'debate'.

Seedcamp was great and has done a huge amount to catalyse an early stage ecosystem across Europe. It takes a huge amount of energy to put something like that together. I think Reshma should get some slack here.

Someone got the hump because they were somewhere they shoudln't be then bleats bitterly about it and says their rules should change. If people feel that strongly about it, go and do your own thing and make up your own rules. The entrepreneurial community as a whole should benefit as a result.

<comment><USER6> You're missing the point - my post states that it is confused about whether it is an early stage open ecosystem to benefit everyone or actually just a way to benefit a closed network of investors with their "seedcamp" fund.

As a small note, I'm a serial entrepreneur with successful exits and an avid advisor, mentor, and investor in a range of UK startups.

<comment><USER14> I respect our achievments and don't doubt you meant well by being there although I am not clear what RIGHT you feel you had to attend. If you have such a big problem with what happened, perhaps it would have been better to speak to Resham privately after the event when she was less stressed and had more time to discuss. Instead, you started Tweeting to the world about the injustice and then blog about it thus stirring up a shitstorm totally out of proportion to the incident. By offering people a right to reply when they are actually running an event seems to demonstrate an inflated sense of importance.

I stand by my point that if you feel this is so wrong, and are no doubt an accomplished entrepreneur, then set up an alternative. I would be equally happy to support yours, or other quality activities that support the growth of the entrepreneurial ecosystem. <http://thebln.com> By making this such an issue, you run the risk of alienating some of the people and organisations that would be inclined to help.

<comment><USER14> Errm, that should have read 'your achievements' not 'our achievements'. None of the achievements in this Hacker News thread are anything to do with me.

</comment></comment></comment></comment><comment><USER15> > _What I hadn't seemed to realise (and I'm sure I'm not the only one), is > that this fourth day is where angel funds and VC's pay upwards of £50,000 to > attend (no kidding!)_

£50,000!? Can anyone else confirm this?

<comment><USER9> its a pretty disingenuous of phrasing it, the panel that sees the final pitches are limited to the people who have invested into seedcamp (or are part of the seedcamp team etc)

and while I am at it they dont pay for "exclusive access" to the startups plans either, there is an entire week at which you can ask the startup any questions you like.

whether having an open or closed investor day is the best solution I certainly dont know, but I am pretty sure the motives arent as insidious as implied

<comment><USER15> So it's like saying Sequoia paid $2 million to come to YCombinator's demo days?

<comment><USER9> actually those were bad explanations

its like complaining that I wasnt allowed in the room when pg / jessica interviewed and decided on the yc teams, there are 2 other events much more along the lines of demo day later on.

<comment><USER16> Your explanation does not seem all that accurate either.

What if pg/jessica had allowed a bunch of people to sit through interviews? Then, some administrative staff decides to kick out one guy.

That would be a more accurate description from what I read here(based on the OP + Seedcamp's response).

Philosophicals--like whether investors should be in the room or not--are totally irrelavant here. What matters is what was promised and whether Seedcamp broke that promise for one individual(for whatever reason).

It seems like Seedcamp has too many cooks in the kitchen. The whole idea of having "official" mentors seems to have backfired here. You have a mentor complaining that investors are treated better than them. The solution to that is to get rid of this whole "mentor" label.

You never hear much about weekly YC speakers. That YC keeps it a low key affair is telling I think.

<comment><USER9> reshma is not "administrative staff", she is the ceo

since the format is more formal than a sit down interview I imagine they didnt want to disrupt a team half way through a presentation to ask someone to leave.

<comment><USER16> That's even worse. A CEO should have better judgement and understanding.

It _sounds_ from Saul's post that this is part of the package for mentors and that Seedcamp was on the wrong.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Uninteresting! Financially oriented issues like these don't bother me at all. Who needs so much money these days when everything (services, hard- and software) is so damn cheap. I don't need anybody investing in our venture. I've got a part time day job which supports me at least up to the RMS standard of living. Who cares about all this bloated so called financial infrastructure. This is just distracting and I don't get it. Create something you love first - if you need some money beyond that for investing in your infrastructure or the likes then do the good old credit card bootstrapping. Should be enough. Don't hire people do it together with some capable people you trust and like to be with. I thought this place would be more about hacking than plain old "dirty" money. P.S. sorry for OT ranting but I couldn't resist, pipe to /dev/null if you please

</comment><comment><USER13> Saul Klein's response is here: <http://blog.seedcamp.com/2009/09/awaiting- moderation.html>

<comment><USER18> One big commercial with this content embedded in it:

"One quick factual point – of course mentors are able to attend the judging sessions, several did this year and have done every year. I think what happened yesterday was a pretty innocent misunderstanding – you came into the room mid-pitch and as you'd not been a mentor during the week, I guess that's why Reshma asked very politely for you to not join the session."

which Philip Wilkinson then disputes:

"Reshma outright told me that I had to leave the judging session as I had not put money into seedcamp, as had all the others sitting in that room. She asked me to leave before the next pitch began too. Mentors were not allowed in full stop."

What seems somewhat unclear is whether Wilkinson was a mentor or not.

</comment></comment><comment><USER19> To squarely address the concern about transparency: I think the model is highly transparent and has previously been well communicated.

The issue he raises, i.e. that the investors in Seedcamp are the ones choosing the winners on the final day of Seedcamp week, seems a fair arrangement: these investors have invested money in Seedcamp to provide capital for the winning startups. Hence they should have an input on where their money goes.

Note that investors do not pay to have exclusive access to Seedcamp companies on the final day. Seedcamp does not sell its services as a "gatekeeper". Instead, the investors have put equity into Seedcamp and Seedcamp invests in the winning startups. The amounts invested in Seedcamp are about 50K for individuals and 200K for institutions. Everyone is free to invest in Seedcamp (he should talk to them!).

Saul's point that the final day is closed except for the investors and invited mentors/advisers makes sense to me. It's a special day where the winners of Seedcamp are chosen, i.e. Seedcamp makes its investment decision. This needs to be a small session and behind closed doors.

Finally, any mentor or investor is absolutely free to invest in any company accepted to Seedcamp week or part of the final 6 - or indeed those that have been rejected by Seedcamp. You can invest before, during or after Seedcamp week. Everyone is totally free to choose where to put their money. The one exception is that as part of the selection process, Seedcamp does not want companies in Seedcamp week that already know they don't want investment from Seedcamp. Seems sensible.

So I guess this whole thing was just somehow handled badly or he was invited on another day and it wasn't really clear when that was. I am sure no one meant to "kick him out of Seedcamp". Part of the reason Seedcamp thrives is that there is this awesome network of mentors and advisers who aren't investors in Seedcamp and see the non-financial benefit of donating their time - for the ecosystem, for karma, for encouraging entrepreneurs, for improving startups. This is a completely voluntary process and mentors do it because it's fun. I think startups can benefit immensely from the advice, but I also find it hard to believe that any individual advice from a mentor can be measured in a potential equity return to Seedcamp and the Seedcamp investors down the road. The companies that deal best with mentors' advice are the ones that would probably have been successful anyway.

Disclaimer: I unfortunately wasn't at Seedcamp this year, so I also wasn't in the room when this happened. My employer, Atlas Venture, is an investor at Seedcamp. Usual disclaimer on personal opinion and the like.

</comment><comment><USER9> mentors arent allowed in the final sessions for logistical reasons, the line has to be drawn somewhere as to who can participate and the fund investors seems like an obvious line.

 _Firstly, I don't see why mentors are invited at all._

Most to all of the mentors have a vested interest in the startup community thriving, lawyers, marketers, investors and angels who were not part of the main fund but still get direct access to the startup, a phone call isnt going to help until you figure out who you are calling, thats where seedcamp and such events help

<comment><USER13> According to Saul Klein, mentors are allowed in.

From: <http://blog.seedcamp.com/2009/09/awaiting-moderation.html>

"One quick factual point – of course mentors are able to attend the judging sessions, several did this year and have done every year. I think what happened yesterday was a pretty innocent misunderstanding – you came into the room mid-pitch and as you'd not been a mentor during the week, I guess that's why Reshma asked very politely for you to not join the session."

<comment><USER6> That's completely untrue. AS the pitch ended, I was asked to leave. Reshma asked me "are you an investor in seedcamp?" - I replied "no, do I have to be?". Reshma: "Yes, everybody else in this room has paid to be here"

<comment><USER13> I don't have a stake in this argument... just thought it would be relevant to re-post Saul's reply.

</comment></comment></comment></comment><comment><USER20> Not many decent companies have come out of seedcamp. Mybuilder is the only success story.

<comment><USER13> Zemanta has done okay, getting funded by USV, at least.

<comment><USER21> Patients Know Best are going to be massive.

</comment></comment></comment><comment><USER19> /popcorn</comment>


Majority of Silk Road's Bitcoins may remain unseized - <AUTHOR> http://www.theguardian.com/technology/2013/nov/25/majority-of-silk-roads-bitcoins-may-remain-unseized

<comment><AUTHOR> From the article:

 _The researchers also report on the possibility that Satoshi Nakamoto, the pseudonymous inventor of Bitcoin, may have been connected to DPR. Nakamoto, who invented Bitcoin in 2009 and provided the computer power which ran the network for the first year of its life, stopped communicating with colleagues in 2010, and hasn 't been heard from since.

But the researchers find that one account, which sent a thousand Bitcoins to DPR in 2013, is linked through a string of high-value transactions to an account which has been active since 16 January 2009, and so Ron and Shamir argue that it is "reasonable to assume" that the account was owned by Nakamoto. They speculate that the transaction "could represent either large scale activity on Silk Road, or some form of investment or partnership"._</comment>


8tracks is going US and Canada only, blocking other countries - <AUTHOR> This is the mail I received on friday:
Hi there,
On February 16th, we'll change how listeners outside the US and Canada tune into 8tracks.
What are we doing?
We'll no longer stream from 8tracks' servers to listeners outside the US and Canada; instead, we'll offer the ability to tune into playlists on the 8tracks website via YouTube video playback. Unfortunately, listeners outside the US and Canada will no longer be able to stream playlists through the 8tracks iOS and Android apps.
Later this year, we'll offer listeners outside the US and Canada the ability to tune into all 8tracks playlists through an on-demand streaming partner's website and native mobile apps.
Why are we doing this now?
In the US and Canada, 8tracks pays royalties to local collection societies for every track we stream. While we've neither actively marketed nor directly monetized 8tracks outside the US and Canada, we're now seeking direct, global deals with record labels to allow our DJs to tap a full music library when curating a playlist; after all, many in our community no longer have local MP3 or AAC files from which to compile programming.
In order to ensure 8tracks' existence for years to come, we've concluded -- at least for now -- that delivering our programming to listeners outside the US and Canada through a licensed on-demand partner is the best path forward.
We remain committed to bringing 8tracks to a global audience so all can join us in creating and discovering playlists for every taste, time and place.
Best,
David Porter
CEO & founder, 8tracks
P.S. If you're an ad-free subscriber, click here for steps to request a refund. <comment><USER2> Oh, at least Canada is explicitly named. For many businesses, "north america = USA".

I haven't really tried 8tracks but most streaming media have a very limited J-pop selection and no South American genres (cumbia, waynos, etc) so I never use them anyways. Good luck though!

</comment><comment><USER3> Will that use more data?</comment>


Venezuela Default Almost Certain, Harvard Economists Say - <AUTHOR> http://www.bloomberg.com/news/2014-10-13/venezuela-default-almost-certain-harvard-economists-say.html <comment> matt-r Very telling that the expert quoted is a former employee of the IMF.</comment>


Capability Immaturity Model - <AUTHOR> https://en.wikipedia.org/wiki/Capability_Immaturity_Model <comment><USER2> Level -1 reminds me some companies I've known, except s/CMM/scrum/g, which leads me to a theory[1] about scrum that's formed in my mind that I haven't heard articulated elsewhere -- I'd be curious to hear reactions:

If you're an intrinsically motivated software professional, you're likely motivated by a number of different factors: creating a great product, love of solving problems, writing elegant code, the fun of building new things, making users happy, etc... (exact levels those matter vary by person.) You're probably _not_ intrinsically motivated by things like hitting sprint goals, achieving a certain velocity, meeting OKRs, etc... (Did you enroll in CS classes thinking "I'm so looking forward to hitting sprint targets!"?) Thus, all of these tend to amount to various forms of extrinsic motivation.

A problem with scrum, IMHO, is that it places these extrinsic factors front and center. Yes, the other things may still matter, but the stuff you focus on and _talk_ about week after week are the various scrum related ephemera. (One may include OKRs, which you may not discuss as often but which may represent another extrinsic factor looming in the background.)

There's some evidence to suggest that extrinsic motivation may dampen one's intrinsic motivation, and so a pet theory of mine is that, to the extent scrum does that, it has a certain deflationary effect on the overall morale of an engineering organization. It might be subtle, depending on the particular org and how scrum is implemented[2]. I didn't even notice it until I went to a place that didn't use scrum.

[1] I'm not strongly committed to this idea. It's just something rolling around my brain.

[2] Obviously, some orgs are better than others. I'm open to the idea that the above is more a reflection of "scrum done badly" than scrum itself.

<comment><USER3> A friend who is an agile advocate calls this "weaponized agile." The goal is not to produce a product, but to be able to boast "we're doing agile."

<comment><USER4> A lot of this happens when people lose sight of the goals of doing agile, and instead become focused (you might even say obsessed) with just the rituals involved- IE the daily standup, the burndown chart, etc.

These also tend to be the organizations in my experience where things tend to devolve quickly- standups take an hour, hard decisions aren't made in grooming, managers will go over the previous day's major fire and then beat up people over the fact that the burndown chart hasn't moved...

They get to put down on their resume that they are doing the trendy thing though...

</comment></comment></comment><comment><USER5> I thought this was a silly joke at first, but it's actually sort-of an attempt to capture actual organizational anti-patterns. I mean at some level assigning an "immaturity level" is silly. However, characterizing various pathologies of bad organizations is helpful.

I think I've actually worked in organizations that were at level -3. Sometimes this was a reasonable goal taken to an absurd extreme. For example, a reasonable Software Quality Engineering organization's goal would be to find as many bugs as possible in the software product, or in short, to try to "break" the product. Taken to an extreme, the ability of an SQE organization to exaggerate any concern about quality to such an extent that it manages to stop the shipment of the product because of quality concerns, can be construed as a success for that SQE organization. In the case I'm thinking of, the SQE org was basically obstructionist, because they got rewarded for that. It was amazing that we managed ever to ship anything.

</comment><comment><USER6> I've experienced level 0 and level -1 organizations. This is an only-serious approach to trying to understand dysfunction, and I like it quite a bit.

Managers, product owners, and marketers need to understand how computers work. There's no alternative anymore; folks are savvy enough that snake-oil products with questionable business value are not having the market penetration that they used to. The days of being able to simply mail a CD to folks are long past.

</comment><comment><USER7> That's a good Monday morning chuckle.

</comment><comment><USER3> I've worked at both level -1 and level -3 organizations. -3 is usually doomed because the organization is actively self-sabotaging and the money is going to run out quickly unless management identifies the toxic actors and gets rid of them. And that rarely seems to happen.

</comment><comment><USER8> at work we use Slack</comment>


Enjoy the lines at Disneyland? You'll love Elon Musk's idea for transit - <AUTHOR> http://www.latimes.com/opinion/op-ed/la-oe-dayen-musk-loop-20180527-story.html <comment><USER2> And, of course, unavailable in Europe ...</comment>


Ask HN: Should I start a business in 2020? - <AUTHOR> What are the reasons for/against starting a new startup in 2020? <comment><USER2> Yes.

This is probably a time witnessing the start of radical and lasting shifts. If you have a view on which ways certain markets will evolve in the future, and a solid proposition, and you can stomach the risk, yes you should.

This ^^ argument also applies in general. It is just that the present time is potentially the nascent stage of many lasting paradigm shifts.

</comment><comment><USER3> For: There is going to be a lot of second order post-epidemic/recession disruptions in all possible areas. So if you are lucky, you can find a profitable niche with potential for rapid expansion. It is actually better moment for starting new business then pre-pandemic.

Against: Risk, liquidity mostly..</comment>


I need a great programmer in Los Angeles for a startup - <AUTHOR>

I need a great programmer in Los Angeles for a startup.  Would anybody be interested?? I need help think its going to be huge.... Please contact me @ email@example.com  thanks <comment><USER2> Everyone thinks their idea will be huge. You will be better served by this community if you do the following:

1\. Explain your idea. Give enough info so a person can determine if they have any interest at all in helping you from reading the post alone. You won't find decent resources the way it's written now.

2\. Participate in the community a bit and establish some credibility. This account created less than an hour ago, combined with the very generic request, harms more than helps your credibility. The only way to overcome this is to provide the necessary info so you don't come across as completely naive.

3\. Assuming you're going to say something like "this is totally hot and unique and it's impossible for me to share it with the world..." --- well, good luck! Maybe give some background info on YOU and YOUR successes.

4\. Recognize that right now developers and designers are in very high demand and most of the good developers and designers are either fully utilized on their own projects or someone else's project that was able to sell them convincingly. If you expect to draw in these limited resources, you'll need to do the same.

This response is meant to help you, please take it as such. Good luck.</comment>


Former project lead of Zend Framework: ZF2 sucks and no one wants to use it - <AUTHOR> https://www.quora.com/Why-is-the-Zend-Framework-not-popular?share=1 <comment><AUTHOR> > Zend Framework became its own competitor

> So the end result is that Zend Framework is: > \- Complex and hard to learn > > \- Not backward-compatible with its own earlier version > \- Very slow</comment>


Show HN: Alternate Pocket (Read it Later) Reading List That Skips "Article View" - <AUTHOR> http://pocket.sveder.com

<comment><AUTHOR> A small app to "scratch my itch" - when using Pocket they insist on showing you their "article view" and not the original site on the first click, making you click again for the original. This alternate reading list shows you the original article on the first click.</comment>


FFFFOUND is closing down - <AUTHOR> http://ffffound.com/ <comment><USER2> What a massive pity. I really enjoyed seeing the irreverent but semi-curated imagery that got uploaded there (though, truth be told, Tumblr has been scratching that itch for me of late).

Farewell.

<comment><USER3> As a fan of FFFFOUND and a neofyte of Tumblr, any specific blogs I should be reading?</comment></comment>


Show HN: All About Machine Learning - <AUTHOR> https://allaboutml.io/ <comment><AUTHOR> Author here.

I've collected various resources about machine learning in one place including:

\- books (with prices, ratings, reviews, first/last edition years)

\- podcasts (ratings, number of episodes and date of the last one)

\- courses (prices, rating, duration, number of lessons)

\- communities (local and online)

\- events (conferences and local events - US-only for now)

\- articles

It's a good place for those who just starting with ML, but I'm hoping to get the attention of the experienced machine learners. All of the content can be sorted by difficulty level. I'm also working on button that will let you hide all the beginner's content.</comment>


Scientists devise algorithm to detect sarcasm - <AUTHOR> http://www.telegraph.co.uk/technology/news/7740955/Scientists-devise-algorithm-to-detect-sarcasm.html

<comment><USER2> "The Telegraph" missed a great headline opportunity:

"Scientists devise algorithm to detect sarcasm. No, really.'

Can somebody try to contextualize this articleby characterizing The Telegraph? There's the Times, the Guardian, the Mail and the Sun, but the relative merits of the British papers escapse most americans.</comment>


Dropcam and Nest Combining accounts – no opt-out - <AUTHOR> https://nest.com/support/article/Why-do-I-need-to-create-a-Nest-Account-to-log-into-my-Dropcam-Account-and-how-do-I-create-one

<comment><AUTHOR> Why it's an issue ?

I happened to use the same email address to create both accounts, but the users of each account are actually different (dropcam at the office, nest at home) - and I have zero desire for either sets of users to have access to the other.

Will likely have to change the account on one or the other. First world problems I know - but still something about this doesn't sit right with my entitled ass.

Email from them:

Please create a Nest Account

Hi,

Now that Dropcam is part of the Nest family, we're excited to add new features and improvements that will keep making your camera better. To take advantage of these upcoming features, we need you to create a Nest Account. It'll only take a minute. And once it's done, you can access both Dropcam and Nest using the same login info.

Create your Nest Account now >

Questions? We now have 24/7 customer support for all your Dropcam and Nest products. You can also check out our support article to learn more.

If you don't create an account within 30 days, we will automatically create one for you and you will be asked to update your password the next time you sign in.

The Dropcam + Nest team</comment>


What would stop a company selling lifespan expansions from ruling the world? - <AUTHOR> http://worldbuilding.stackexchange.com/questions/9365/what-would-stop-a-company-able-to-sell-lifespan-expansions-from-ruling-the-world

<comment><USER2> Nothing.</comment>


MS's dream of Windows on phones is as good as dead – and that's great for MS - <AUTHOR> http://www.businessinsider.com/microsoft-windows-phone-dead-2016-11 <comment><USER2> "By continuing to work on Windows 10 Mobile, Myerson says, Microsoft generally gets better at working with cellular devices and with ARM processors — the same kind of energy-efficient chips for smartphones that Apple has been using in its latest MacBooks, but that Windows for PCs has never fully supported."

T1 for the touch bar aside, does Business Insider think the new MacBook has an ARM processor?</comment>


Darcs' Theory of patches - <AUTHOR> http://darcs.net/manual/node9.html#SECTION00910000000000000000 <comment><USER2> Let me define pseudo-math to be the approach of making a few mathematical definitions and then proving only some trivial "theorems."

Theorem. The Darc's theory of patches is pseudo-math.

Proof. By definition. QED

<comment><USER3> Personally, I kinda like watching physicists get slightly peeved when you point out that their models could stand being a little bit more rigorous. I mean check out this paragraph:

"""I think a little background on the author is in order. I am a physicist, and think like a physicist. The proofs and theorems given here are what I would call ``physicist'' proofs and theorems, which is to say that while the proofs may not be rigorous, they are practical, and the theorems are intended to give physical insight. It would be great to have a mathematician work on this to give patch theory better formalized foundations."""

Which translates to: you know what, we both know this is all pretty much correct and if you think you need to spend a couple more hours (or days) setting down the mathematical foundations in excruciating detail be my guest, but I'd rather read a thousand papers on string theory.

I mean, I pretty much agree. After all, I studied computer science. We make physicists look pretty rigorous.

<comment><USER2> Formal computer science usually has more formal proofs than most branches of mathematics. Computer scientists will lay out an explicit proof by induction where most mathematicians will simply write "by induction". At least that's been my experience.

<comment><USER4> I found that to be quite the opposite. Having finished my CS degree and taken various analysis of algorithm classes I found proofs to involve lots more hand holding and shortcuts.

I'm working on finishing my Mathematics degree and proofs are much more vigorous.

<comment><USER5> Check out some papers on type theory. They prove the most trivial things in excruciating detail.</comment></comment></comment></comment></comment>


Google cuts Cloud Storage prices another 10% after Amazon S3 price cut - <AUTHOR> http://thenextweb.com/google/2012/11/29/in-response-to-amazons-price-cuts-google-cuts-cloud-storage-prices-by-another-10-for-a-total-of-30/ <comment><USER2> Google is basically telling Amazon: "You do _not_ want to play this price- cutting game with us".

It's a great strategy from Google especially if they think they can match any move from Amazon in this way, and if they can sustain it for a long period of time.

It's basically game theory, and at this point, Amazon would be smart to _stop_ cutting prices just for the sake of out-competing Google on price. And if they do that, Google might also stop doing it, because as in game theory, they know continuing an aggressive price war in this manner is only going to hurt both of them, because they are both very resilient and they won't take each other out in this way anyway.

Amazon, the market leader, trying to beat Google on price, would be like Coca- Cola trying to beat Pepsi on price, and racing to the bottom. Coca-Cola has learned a long time ago that it's okay if Pepsi is slightly cheaper. Same goes for Verizon and AT&T.

I think they will both still continue to cut their prices at a regular time period, as hardware prices fall, but only for the sake of _expanding the market_ and getting new classes of customers that otherwise wouldn't use their services, and not just to try and steal from each other.

<comment><USER3> I doubt people choose Google's Cloud Platform over Amazon based on price.

<comment><USER4> One of the main reasons I personally wouldn't choose Google over Amazon no matter how much they lower the price is due to the lack of a solid customer support. God forbid if something goes wrong, not only will I risk losing the Cloud account but also everything else linked to them including Adsense.

Also, Google has a history shutting down unviable services and as these competitive price cuts continues, it gets more risky to keep betting on Google.

<comment><USER5> A history shutting down unviable services is a glass half full. On the upside, it means they won't permit a service to limp on, viewing its customers as burdens and providing terrible service in the hopes they go away.

<comment><USER6> In either of those scenarios, migration off their services would become necessary. But if they keep it limping instead of cutting it off, that I think facilitates safer more cautious migration (if for no other reason, because it would give you more time to do so). In that respect, keeping the service limping would probably present the superior customer service experience.

</comment></comment></comment></comment></comment><comment><USER7> OP is showing the old prices for Amazon. New prices: <http://aws.amazon.com/s3/pricing-effective-december-2012/>

Google went to $0.095 a few days ago. S3 went from $0.125 to $0.095 per gig.

Google has undercut again by going to $0.085.

I like this very much. Hey Amazon, I heard Google also called your mamma fat, are you just going to take it?

<comment><USER8> Google responds to Amazon, but Amazon doesn't need to respond to Google.

<comment><USER7> Hey. HEY. HEY! We might switch, they don't know for sure, what? Ambiguity. Get with it. Amazon if you don't match the Google prices we all _might_ switch. Whatchagonado.

</comment></comment></comment><comment><USER9> As if in reply to my comment yesterday, Google continues to validate its service not by competing on quality or feature distinction, but by throwing gobs of cash at it, as they have done every other 'successful' effort outside of core search and Gmail.

Man, if only there was a single serious App Engine-compatible competitor, prices there would be at the sub-penny level by now given the fair value of that junk. Only it seems designed from the outset for this scenario to never occur, and so why would I trust my future forward compatibility to another of their cloud efforts (or the mercy of their customer support ethos)?

<comment><USER10> Chrome, Android, Maps, AdWords (or pretty much all their Ads products), YouTube, Analytics, Docs ... should I keep going?

<comment><USER11> While I think the grandparent is understating Google's success, it's worth noting that in your list AdWords comes under search (to me, at least), and the only other item that wasn't born out of acquisition is Chrome. Of course this is a perfectly rational strategy for Google and in the case of, e.g. Android, what they've managed to do with it since acquisition is remarkable. It's just worth remembering a lot of the successes come from spotting a startup on the rise and snapping it up.

<comment><USER12> This is a bit of a tangent, but at some point I find the "it was really an acquisition" thing becomes rather silly, as there is very little difference between hiring people specifically because of their experience and ideas in a product area and a startup of some people with experience and ideas but no actual product yet. Maps and Android definitely fall under that second group, as Where 2 essentially thought that web mapping was a good idea, but hadn't actually done it yet, and Android didn't release _anything_ until two years after acquisition, let alone ship an actual phone (which came a year after that).

There can be insight there (one great property of startups en masse is that they serve as a great experimental method for proving zanier ideas will work or market segments can exist if a product is made for them), but there does come a point where it's like saying Google's success in AI research is because they spotted AI researchers and snapped them up. Well...yeah, employees usually are hired for the job they were hired for.

Regardless, the original poster's criteria was "Google continues to validate its service not by competing on quality or feature distinction, but by throwing gobs of cash at it", which I think the GP's examples clearly contradict, as all of them have continued to gain quality (for some people's definition of quality) and feature distinctiveness.

<comment><USER11> It's definitely not black and white, and I called out Android for specifically that reason. I wasn't actually aware that maps was not a web product at all when acquired so you're quite right that it fits into the same category.

To take the tangent further off topic it's interesting to me that Google's greatest successes post-search/ads appear to be these strategic products. Not things that bring direct profits, but those that allow them to influence the major platforms (mobile, web). Committing key resources in this way speaks of long-term thinking that other companies could learn from.

</comment></comment></comment></comment></comment><comment><USER13> Amazon responds to Google by not shutting down successful new services and alienating users.

<comment><USER14> What free services has amazon ever provided?

<comment><USER13> Is this comment based on the assumption that because users do not pay for most of Google's services, they should have zero expectations about the availability and longevity of said service? If so, let me approach this from the reverse:

A company creates a service to generate revenue. Google provides numerous free services from which they show advertisements (or crowdsource free labor such as the google voice training system or google image search tagging "game") to generate revenue. Another company might charge for said service but not flood me with advertisements. Both companies make revenue from their service offering.

Why is it okay for Google to shutdown services (which either served their purpose or weren't profitable) but so unspeakable if another company were to do the same for a paid service?

Regardless if you agree with that viewpoint or not, at the end of the day, Google has a long history of creating products, gaining users, and shutting down those products. This history has made it extremely difficult for them to break into a market such as this one because quite frankly nobody trusts that the product will be around very long. The utter lack of customer service also makes it difficult to place faith in their systems.

</comment></comment></comment><comment><USER15> The only people who will switch are people/companies with a lot of data where it may be cost effective.

Most small developers will stay away from Google. Amazon offers a 12 month tier free. Google offers prices and terms that change with 30 days notice.

The AWS conference is still on with Jeff Bezos talking in half an hour. Anyone care to guess what his response to this may be?

</comment><comment><USER16> We've been at 7.9 cents/GB[1], per month, for a few months now, and neither google nor amazon is responding to our price point.

How odd!

[1] <http://www.rsync.net/products/pricing.html>

<comment><USER17> You're very much more expensive in the brackets below 10TB amazon takes around 10cent, you up to 24. Break even is in the bracket between 10 and 49 TB but after that amazon again undercuts you with 7cent/GB/month. With you I have to pay in advance and not by monthly usage - at least that's how I read your product page.

Now there may or may not be other reasons to choose your service (data center in switzerland is appealing) but according to your pricing page, you're only cheaper in a very narrow window.

<comment><USER18> > Break even is in the bracket between 10 and 49 TB but after that amazon > again undercuts you with 7cent/GB/month

did, i mean did.. did you graph and solve that mentally while browsing the pricing page?

<comment><USER17> No need to graph. They both list the brackets and the prices.

</comment></comment></comment></comment><comment><USER19> Really like the DRA concept from google - same durability, but reduced availability.

Comparing to reduced durability of Amazon RRS, it's a nice happy medium between the normal storage and Glacier.

</comment><comment><USER20> Sounds like a price war started between Google and Amazon. Good :) Hopefully other providers will join. BTW - you can compare cloud prices at <http://www.cloudorado.com>

<comment><USER21> do you know of a price comparison of s3 alternatives (not ec2)?

</comment></comment><comment><USER22> This is a great example of how competition is good for the customer.

</comment><comment><USER23> Can Google Cloud Storage be used to just store personal Backups? Getting started with the service it seems that it's really targeted to developers. Why can't Google build an interface and offer it as a backup solution.

Maybe that would compete with their other offer of Buying Google Drive storage for five times the price.

<comment><USER8> There are a variety of third-party backup apps. Many of them only support S3 and sometimes Rackspace, but they may add Google support now that it's cheaper. See [http://gladinet.blogspot.com/2011/11/google-has-been- providi...](http://gladinet.blogspot.com/2011/11/google-has-been-providing- cloud-storage.html) <http://www.zmanda.com/backup-google-cloud-storage.html>

</comment></comment><comment><USER24> Are these prices for locally redundant storage or for georedundant storage?

For reference, Azure's prices for those are 0.0931 and 0.125, respectively. I wonder if they'll be dropped as well in reaction to these changes.

</comment><comment><USER25> How can they drop their prices by 30% and still make anything? I was under the impression that the margins for S3 and Cloud Storage weren't that high.

<comment><USER26> Hardware costs drop over time. The servers they needed to power S3 cost more and required more power a couple years ago than they do now. It only makes sense that the price of the service continues to drop.

</comment></comment><comment><USER27> How easy is it to switch my usage to google from s3?

Right now i have a rails app that uses carrierwave to manage images and store them on s3.

All i needed to get s3 set up was two lines of config, a ruby gem, setting some heroku config variables to the api keys.

How easy is it to switch?

</comment><comment><USER28> Whatever happened to Google's Don't be evil! May be the effect died long back with all the law-suites against them.

Just nitpicking but the author is adding percentages when they clearly should not be.

<comment><USER29> How is that evil?

You are right about the percentages though. 20% + 10% = 32% not 30%. They actually cut a further 8.3%.

<comment><USER30> If you look at the actual old and new prices, it actually could be over 30% depending on how much you use.

</comment></comment></comment><comment><USER31> Price wars this never ends well, where have I seen this before...?

<comment><USER32> You mean always ends well?

<comment><USER33> No, not always. A bitter race-to-the-bottom always seems to lead to feature cuts, reduction in quality, etc.

It is for this reason I prefer a nice, friendly, slow price war. I guess you could say the kind of price war where it is in fact a _product_ war- price is only one of the many _battles_ being waged.

<comment><USER31> Yeah that was my view on it, although I can see if they slow down a bit this can be good for the customer. This all just seems a little too quick.

</comment></comment></comment></comment><comment><USER34> At the same price, I'll go with the one that is the first to eliminate any charges for get/put requests.

For public hosting of many smaller objects those gets add up fast.

</comment><comment><USER35> And thus begins the market exchange of bandwidth/storage.

This is nice because it also helps make it cheaper for startups and product development.

</comment><comment><USER18> Welcome to Cloud Pricing a´la Oil Pricing

The Confusement of Variable Pricing Throughout the Day

Storage is King

Datacenters are the New Parking Lots

Computation is the Future Occupant

<comment><USER18> ...unless Amazon matches Google and retorts "let's battle this out on agility, support, security, service"

</comment></comment><comment><USER36> If they had balls they'd make it FREE!!!1

<comment><USER37> they did and then they shut it down :\

</comment></comment><comment><USER38> OH NO SHE DIDNTTTTTT</comment>


Windows 8 App Growth Already Slowing - <AUTHOR> http://www.tech-thoughts.net/2013/03/windows-8-app-growth-already-slowing.html <comment><USER2> Shovelware is already a solved problem.</comment>


Why inexperienced developers often side-track technical discussions - <AUTHOR> https://gist.github.com/steakknife/6336719

<comment><USER2> Must be fun working with you. For anyone looking in the comments for the tldr; dont bother, just some "experienced" old fart venting about the kids having the same argumemts he had when he was younger. Complaining because they wont just take his word for it and have to have the argument themselves.

I too thought it might be actually about a discussion going off topic when juniors are involved and maybe a tip i did not know how to get it back on track.</comment>


Some notes on Rust - <AUTHOR> http://lambda-the-ultimate.org/node/5113 <comment><USER2> > Nobody seems be saying much about Rust, or if they are, the LtU search can't > find it. So I'm starting a Rust topic.

The reason I personally am silent about it is because there is an ongoing overhaul of standard io libraries. Honestly, my need to be adventurous dried up when I was left with few broken libs. Writing about Rust still has a risk of becoming obsolete and misleading quickly. Waiting for the _real_ 1.0.

</comment><comment><USER3> > There's a macro called "try!(e)", which, if e returns a None value, returns > from the enclosing function via a return you can't see in the source code. > Such hidden returns are troubling.

Strikes me as simply a very appropriate use of macros. Get tired of writing the same syntactic fragment again and again? Write a macro. Want to see what some macro is "hiding"? Look it up or expand it.

<comment><USER4> The issue is it makes it difficult to notice that a function might return when scanning through a function. Especially as it's in places that are looking for a value (e.g. assignment).

At the moment it's just return and try!, but people look to the standard library for what is acceptable. When the standard library contains a macro that can return, people will write their own macros that return. It could potentially be half a dozen different macros you need to keep in your head.

Personally, I go back and forth on it. Hopefully it will turn out fine.

<comment><USER5> > The issue is it makes it difficult to notice that a function might return > when scanning through a function.

What other solutions are there? The only other approach to error handling I've seen is exceptions (e.g., C++, Java, C#, JS…), and if you don't like `try!` because it is a "hidden return", you certainly won't like exceptions. At least with Rust's macros, I know that in the absence of one, there is no return; in the presence, there might be. Exceptions in most languages make no guarantee.

<comment><USER4> It's a trade off. For the trouble of exceptions I get nice benefits like stack traces (though there are proposals to add stack traces to Rusts error handling). There are times when I really like exceptions, and times (such as trying to trace through an execution path) that I'm irritated by them.

What other solutions are there? Well, you could make the return explicit:

        let z = try!(x / y, onerror = return)

There are obvious downsides, such as added verbosity, and the need to figure out keyword arguments in macros, and do you allow access to the error value etc. but at least I can grep for/highlight "return". It also makes the meaning of the slightly confusingly named "try" more obvious (again, I'm vaguely aware of proposals that would change the name).

I think ultimately try! is a good thing, but I don't think it's trivially "a very appropriate use of macros". It's a considered use given some difficult trade-offs.

</comment></comment></comment></comment><comment><USER6> Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the author saying there isn't enough syntactic sugar?

<comment><USER7> My experience mirrors the author's: it results in a lot of use of macros and case statements. These create a fair bit of cognitive overhead to discern what the program flow will end up being, and special syntax for unpacking values.

The broad use of case statements leads to one more odd problem - knowing when, and when not, to use a `;`. Explicit returns are frowned upon, they prefer the "results from the last expression" form of returns. The `;` results in an expression returning a different value and a different type. The type system will usually catch these errors and print a helpful "perhaps you should remove the ';' from this line" message, but it's an extra bit of cognitive overhead induced by case statements.

Ultimately, I think it's less about missing syntactic sugar, and more about the type system acting like an electric fence instead of a hedge in its efforts to guide the user to their destination.

<comment><USER8> Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this:

        fn foo() -> bool {
            true
        }

is preferred over

        fn foo() -> bool {
            return true
        }

But that's more of a style issue.

As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

<comment><USER7> > Explicit returns are not frowned upon. I don't know where you got that idea

From the docs:

[http://doc.rust-lang.org/book/functions.html](http://doc.rust- lang.org/book/functions.html)

> Using a `return` as the last line of a function works, but is considered > poor style

<comment><USER8> Yes. Which is what I said. "Using a `return` as the last line of a function works" is not the same as "don't use explicit returns."

<comment><USER7> So I should use `return` except when I shouldn't? This is the cognitive overhead problem I'm talking about.

The original context of my concern is the instance where the match statement makes up the last statement in the function (frequently the only statement in the function's immediate scope). Since the individual cases are not terminating the function early, to get a value out of a match statement you simply leave the last expression bare.

i.e.

        fn something... {
          match input {
          Ok(input_val) => {/* several lines of semicolon terminated code*/
                            output}
          Err(errval) => {/* several more lines of semicolon terminated code */
                  output}
        }

is correct, but

        fn something... {
          match input {
          Ok(input_val) => {/* several lines of semicolon terminated code*/
                            return output;}
          Err(errval) => {/* several more lines of semicolon terminated code */
                  return output;}
        }

is poor style, and

        fn something... {
          match input {
          Ok(input_val) => {/* several lines of semicolon terminated code*/
                            output;}
          Err(errval => {/* several more lines of semicolon terminated code */
                  output;}
        }

is an error.

<comment><USER8> > So I should use `return` except when I shouldn't? This is the cognitive > overhead problem I'm talking about.

No. Use `return` only when you _must_. If you want an early return in a function, then you need to use `return`. If you don't need an early return, then don't use `return` at all.

I can't remember if this was ever a cognitive load for _me_ personally. I don't think it was.

<comment><USER7> > I can't remember if this was ever a cognitive load for me personally. I > don't think it was.

Well, to be fair, it sounds like you're used to semicolons having special meaning (aside from separating expressions) from a previous language.

> As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I > love it.

It's worth remembering that most users of C, C++, Ruby, Java, Python, or whathaveyou are not used to the semicolon having special meaning. Since Rust appears to be primarily aimed at replacing C++, this is going to be a significant change which will likely trip people up for awhile.

<comment><USER9> I'm a C/Python person, and it did take a question on irc for me to get my head around how Rust does it, but now it seems so natural that it's a little irksome to look at some of my Python code :)

<comment><USER10> Ruby also does this, so if you want that natural feel in your dynamically typed language... ;)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: [http://blog.rust- lang.org/2014/12/12/1.0-Timeline.html](http://blog.rust- lang.org/2014/12/12/1.0-Timeline.html)) I wasn't expecting it to be picked up on Hacker News.

Rust is going to be very important. The ownership system is a major step forward in language design. It's a huge improvement over C/C++.

It's not easier to write than C++. Rust may feel clunky for people coming from Javascript, Python, Ruby, and PHP. Having to think about lifetime issues for mere strings is a new cognitive load. The big win with Rust is that most of the errors are caught at compile time. This is Rust's big advantage, but alien to scripting programmers. The Rust compiler report errors in three phases. First you get all the syntax errors, and until the syntax is perfect, that's all you get. Then you get all the type errors, and until the type issues are perfect, that's all you get. Then you get the ownership errors. Ownership is a global analysis; ownership problems involve at least two points in the program. The compiler produces good, but very wordy error messages. (Hint to Rust developers: put in a line length limit and word wrap for long compile time error messages.) If your ownership design is faulty, the result is likely to be "fighting with the borrow checker", because the problem isn't local, and just fixing the compiler-reported error will make the problem pop up elsewhere. The cleverness of the ownership system is impressive, but some programmers are going to feel like they're being hammered by it. Successful C++ programmers won't have a major problem with this. It may be tough on the Javascript crowd.

Rust requires some advance planning, which may be incompatible with "agile" development. It's also difficult to port code from other languages to Rust without rethinking the ownership and bounds logic. There is a port of Doom to Rust. It has a lot of unsafe code, because Doom's internal memory structures are not directly compatible with Rust's. Such problems will recur as big packages with delicate internals are ported over to Rust.

This is partly a documentation problem. The current tutorial ([http://doc.rust-lang.org/book/hello-cargo.html](http://doc.rust- lang.org/book/hello-cargo.html)) is relentlessly upbeat and glosses over too many of the hard problems. Once some third-party books have been written, that situation should improve.

<comment><USER12> Not easier than C++? I dunno, C++ looks like a clusterfuck of complicatedness. I'm mostly coming from F#, with some C. Rust's ownership system _just makes sense_ and seems to perfectly answer the questions I have when using C APIs. Rust, for me, looks a lot like what I've wanted when writing performance F#. I'd commit atrocities to have optional ownership in F#.

Every time I've fought with the borrow checker, it's because I've had a serious design or conceptual flaw. (Well, apart from syntax/compiler questions). Since you can derive most of the rules just by thinking about it, I find it grows on you quickly. I'll be very saddened if the borrow checker actually ends up being hurtful for adoption overall. Though I agree if you cannot handle pointers or think about memory, Rust will be difficult. So yeah, scripting only devs will have trouble. But! It's better than them writing the code in C.

Rust overall seems like that. There's less random stuff and things work mostly by thinking about safe, zero overhead abstractions, and what falls out from those mandates. Mostly.

Now, maybe if I was a modern C++ programmer, I'd find the effort about the same. OTOH, C++ systems don't end up as safe as Rust ones, so I'm not sure there's a perfect comparison to be had. Maybe that'll change as C++ has started catching up feature wise, but someone I doubt it.

<comment><USER13> Overall, I think Rust is easier to use than C++ but not easier to _write_ than C++. Writability is a specific facet of usability, which is hurt by strict upfront checks.

Writability is a worthy thing to improve: GHC's -fdefer-type-errors feature is a good example. I hope Rust improves its writability in the future.

<comment><USER9> I think just like other languages, writing Rust leads to a familiarity with what the compiler wants. Then you spend more time thinking about design and the problem at hand, and less fighting the compiler. I think Rust will ultimately be easier than C++ to write because while there are tricky concepts to master, there should be much fewer of them than C++ has.

<comment><USER13> I disagree. While you get familiar with what the compiler wants (certainly I did, after using Rust for more than 2 years now), it's just that Rust compiler wants more from you than C++ compiler does.

The number of tricky concepts largely do not affect writability, because you don't have to use them. The number of mandatory compile time checks do, because you have to pass them.

One way to improve writability is a mode to turn off some of checks while you are exploring. I already gave a good example from Haskell. When you are done exploring, you can turn on all the checks.

<comment><USER12> Hmm, so like a Rust flag like --allow-leaks or --corrupted-ownership?

It seems like editor support would totally dominate here. That is, realtime checking of lifetimes and autocomplete/inline errors should be a much bigger improvement in write times than some way to emit invalid code.

</comment></comment></comment></comment></comment></comment><comment><USER14> I don't have an account there so I'll comment here:

> In particular, allocating a new object and returning a reference to it it > from a function is common in C++ but difficult in Rust, because the function > doing the allocation doesn't know the expected lifetime of what it returns.

This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. References and lifetimes allow you to safely return pointers to _stack_ allocated objects. In C++, you'd have to do this:

      MyType value;
      my_function(&value);

When returning references, rust uses the lifetimes instead of explicit declarations to figure out where (on the stack) `value` needs to be allocated.

> Declarations are comparable in wordiness to C++.

Only at interfaces where the declaration also serves as documentation. Elsewhere, types can generally be inferred.

> Rust has very powerful compile-time programming; there's a regular > expression compiler that runs at compile time. I'm concerned that Rust is > starting out at the cruft level it took C++ 20 years to achieve. I shudder > to think of what things will be like once the Boost crowd discovers Rust.

Unlike C++, 1\. Macros from one crate aren't imported into another unless the user explicitly requests that they be. 2\. Macro invocations are clearly macro invocations. You never have to wonder if something is a function or a macro.

> The lack of exception handing in Rust forces program design into a form > where many functions return "Result" or "Some", which are generic > enumeration/variant record types. These must be instantiated with the actual > return type. As a result, a rather high percentage of functions in Rust seem > to involve generics.

How is this a problem?

> There are some rather tortured functional programming forms used to handle > errors, such as ".and_then(lambda)". Doing N things in succession, each of > which can generate an error, is either verbose (match statement) or obscure > ("and_then()"). You get to pick. Or you can just use ".unwrap()", which > extracts the value from a Some form and makes a failure fatal.

I agree that this is less than ideal. However, IMHO, this is better than Java and C++.

Java:

Libraries tend to bubble everything. This leads to long throws clauses in function signatures with unexpected exceptions. A user of these libraries often catches and ignores these exceptions when writing the first draft of his or her programs because they don't make sense (why handle IO Errors when using a collection?). And then, because his or her program works, he or she forget about the ignored exception cases turning them into silent errors.

On the other hand, in rust, you can only return one error. When writing a function that has multiple failure modes, this forces the programmer to think about the set of failures that can happen and come up with new error type. This doesn't force the programmer to come up with a _meaningful_ error type but it gives them the opportunity.

Additionally, like in Java, Rust programmers can ignore errors (`unwrap()`). However, unlike in Java, these ignored errors are not silent, they are fatal.

C++:

Exceptions are unchecked and everyone I've talked to avoids them like the plague. In the end, C++ exceptions end up acting like rust's `panic!()` because programmers don't check them but are used like Java's exceptions because programmers _could_ check them.

> There's a macro called "try!(e)", which, if e returns a None value, returns > from the enclosing function via a return you can't see in the source code. > Such hidden returns are troubling.

I agree that hidden returns can be troubling. However, in rust, only macros can lead to hidden returns, macros use a special syntax (`macro_name!(args...)`, and macros have to be explicitly imported.

> All lambdas are closures (this may change), and closures are not plain > functions. They can only be passed to functions which accept suitable > generic parameters. This is because the closure lifetime has to be decided > at compile time.

The first sentence is correct but the last two are just wrong:

        fn takes_a_function(f: Box<Fn()>) {
            (f)();
        }
        fn main() {
            takes_a_function(Box::new(move || { println!("hello world") }));
        }

The `Box` allocates the closure on the heap and the `move` causes the closure to capture by value. This means that this closure (`f`) can be moved freely without lifetime restrictions because it doesn't reference the stack. However, most functions that accept closures use generics and do any necessary boxing internally to make the user's life easier.

> Rust has to do a lot of things in somewhat painful ways because the > underlying memory model is quite simple. This is one of those things which > will confuse programmers coming from garbage-collected languages. Rust will > catch their errors, and the compiler diagnostics are quite good. Rust may > exceed the pain threshold of some programmers, though.

Rust is a _systems_ language. It exposes a lower-level (not simple) memory model because systems programmers need it. If you want garbage collection, you are free to roll your own (yes, you can actually do this in rust).

> Despite the claims in the Rust pre-alpha announcement of language definition > stability, the language changes enough every week or so to break existing > programs.

Re-read those claims. Alpha means fewer breaking changes and no "major" breaking changes not stability.

<comment><USER7> > References and lifetimes allow you to safely return pointers to stack > allocated objects.

This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee.

In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a lot of the compiler's restrictions, its akin to writing <language of choice> in Rust, which is frowned upon in any language. Recommending its use so broadly is doing a disservice to people who want to learn Rust.

> Only at interfaces where the declaration also serves as documentation. > Elsewhere, types can generally be inferred.

Except where they can't, and those locations aren't terribly consistent. The Rust designers have publicly announced their preference for explicitness over inference, and the language reflects that.

> On the other hand, in rust, you can only return one error.

This is not unique to rust, or any language really. You can only throw one exception at a time. You can only set one errno at a time. You can only return one `error` at a time.

> macros have to be explicitly imported

Except for the built in ones, which are the only ones referenced by the OP. Also, by placing the macro delimiter `!` between the name and the parenthesis, it makes the macro harder to scan for visually. I imagine that any editor will want to set up special rules to highlight these distinctly, and having special highlighting for the ones known to change the program flow would be beneficial.

> It exposes a lower-level (not simple) memory model because systems > programmers need it.

Low level memory _is_ simple: write to, read from, write to referenced, read from referenced. The OS adds one more major operation: get heap memory. Everything else is added by languages or libraries.

That said, Rust's restrictions on memory lifetimes results in more simplistic memory related code. When you have to jump through extra hoops to create a pointer which may be used beyond a single scope, and the compiler creates so much friction when you want to do anything with them in that greater scope, people will defer back to simplistic memory code.

I'm not certain if this is good or bad; it just is at this point.

> Alpha means fewer breaking changes and no "major" breaking changes not > stability.

Any breaking changes affect stability, affects documentation (Rust's library documentation is behind the actual code as of a week ago), and affect 3rd party libraries. The results of this is that if you're not Mozilla, there are significant barriers to writing Rust code right now, and I would not personally recommend learning or writing Rust right now to anybody.

<comment><USER15> > Except where they can't, and those locations aren't terribly consistent.

Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute).

> The Rust designers have publicly announced their preference for explicitness > over inference, and the language reflects that.

As the original author of the typechecker, I can state that the idea that we intentionally made the type inference less powerful than it could have been is totally false. It's always been as powerful as we could make it, except for interface boundaries (where type annotation is needed because of separate compilation anyway).

<comment><USER7> > Why aren't they consistent?

So, I went back to do a bit of research, and it's gotten better since this first bothered me, my apologies. My beef was with the `let x = vet::Vector::New::<i32>()` vs `let x: Vec<i32> = vec::Vec::New()`. Perhaps not the best way to word it, so consider this objection retracted. :)

> the idea that we intentionally made the type inference less powerful than it > could have been is totally false

Except for function definitions, where the types could be inferred from the function bodies, but are not:

[https://www.reddit.com/r/rust/comments/2bcof3/rust_type_infe...](https://www.reddit.com/r/rust/comments/2bcof3/rust_type_inference_question_functions_vs_closures/)

Plus (and this is more related to the complete lack of implicit type conversions), there are types everywhere in the program. I frequently can't write a number without having to append a type, even when the type has been explicitly defined previously.

Here's one of my favorites from a recent attempt to write a ray tracer:

        let mut s: Vec3<f64> = Vec3{x: 0f64, y: 0f64, z: 0f64, w: 0f64};

<comment><USER16> The default types for bare literals is described in RFC #212 ([https://github.com/rust-lang/rfcs/pull/212](https://github.com/rust- lang/rfcs/pull/212))

To summarize: bare FP literals default to f64, bare integral literals default to isize. (NOTE: isize is recently renamed from int. It is a pointer-sized integer.)

(EDIT: The default for integer literals may be superseded by a later RFC. I seem to recall that the default is actually i32 now, but I can't find a PR to back up that claim.)

So you could easily get a Vec3<f64> like so:

        let mut s = Vec3 { x: 0.0,  y: 0.0, z: 0.0, w: 0.0 };
        let mut t = Vec3 { x: 0f64, y: 0.0, z: 0.0, w: 0.0 };

The key here is that integral literals and floating point literals are distinct.

A bare literal of the form `0` is an unconstrained integral literal.

Whereas a literal of the form `0.0` or `.0` is an unconstrained float literal.

In practice it is very rare for me to annotate my numeric literals. If the variable escapes the stack frame it will be constrained by the signature of the function anyways. If not I constrain the type inline (`let x: T = ...`) and use the appropriate bare literals.

<comment><USER10> You are right that this changed, but I can't find it in the RFCs either. [https://github.com/rust-lang/rust/pull/20189](https://github.com/rust- lang/rust/pull/20189) implemented it. And it is what everyone agreed upon.... hmm

<comment><USER10> Found it! [https://github.com/rust- lang/rfcs/pull/452](https://github.com/rust-lang/rfcs/pull/452)

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> > In particular, allocating a new object and returning a reference to it it > from a function is common in C++ but difficult in Rust, because the function > doing the allocation doesn't know the expected lifetime of what it returns.

I'd like to see a code snippet explaining this problem.

<comment><USER18> Yeah, it's unclear what he's talking about there. Normally when a function allocates a new object, it would want to return it by move (transferring ownership), rather than by reference. That doesn't involve any lifetimes.

        fn make_a_foo() -> Box<Foo> {
            Box::new(Foo { a: 5 })
        }

If the function allocated memory and only returned a borrowed reference, who would be responsible for freeing it? Yes, Rust will make you stop and think there, as it enforces memory safety.

In cases where it does make sense to return a reference to a new object, like allocating from an arena, the lifetime ('a) of the returned reference will be the same as the lifetime of the arena.

        fn new_from_arena<'a>(arena: &'a TypedArena<Foo>) -> &'a mut Foo {
            arena.alloc(Foo { a: 5 })
        }

But Rust can infer the lifetime, so that can be shortened to:

        fn new_from_arena(arena: &TypedArena<Foo>) -> &mut Foo {
            arena.alloc(Foo { a: 5 })
        }

<comment><USER19> Any reason you would ever want to return a Box instead of just a Foo, which the caller can then put in a Box if so desired?

<comment><USER20> I can think of a case: when you want to return a type whose size is not known at runtime (a "dynamically-sized type" a.k.a. DST), then you need to stuff it behind something else whose size is known so that the compiler can statically determine how much memory to allocate before calling your function. You could use a reference for this task, but only if, as per Rust's usual rules, you have a parameter to your function whose lifetime you can tie it to. If you don't have such a parameter, then a Box is your next best bet.

Somewhat related to this, there's also currently a language deficiency where you can be forced to use Box when returning a closure from a function. This will be addressed shortly after 1.0.

</comment></comment></comment></comment><comment><USER21> > Despite all this, Rust is going to be a very important language, because it > solves the three big problems of C/C++ that causes crashes and buffer > overflows. The three big problems in C/C++ memory management are "How big is > it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none > of those problems effectively. Rust deals with all of them, without > introducing garbage collection or extensive run-time processing. This is a > significant advance.

What? C++11/14 solves these issues.

<comment><USER15> > What? C++11/14 solves these issues.

You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data.

I would also argue that Rust is a _better_ solution to the first two issues. Modern C++ does not solve the problem of use-after-free (dangling references and invalid iterators are very possible, and common in large codebases). This is something that I don't believe C++ _can_ solve without becoming a radically different language. Furthermore, Rust forces you to use the right patterns unless you type "unsafe": this is, again, important for security, reliability, and developer productivity, reducing the amount of time you spend in the debugger.

<comment><USER22> My simplification of matters is that while C++ _can_ now do everything right, it still easily lets you do everything wrong.

Rust compels correctness, so for any project where you can't trust your coworkers aptitude towards correctness (and that is to say you even trust your own) Rust is an insane productivity booster. We could have avoided millions of hours of work and thousands of zero day and system destroying bugs if we had OS cores written in a language like Rust.

<comment><USER23> > so for any project where you can't trust your coworkers aptitude towards > correctness

So, for _any_ non-trivial project. People _will_ make mistakes, no matter how skilled or experienced they are. Catching these mistakes at compile-time can be a huge gain for security and stability.

Though it remains to be seen is what kind of maintenance/development burden these constraints introduce over the longer term lifecycle of a software project.

</comment></comment></comment></comment><comment><USER24> I tried to learn a bit of rust and I couldn't shake the feeling that rust is a very ugly language, like uglier than c ugly.

<comment><USER25> What makes you say this? And what is your prior language experience?

<comment><USER11> _I tried to learn a bit of rust and I couldn 't shake the feeling that rust is a very ugly language, like uglier than c ugly._

 _What makes you say this? And what is your prior language experience?_

Right there is the problem. There are many programmers for whom it's their day job. Others depend on their code doing something useful and important. But they're not theoreticians, don't have advanced degrees in CS, and haven't written in a dozen languages. A new language has to be usable by them to get traction.

The Rust community, at this point, is mostly people who know several programming languages and want to try a new one. Look at the comments above from people who compare type systems in different languages and are aware of the strengths and weaknesses of different approaches. Note the references to obscure languages and research papers most programmers have never heard of, let alone used or read. This is not the target market for a new language, if it is to be a success. It has to be used by people who don't debate language theory issues while the Super Bowl is on.

</comment></comment></comment><comment><USER26> > I just hope the Rust crowd doesn't screw up.

If i had a pound for every time i'd heard this sentiment, i'd be a rich man!</comment>


Show HN: A smarter alarm clock. - <AUTHOR> http://kck.st/AfzPrN

<comment><USER2> You may want to check these out

[http://www.makeuseof.com/tag/3-unique-android-alarm- clocks-b...](http://www.makeuseof.com/tag/3-unique-android-alarm-clocks-bed- faster/)

<http://www.shakeawake.com/>

<comment><AUTHOR> Thanks. Those are the kinds of features we expect to put in our App too. I have even bigger plans for the App in fact, but I don't want to give away all my secrets here, because some of them can be copied. But, I'll just say that it's going to be incredible, amazing, and world-changing! If we make our funding goal and get these things out there in large quantities, and add all the features to the App that we're thinking of, people are never going to go back to traditional alarm clocks again. In fact, we don't even thing they'll be called "alarm clocks" for much longer.

</comment></comment><comment><USER3> If you ask me, alarm clocks should be going more low-tech than high tech.

I need an alarm clock with decoy snooze/cancel buttons. All of them would be metal plated, and wired up to whatever circuit those "trick" pens use (the kind that gives you an unpleasant but safe shock).

I would attach a hammer to this hypothetical alarm clock too if I could figure out how...

<comment><AUTHOR> I don't think we can add the hammer or the electric-shock, but we can certainly add a virtual metal-plate in front of the snooze button, and we can even make it so you have to answer a question or type in a code to release it. We can try to do whatever our user community comes up with, it's all software, so we can add lots of cool features as time progresses.

</comment></comment><comment><USER4> Would be neat to see numbers about how many people actually have trouble with alarms. I don't. I actually tend to wake up right before the alarm goes off even. Just saying, we may think it's a large problem because people who have the problem complain a lot, but there may not actually be enough people out there with the problem to support a business...

<comment><USER5> I have a huge problem with them. Usually I've got 5-6 alarms set one after another to wake me up properly. Even if I put the clock/phone far away, I'm quite capable of getting up, going there, turning it off (code or whatever protection is not enough to stop me), going back to bed and not remembering any of it. And no, I'm not sleepwalking really. I'm just not awake enough to do a mental switch between "there's this thing that's annoying me, I must stop it to continue sleeping" to "it's morning, this annoying thing is trying to wake me up".

On a typical day my alarm wakes up my girlfriend and she pokes me until I wake up. Actually, I just switched to an Android phone, so I'm going to try some of those movement detection apps... we'll see how good they are.

<comment><AUTHOR> One cool thing we can add to the app is all the features you just described about multiple alarms and snooze options or screen-lock codes or whatever. We can have a mode where it starts off kind of quiet and gets louder, or maybe you want a really nice song to start off with, but then you can have it play more and more annoying songs if you keep hitting snooze. We hope you wouldn't have to keep hitting snooze though, because the iDreamSaver is going to wake you up at the right time to begin with!

</comment></comment></comment><comment><USER6> This is great! I've been looking for something like this for awhile but all of the other concepts seemed too cumbersome. I really hope this product reaches its funding goal. Cool idea.

</comment><comment><AUTHOR> Would appreciate ANY feedback from the HN community!

<comment><USER7> Why would I purchase this as opposed to using <http://www.sleepcycle.com> ?

<comment><USER8> Interesting app! It seems like a lot to remember to put your phone under the covers and make sure it doesn't fall off in the middle of the night (at least for me). Additionally, I've always loved having the phone in the dock next to my bed, since it doubles as a clock for me in the middle of the night.

Do you know if the Sleepcycle app is able to differentiate between your movements and someone else's? It seems like this wouldn't be possible?

This is obviously a totally different price point, but it seems like bringing a hardware-based solution here does offer some real and very tangible benefits.</comment></comment></comment>


Paid app disabled via update, customers offered free trial of new app instead - <AUTHOR> https://play.google.com/store/apps/details?id=com.flightradar24free&hl=en_US&showAllReviews=true <comment><USER2> It should be possible to install older versions of an app, at least the versions the user had installed in the past. This would also allow users to downgrade if a new version didn't work on their devices or all devices.

</comment><comment><AUTHOR> If a paid app stops working (made to stop working with an update), should not there be a refund? Is this legal?

<comment><USER3> Man, who thought screwing over the people willing to pay for their first app was a good idea? Good customers they could've brought along on the ride with their new app via a credit or something. Then hit them with in app purchases for even better service/support or something, or do nothing, which is better than what they did here.</comment></comment>


Fyuse - <AUTHOR> http://fyu.se/

<comment><USER2> The tech seems cool, but I'm not seeing what extra value I get over a scrubbable video. How are you using the spacial information to add value to the images?

<comment><USER3> It seems like they are registering the points-of-interest between frames/images so that they can create a consistently scaled set of output images even if you, for example, took a step further away from the filmed object. And then using these sort-of-normalized frames to interpolate between them.

</comment></comment><comment><USER4> How is this different from taking a normal video, and letting user navigate forward and back by dragging?</comment>


Viewpoint: 'I feel like was accidentally hired' - <AUTHOR> https://www.bbc.co.uk/news/technology-53180073 <comment><AUTHOR> I fear that HN folks have got tired of this topic, but this is really well written and it made me think.

<comment><USER2> Also posting this to HN, and seeing that you got here first :)

I just wanted to add, that this seems like a very US-centric view. Here in the UK, I have worked with many non-white people over my career, and I've hired several to work on my teams. Certainly in London, race doesn't really come into it - if you are the best fit, you get hired, regardless of your ethnicity (it's illegal to do otherwise in fact).

<comment><AUTHOR> I think there's a real risk of complacency. Computer Science is for the most part quite a diverse community, both here in the UK and in the US, and I love that. But there _are_ groups who are very underepresented. In my CS classes in London there are a wide range of ethnic and national backgrounds, but there are relatively few black students. This doesn't need to be self-perpetuating. We should take Ibrahim's comments seriously, and try to be more welcoming.</comment></comment></comment>