Tesla fires hundreds from headquarters, factory - <AUTHOR> http://www.mercurynews.com/2017/10/13/4819750/ <comment><USER2> High-level executives at Tesla are bailing out. Back when Musk announced his overoptimistic production schedule for the Model 3, his two top production executives quit.[1] Nine more high-level executives have left so far this year.[2]

[1] [https://www.bloomberg.com/news/articles/2016-05-04/two- tesla...](https://www.bloomberg.com/news/articles/2016-05-04/two-tesla- production-chiefs-to-leave-ahead-of-biggest-challenge-yet) [2] [https://www.bizjournals.com/sanjose/news/2017/08/02/tesla- ts...](https://www.bizjournals.com/sanjose/news/2017/08/02/tesla-tsla- executive-exodus-kurt-kelty-battery.html)

<comment><USER3> That's really interesting. The Economist ran a story earlier about how aggressive Musk's finances are and how there was weird finance going on and that Musk was simultaneously trying to keep things afloat, keep on a super aggressive schedule and keep control.

[https://www.economist.com/news/business/21709061-entrepreneu...](https://www.economist.com/news/business/21709061-entrepreneurs- finances-are-jaw-dropping-inventive-and-combustible-his-space)

Perhaps the wheels are starting to come off. Even if they do, it's been amazing what has been achieved.

<comment><USER4> From afar, it seems that's just how musk did about everything. SpaceX was a potential catastrophy, but they passed the tipping point successfully. Everything Musk does is "adventure" like, which is unsurprisingly good for employee stability. It's a bit like Jobs at Apple. You're gonna suffer, maybe get fire but you worked on "that" project.

</comment></comment></comment><comment><USER5> I know someone who just got fired in this round at Tesla. His manager never communicated to him that he was a bad performer. He was not on a PIP or any performance plans. He was also working on Model 3. One fine morning his manager called him and said this would be his last day. He is a single income earner and was so shocked by this news that he is getting borderline depressed. They offered only 2 weeks of severance.

<comment><USER6> > I know someone who just got fired in this round at Tesla. ... They offered > only 2 weeks of severance.

Fired or layed off? I've never experienced either, but I always thought severance pay was exclusive to the latter.

<comment><USER7> If you're fired for doing something bad, then you become ineligible for unemployment compensation (which is something you earned) and some other benefits. This creates a perverse incentive to claim a cause for termination. On the other hand, it also creates an incentive for the fired employee to sue, especially if they think that the employer didn't have an utterly bulletproof paper trail and discipline procedures.

For this reason, it's sometimes more practical for a company to terminate someone without cause, and just pay out the benefits as a cost of doing business. They can wait for a slow season, when they would normally shed some workers, and terminate the lowest performers.

Companies avoid the term "layoff" because it has connotations, such as eligibility to be re-hired when conditions improve. So they use "reduction in force" instead. The people who are fired are "impacted," and so forth.

The terminology used doesn't mean anything... what matters is whether someone was terminated "with cause" or not.

<comment><USER8> It varies by state, but you can collect unemployment a lot of the time if you have been fired.

<comment><USER9> In California, unemployment is a maximum of $450 a week for 26 weeks. Still helpful, but ~$11/hour is a pretty big drop for most of them.

<comment><USER7> Indeed, it's not a lot, but I figure, you earned it so you might as well collect it.

</comment></comment></comment></comment></comment></comment><comment><USER10> I'm not a fan of this style of management at all. I won't knowingly go to work for a company that behaves in this manner. I've read that Netflix does it, and I've seen inferences that they acquired the practice from Disney.

If you have a low performing employee that you want to get rid of, fine. Arbitrarily destroying the lives of a percentage of your workforce in an annual purge is not OK.

People always seem to put Musk on a pedestal. Personally, I've always been (and always will be) leery of a company run by a PayPal founder.

<comment><USER11> And it is exactly this style of management that is causing problems at the German automation plant he aquired (see my comment in the duplicate thread). It is probably a reason why production of the Model 3 is behind -- the company he acquired builds the factory robots needed for advanced automation. Smart move to acquire it then and it explains why the timing is now off.

You can't run a German plant like an American one, people will take the 30 day vacations that have been written into their contracts since before he arrived (just because you have a new boss doesn't mean the old contract is invalid), take sick days if they need them (unlimited sick days by law, they don't come out of your vacation time), and go home at 5pm because they value their home/family/free time. Last I checked the factory had at least dozens of positions open that they can't fill because no one here wants to work for them.

<comment><USER12> Presumably one bit of Tesla culture they can't bring to Germany is firing low performers.

I worked for a German company for over a decade. I don't know if it was due to their culture or their laws, but I never saw anyone get fired for poor performance (except for failing the initial 6-month probation after joining). And it's not like we didn't have low performers — once I got into management it became quite clear that there were a handful of people who were borderline useless, but it was just accepted that they were employees, that the company should look after them just the same, and find work for them to do.

<comment><USER13> The idea in large parts of western europe is that it is OK to fire employees who aren't fit for their job, but that "low performing", at best, only is a low quality indicator of the former.

For example, management can stifle productivity in ways that individual workers have little influence on.

Also, employees may be 'useless' for a while, but then improve again, for example if they are going through a divorce, the death of a relative, etc. Firing people because they perform worse for a few months is frowned upon in some circles.

<comment><USER14> How do people there understand the difference between low performers and people who aren't fit for their job? The latter has the sound of something lasting that cannot be fixed, but I'm wondering how it plays out in practice. How do you determine that someone is not fit for their job as opposed to a mere low performer?

<comment><USER15> By discussing things with them like a regular human being and giving them opportunities to try things they are more comfortable with.

Good management is not, ironically, rocket science.

<comment><USER14> I think this comment is the 'RTFM' of employee-employer relations.

Very few things in this world are actually simple enough that this kind of dismissive attitude works. I've seen people who didn't care about giving helpful feedback and second chances, but I've also seen people who agree in spirit, but don't know how to do it well.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Do other companies do this? Unless this is GE-style force ranking, I've never heard of it.

If somebody isn't performing well, I have no idea why I'd wait up to a year to deal with it. And it seems terrible for morale (and PR) to have a regular event where a bunch of people will be let go in one block.

<comment><USER17> > Tesla said the performance-based departures were not considered layoffs and > not subject to state notifications. It also said the moves have generally > boosted worker morale, as high-performing employees have been rewarded.

Maybe I'm just paranoid but this part kind of smells to me.

<comment><USER18> One of my best momemts at bigco was a useless middle manager getting fired. Bad and toxic employees do kill morale for your team.

<comment><USER16> Sure. But then why keep them around for up to a year and fire them in bulk? The moment to get rid of a bad employee is as soon as you notice you have a bad employee.

The distribution of noticing problems should be pretty much random, so concentrating the firings in a once-a-year block means a high tolerance for keeping bad employees around. That, or they got rid of these people for reasons not really related to performance.

</comment></comment></comment></comment><comment><USER19> This sort of behaviour is quite common in companies, so I can't help wondering if it is true that studies have shown a significant percentage of Silicon Valley CEO's and company executives are psychopaths.

[https://www.cnbc.com/2017/03/21/apparently-psychopaths- make-...](https://www.cnbc.com/2017/03/21/apparently-psychopaths-make-good- ceos.html)

[https://www.theguardian.com/technology/2017/mar/15/silicon-v...](https://www.theguardian.com/technology/2017/mar/15/silicon- valley-psychopath-ceo-sxsw-panel)

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

[https://www.washingtonpost.com/news/on-small- business/wp/201...](https://www.washingtonpost.com/news/on-small- business/wp/2016/09/16/gene-marks-21-percent-of-ceos-are-psychopaths- only-21-percent/)

<comment><USER20> Why would they have to be psychopaths to justify such behaviour? A belief that the project > people suffices. Can you not think of any project that is more important than the individual workers making it happen?

Also, I suspect they would react differently if e.g. the mass-laid-off committed mass suicide, whereas I doubt a psychopath would.

</comment></comment><comment><USER21> The high estimate was 700 fired. Out of 33,000, that's 2%. Culling the bottom 2% performers seems like a reasonable (even healthy) thing to do; not really an upheaval.

<comment><USER21> EDIT: Not healthy, though, if that 2% is a quota, rather than the happenstance fraction of people who fall below the performance bar at evaluation time.

</comment></comment><comment><USER22> The unforgivable action here is the badmouthing of the workers that they fired, gloating about increased morale. Not even Uber would sink that low.

This crap from management shouldn't be tolerated, much less celebrated.

<comment><USER23> That tends to be one cheap option to keep psychologically tied to the company.

I'm not for or against it, but I imagine being one of those workers it would suck.

Still, I'm all for automating as much as possible, and in the case of workforce reductions, gloating over the fact that things move so much more quickly and accurately.

I do like Elon Musks's attitude toward people wasting time. And this is head and shoulders above what goes on in China, India factory conditions. Not saying no one should whine and bitch and moan about it, but truly, it's not all that bad.

</comment></comment><comment><USER24> Hiring managers are going to remember this. I hope that it was performance related and that Tesla wasn't just trying to save face with investors.

</comment><comment><USER25> Man, that's rough. I know there is good reason to get rid of dead weight, but two things:

1\. I had no idea dead weight would be allowed to exist at Tesla.

2\. I believe dead weight can be redeemable, if you put in the right effort --not the procedural PIP stuff (which is about improvement as much as incarceration is about rehabilitation) but I mean real effort to rehabilitate a worker. Maybe too much effort for a high flying co.

<comment><USER26> Not to waste time pointing out what you already know, but I think it's worth adding that you can be fired without being dead weight. Many firms (especially in law or consulting) have chosen to have pyramid structures with up-or-out policies that fire half the employees every two years. Even if the fired employees are good, this keeps everyone motivated and allows you to churn through employees to find the really excellent ones worth developing. The system is not inherently good or bad, as long as all parties are aware of it.

<comment><USER27> > Even if the fired employees are good, this keeps everyone motivated and > allows you to churn through employees to find the really excellent ones > worth developing. The system is not inherently good or bad, as long as all > parties are aware of it.

Everything about these statements is wrong. Take it from someone who worked at Microsoft before and after they finally smartened up and ditched stack ranking: it's horrible. It creates an atmosphere of paranoia, where people sabotage each other at great cost to the company instead of working together towards common goals. Worse, contra your claim that it weeds out the worst and lets the best rise to the top, what actually happens is the best quickly get sick of the bullshit and leave, while the ones rising to the top are the ones most adept at politics and gaming the system.

Stack ranking has no redeeming qualities whatsoever, and if that's really what Tesla is doing it's enough alone to make me more bearish on them. It's that bad.

<comment><USER26> The top three management consulting firms are ranked #1, #3, and #11 on Glassdoor's best places to work. Clearly their up-or-out policies aren't seen as horrible by their own employees. And as a consultant who works at one of those firms, I've never seen anyone sabotage someone else's performance, not once. In fact, you are probably rated best when you help support those around you. Certainly the policy causes stress, but these firms are top destinations for MBAs regardless.

[https://www.glassdoor.com/Award/Best-Places-to-Work- LST_KQ0,...](https://www.glassdoor.com/Award/Best-Places-to-Work- LST_KQ0,19.htm)

<comment> semi-extrinsic People with MBAs have a very different mindset from auto workers. When you've had "this is an optimal system" drilled into your head at school by people you've been told are very smart and you should look up to, you're probably going to think it's a good system. Especially when you know that the probability of harsh financial consequences for yourself and your family from this policy is essentially zero.

The situation for auto workers is very different on both points.

</comment></comment></comment></comment></comment><comment><USER11> Interesting comments can also be found here: [https://news.ycombinator.com/item?id=15470314](https://news.ycombinator.com/item?id=15470314)

</comment><comment><USER28> The Romans called this style of management "decimation." It's unfortunate that it's still fashionable in the 21st century.

Also, this sounds straight out of the Ministry of Peace:

"It also said the moves have generally boosted worker morale"

<comment><USER29> >The Romans called this style of management "decimation."

To be fair to the Romans, decimation was a (correct, if the adjective can be used in this case) _random_ process and was limited to the army.

The idea was that when a large group (a cohort or 480 people) _severely_ underperformed (it happened in case of rebellion/mutiny or blatant cowardy), AFTER having executed on the spot those that led the rebellion or that were manifestly coward or leading the mutiny, the remaining were divided in groups of ten, then in each group one was selected by drawing lots, and was executed by the remaining 9 comrades.

This had two advantages (in the eye of the Roman leaders), the army would not have been exterminated (unlike in more "traditional" repression of rebellions) and the 9/10 remaining would have been _motivated_ to contribute to the group.

So, there was not an evaluation of the performance (or non-performance) of the single, the responsability was attributed to the group as a whole, and then out of the 10 people subset the 1 to be killed was chosen by Fate.

</comment></comment><comment><USER30> I used to be of the opinion that a company should have full right to drop dead weight as and when it chooses fit. The thing we forget is we, citizens, pay extortionate taxes to run a government which provides favourable incentives for companies to form and provide employment. They should, in return, be obliged to demonstrate some level of mutual benefit to employees, rather than purely incentivising shareholders' and directors' bonuses.

<comment><USER31> So companies should follow the law? I think you're really arguing for better employee protection in the USA ?

<comment><USER32> I interpreted the post as meaning when a company is given millions of dollars in tax breaks, i.e., build your new factory here and your income tax is abated for X years, then they should be on the hook for when they let go of employees.

In theory I agree and the company should be on the hook to provide training or assistance.

<comment><USER31> So why weren't employee protection or training part of the tax break? Same point.

<comment><USER33> Why would everyone's taxes be used to protect a few workers? Especially (apparently) not the greatest... If the company is doing well it'll continue to hire and provide employment to others. As a society, I believe we could argue that we shouldn't subsidize companies that offshore the work, but otherwise if we want help for employees that are let go (training, assistance, ...) better make it a public service.

</comment></comment></comment></comment></comment><comment><USER34> It's quite common in investment banking. A bunch of them do it.

[https://www.quora.com/Could-Goldman-Sachs-strategy-of- firing...](https://www.quora.com/Could-Goldman-Sachs-strategy-of-firing-the- bottom-5-10-of-staff-every-year-work-for-all-businesses)

I think Barclays also used to do it.

It's shitty thing to do to people. But you don't need me to tell you they're shitty companies.

</comment><comment><USER35> Wouldn't be surprised if this is to distract people from bad publicity such as production delays and handmaking of parts [https://www.wsj.com/articles/behind-teslas-production- delays...](https://www.wsj.com/articles/behind-teslas-production-delays-parts- of-model-3-were-being-made-by-hand-1507321057)

</comment><comment><USER36> 2 key sentences in the article say so much: "Several said Model X, Model S and former SolarCity operations seemed to be targeted." ... "The spokesman said most of the dismissals were administrative and sales positions, and outside of manufacturing."

This has little to do with performance or any conspiracies. If your output of products is about to dramatically shift there is no reason to think employment should remain stable among all departments. I would guess if shifting a company's labor requirements was more politically correct, the shift would be much larger.

The average pundits head might just explode trying to rationalize the juxtaposition of a clean tech company increasing production rapidly yet 'firing' hundreds. The rational, however, applaud these efforts and the difficult decisions this requires.

<comment><USER37> Flawed assumption being presented as logic here. The only logical reason for firing would be if the model S,X skills were completely irrelevant to whatever the new model is - which is unlikely.

<comment><USER38> It seems to me that the firings were probably more in the sales side. They have had problems with sales people who refused to do things the 'Tesla Way' by either being pushy, or by offering discounts to make their numbers look better.

</comment></comment></comment><comment><USER39> There seems to be some confusion/ambiguity around whether these layoffs were focused on the Fremont Tesla factory or company wide.

If they were focused on 1 factory that would be weird - if they were company wide that would be within the bounds of normalcy.

Can anyone illuminate?

</comment><comment><USER40> Its like the "Survivor" TV show. Or "The Apprentice" \- hey who was the host of that?

</comment><comment><USER41> So basically what you have is Musk over promising and under delivering but it's the worker's fault he could not meet unrealistic deadlines he set himself ignoring all reality.

Musk set Tesla up for failure and now the non-management people have to suffer as a result. The fact that this is even being talked about right now may hurt Tesla's chances of hiring great future employees...especially with that scathing article basically saying they were being fired for bad performance and not laid off.

Can you still get unemployment if you are fired for unsatisfactory performance?</comment>


Tech That Tracks Your Every Move Can Be Convenient, Not Creepy - <AUTHOR> http://www.wired.com/2014/03/designers-tracking-tradeoffs/

<comment><USER2> No. Full stop.

Being tracked is never good. It's the thin edge of a wedge, which, if left unchecked in the name of "convenience", will lead to total tracking of everyone in the names of "safety" and "convenience".

"They" will say it's "for the children", as they always do, and the politicos will pass legislation.

This is like drugs: just say no.

<comment><AUTHOR> For the record, I dislike tracking, but I like seeing the other side once in a while.</comment></comment>


Ask HN: I wonder if message length have impact on communication efficiency - <AUTHOR> I look for studies that discuss about messages lengths and communication efficiency and the relation if any with nowdays messaging usages compared with previous generation habits.<p>Any thoughts, sourcesor suggestions are welcome. <comment> Lorenz-Kraft I think there are no direct studies about message length and efficiency. You might want to look closer at NLP because most of what you might be looking for is defined within NLP.

For Example: "Efficiency" depends on the sender (who writes) and recipient (who reads). But this is not the end. 1: HOW is something written (Hard to grasp?=> Flesh Analysis) 2: HOW is something written (10 px Font on mobil? => Typography) 3: HOW is something written (light white 20px Font on light grey background?? => Typography and Color Contrast) ... and so on for almost all topics. There are mostly more than one question to be answered ... for both views (sender and receiver).

<comment><AUTHOR> Thank you for this constructive answer. I understand here that indeed there might have answers in NLP for my question. I also mainly understand that there are no simple answers. It's a very hard question that should be splited in many sub topic to have a true response overview, what looks to me to hard for a proper answer. I think now I have to dig the internet a lot to have a more accurate response ;)

I can elaborate more on my inital question by rephrasing as following : "Does short messages systems (messenger like / sms) in 2020 provide better human communication (more efficent, better comprehension) than legacy long messages systems (emails, letters, books) ?

Rephrasing makes me understand that the question is still way to large as it need a lot of definition ans asumption to hope an simple answer.

<comment> Lorenz-Kraft I think the "medium" (twitter/mail/messenger) and its "limitation" do not matter a lot. I think it mostly depends on the sender and the receiver (and its circumstances). If they have a mutual understanding (same "degree") of the message, the communication MIGHT be more efficient due to lessen time delay. Nevertheless, the sender might use the wrong words ... speaking Portuguese ... you see where this leads ... also, and most fascinating ist the "time factor". Like: "Do you need time to understand / grasp something?"

So as I see it: The communication medium itself is almost always not responsible to for "better human communication". BUT, as all rules, there are exceptions, for example, twitter is a medium that can, with one "tweet", move a whole flock of birds at once (I think this was the initial intention of twitter ... philosopical seen). This "reach" (unprecedented before) opens up a whole new slew to "human communication". Like with one tweet: 1: Some Trump might declare war with ($random-country) 2: A Country might revolt (see Arab Spring) 3: Stock Market might break ...

By the way, not sure if you might like it, but "Cognitive Load" is a very interesting topic in itself. Its about your own possibility to grasp/understand/dissect things. Its mainly about "basic" things that, when cumulated, are totally obvious OR totally confusing. In my opinion, this is the main key to "better human communication".

But to end this topic, here is my recent -Word of the Week-: If you can't explain something well, its likely you don't understood it either

</comment></comment></comment><comment><USER2> I think the shortness of Twitter is why it's a vile toxic dump.

But I'd look into the Twitter message length change over -

ie. [https://medium.com/@kurtgessler/twitter-length-study-do- long...](https://medium.com/@kurtgessler/twitter-length-study-do-longer- tweets-drive-more-engagement-and-referral-traffic-3dd0781363ff)

> previous generation habits

This is harder to understand. I'd say the telephone was what was important directly pre-internet. Letter's were quaint. $ per message mattered. Latency was huge. It's pretty complex.</comment>


Ask HN: Anyone in NYC area using Verizon FiOS? - <AUTHOR>

Wondering if anyone in NYC area is using Verizon FiOS (residential or small business) and their experience with it.  How's the performance and service availability (up/down time)?  Is it recommended? <comment><USER2> I live in Jersey City. Unfortunately I have to use it because it's all my apartment building is wired for.

It's an overpriced service, in my opinion. The reliability is good, but I'm paying $60 a month for their slowest speed. When I lived in PA I was getting twice the speed for $20 a month. Maybe that isn't unreasonable when you're also getting cable and phone for not too much more as a package, but I don't have a TV and don't need a landline so they're just gouging me.

One of the things I really hate about this area is how expensive everything is.

e: side note - when they come to set up your internet make sure all your machines are booted into linux (if you dual boot), otherwise they will attempt to install some of their software on your computer. They don't have a linux version of the software and will just give up and leave. If you have windows or osx running they won't leave until you let them install it.

<comment><AUTHOR> Thanks for replying stackcollison! Yes, it's crazy how expensive internet service is in NYC area. I just wish Google fiber or other gigabit service can get here sooner. My friends in other countries are getting hundreds of mbps for their internet service. I don't know how our country, supposedly the most technology advanced country in the world is still talking low mbps internet... It's time for a nationwide upgrade.

</comment></comment><comment><USER3> YES - I currently have 155MB down and 50MB up - Although the wifi they included is limited at 130MB and not 300MB :( First World Problem.

I would recommend them as they also have a 300MB down package - but you have to ask for it as most of the people who work for them are idiots but their service is great.

Side note - I had them install my internet - had my HDTV setup with an antenna (Free TV, Imagine that) and they asked who my cable provider was... They had no IDEA you could get HDTV picture with an antenna - these are the same guys INSTALLING HDTV setup boxes at your home, crazy! END OF RANT!

<comment><AUTHOR> John, thanks for the info! A few more questions if you don't mind. How long have you had the service? Was it reliable? Any down time that you experienced? Were they quick in fixing problems?

I know what you mean about HDTV. I use the antenna to get free HDTV too. People come over to my place and see how clear it is couldn't believe it. It's funny people who work in the industry do not know about it haha

<comment><USER3> I have had it almost 7 months. 0 down time. If you can get FiOS I recommend pulling the trigger... unless you can get Google Fiber :0

<comment><AUTHOR> haha I wish Google Fiber is available here!</comment></comment></comment></comment>


Show HN : I have developed a robots.txt full text search engine. - <AUTHOR> http://robots.dnsdigger.com/ As a sub project of my pet project DNSDigger.com i have developed a search engine that index robots.txt (http://en.wikipedia.org/wiki/Robots_exclusion_standard). I actually don't know what poeple could use this for but i suspect poeple that are into SEO could use it and black/white-hat hackers(?). What i need help with is VPS/$$ for spidering. And as i sit on a considereble index of domainnames (though DNSDigger.com 300m hosts) i thought that if you want a TLD indexed sooner than later you could sponsor it with either VPS or Paypal. See it as a strange "kickstarter". And if you think the "design" suck (which it does because there is a lot of things i suck at and design is one of them) you are free to submit anything better. I can put up a banner for your service a limited time. I am adding new hosts/TLD all the time.
And if you have to ask what this is you will not have any use for it even if you did ;) <comment><USER3> Very cool project. I'm curious as to how you're getting all these robots - <USER2> you scraping them yourself?

<comment><AUTHOR> Downloading them as we speak. I have a big list of hosts/domains i have collected through spidering for my DNSDigger.com. This is a hobby project that has grown a bit over my head hehe. And there is no scraping needed. Robots.txt is just simple textfiles. Download and parse, repeat a couple of million times and build an index :)</comment></comment>


Ask HN: How to design a karma reward system - <AUTHOR>

I am building what is actually a large portal for a 'tutoring site'. Visitors will be able to join groups, create groups and post comments, lessons etc. They will also be rewarded for completing on-line exercises.
I would like to introduce a 'karma reward system' in order to a) motivate people to contribute and b) to crowdsource ratings both for people as well as content.
I am leaning to something that is in-between what http//thesixtyone.com offers and HN's or stackoverflow's floating method of ratings.
I am looking for suggestions, formulae and good links to resources, books etc as well as other sites than the above three that you favour. <comment><USER2> What I've wanted to try but I have never had the opportunity to was having karma be accumulated on a per-topic basis. I think any time you've got a wide set of topics this is necessary to avoid the issues of people being treated as credible outside of their domain of expertise, and it could help mitigate the issue on Stack Overflow where people who answer lots of easy questions can get much more karma than those who answer a few much harder ones.

<comment><AUTHOR> Jeff Thanks! What you saying is very true of stack-overflow and although I visit occasionally their whole karma formula does not appeal for the reason you mentioned. I was thinking in similar lines and have introduced the groups concept for example when you belong to the 'lisp circle' you will be able to earn additional points when you answer or solve lisp problems. My concern is not to let the users focus too narrowly, I was thinking that joining groups should be limited i.e, when you accumulate 100 points you can join a group and as you earn open up more groups... To link the whole thing in a sort of 'PageRank' algorithm to stop people from gaming the system is what is puzzling me.

</comment></comment><comment><USER3> I've posted this on HN before, but I wrote a long essay about problems with account-karma-moderation systems: <http://www.kuro5hin.org/story/2009/3/12/33338/3000>

Probably too involved for your project, but there are some problems you should be aware of from the get go.

<comment><AUTHOR> Perceval thanks and by the way an excellent essay. You hit the nail on the head with ... 'our hypothetical comment-driven forum would push stories up based on quality of conversation....'. Do you think that part of the formula can be improved by including automatically a 'readability formula', where the childish comments and language would automatically be penalized by the system?

<comment><USER3> Some folks are already working on that: <http://stupidfilter.org/main/>

It's supposed to identify _formally_ stupid comments, i.e. those that have bad spelling and txt abbreviations, etc. It doesn't do anything about substantive stupidity, unfortunately ;)

<comment><AUTHOR> I was thinking something like the _Gunning fog index_ <http://en.wikipedia.org/wiki/Gunning_fog_index>

</comment></comment></comment></comment><comment><USER4> > I would like to introduce a 'karma reward system' in order to a) motivate > people to contribute

What evidence do you have that any karma system motivates people to contribute the kind of content that you want?

Seriously - look at the top karma people on HN. What fraction of them post for karma? Of the ones who do, how many of them do you want?

> and b) to crowdsource ratings both for people as well as content.

Again - what evidence do you have that karma helps with this?

A karma system guarantees that you'll have people posting for karma and discussing it. Both are bad. What benefits that you can reasonably expect that are more valuable?

</comment><comment><USER5> It depends on your choice of language and some specific implementation details....and whether you are more interested in the user interface side, the data modeling, or both.

There's a range of approaches to motivational systems, and I think in 2010 we'll see some real innovation in this area. For instance, I think Gowalla is doing a particularly great job.

<comment><AUTHOR> Thanks! I added Gowalla on the list! I am more interested in the data modeling and algo and good examples like Gowalla.

</comment></comment><comment><USER3> Here's a blog that might be relevant: <http://buildingreputation.com/>

<comment><USER6> Some great articles on there...

</comment></comment><comment><USER7> I'm planning on working on something potentially very similar. Here's an outline post I made a while back: [http://karanbhangui.posterous.com/course- learning-aid-propos...](http://karanbhangui.posterous.com/course-learning-aid- proposal)

Lemme know if you're interested in collaboration.

<comment><AUTHOR> Thanks I will send you an email! Is that UWaterloo like in the UK?

<comment><USER8> The University of Waterloo ( <http://uwaterloo.ca/> ) is in Ontario, Canada.

</comment></comment></comment><comment><USER6> Related question: does anyone have any info on using a super simple voting system (thumbs up/down, or just up) that does NOT suffer from time bias. In other words, an item might have more up votes just because it's been around longer.

<comment><USER8> Bias your comment ordering system in favor of new comments so that every comment gets its 5 minutes of fame before staying around with a good score or floating to the bottom with a bad score. it's not perfect, but it should mitigate the problem.

</comment></comment><comment><USER9> stackoverflow has a few interesting incentives:

\- activity is renamed to 'rep' which implies that your activity ranking reflects on you personally, even though everyone knows its really a measure of how long you've been active and whether you answer broad beginner questions that get a lot of google hits

\- it makes sure you know when you are downvoted

\- though the numeric penalty of a downvote is negligible, but since it is a personal criticism of your reputation, you have ego incentive to improve your contribution

</comment><comment><USER10> <http://public.research.att.com/~volinsky/netflix/>

For all your rating/karma/rewarding needs :-)

</comment><comment><USER11> Read/watch all the Amy Jo Kim presentations you can find online.

<comment><AUTHOR> Thanks lots of videos - will need three days to view them! :)</comment></comment>


Social Networking's Next Phase - <AUTHOR> http://www.nytimes.com/2007/03/03/technology/03social.html?_r=1&oref=slogin <comment><USER2> Extending Zawinski's law [1] to the web: Every website expands until it becomes a social network. Websites that cannot so expand are replaced by ones which can.

[1] http://en.wikipedia.org/wiki/Zawinski's_Law_of_Software_Envelopment

<comment><USER3> Google search is pretty big. Is it a social network?

<comment><USER2> Zawinski's law didn't really apply to windows either.

But it's a good question. Both edges of the feedback loop between search and social network are interesting:

a) Social networks where we have to manually link to friends will not last.

b) Google's integrating search with notebooks, groups, hosting, email and IM. Perhaps those are primitives for a social network rather than an OS.

c) Making search more relevant using a social network is perhaps still a valid approach, in spite of the lack of success so far.</comment></comment></comment>


Dropbox Is Probably Not Stealing Your Files - <AUTHOR> https://one.darrenpmeyer.com/blog/dropbox-is-problably-not-stealing-all-your-files.html <comment><USER2> This is a fine post, but all I can think about this situation is "or, you could just reverse the Dropbox client and find out for sure".

Speculation about Dropbox stealing files seems premised on the idea that you can't know what the client is doing. But that's not even close to true. People reverse much, much harder targets than Dropbox for fun. If any version of Dropbox published to its user base ever did anything like this, we'll all know soon enough.

<comment><USER3> I would be _very_ surprised if a workplace name like Dropbox has never been reverse engineered by a bored hacker on a lazy weekend.

Surprised and disappointed.

<comment><USER4> I reversed it back when it was version 1.1.something, it was basically all compiled Python modules with custom encrypted code objects and non-standard opcode mappings for the bytecode.

Quite interesting to see how it worked, and useful to get the key for the encrypted logs, to see it what it actually did while running. Back then you could intercept the https connections as well as they hadn't pinned the certificates yet, to get an even fuller picture.

There was nothing obviously nefarious going on back then, but that was quite a few years ago of course.

<comment><USER5> So what you're saying is that, if I wanted to launch a nefarious file-stealing Dropbox-like application, I should first launch the non-nefarious version, and then when it gets up to 3.6 or so, turn evil?

<comment><USER6> Yes. That's exactly the right time to turn evil.

[https://xkcd.com/792/](https://xkcd.com/792/)

</comment></comment></comment></comment></comment><comment><USER7> "This is, by necessity, a system-wide process."

This is, by design, a fucking huge defect of the underlying system calls.

Give the OS a list of folders to watch. Dropbox should not even get a callback for a file it's not is supposed to watch.

<comment><USER8> See: inotify in Linux

<comment><USER9> inotify is by far the best of the filesystem notification APIs. It's wildly reasonable.

</comment></comment></comment><comment><USER10> Quote:

"A simple protocol can give us an idea of whether data is being sent to Dropbox:

1\. Create a large-ish file (1MB) outside of the Dropbox folder

2\. Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file

3\. Repeat with many different files, etc.

Doing exactly that, Dropbox only sent a few hundred KB after "accessing" the target file. Seems unlikely that Dropbox is uploading files outside your Dropbox folder."

This test approach has a problem. A more realistic test would be to place a well-compressed file, one that by definition cannot be made smaller, on Dropbox and see what the system traffic size is for that file. For an optimally compressed file, if the system is reading the entire file, the read size will more or less equal the file size.

<comment><USER11> You're still missing the possibility of DB uploading a hash vs standard file compression. Even if they never upload the full file plenty of people would love to know if any of your files was on some list. (Classified information, piracy, etc.)

</comment></comment><comment><USER12> Well, dropbox could just listen for fs events inside the DropBox folder; and it should, from a performance perspective as well as from a privacy point of view. And then "sends a few 100 kByte"? I hope this is a typo; if not, I would like to know what these are. (also: the OP's largish file (1MB) could easily fit into "a few 100kByte" after compression)

<comment><USER13> _Well, dropbox could just listen for fs events inside the DropBox folder..._

On Linux at least [1], this is exactly what the Dropbox client does. It only registers inotify watchers on the $HOME/Dropbox directory and subdirectories. To verify:

        strace -f -e trace=inotify_add_watch dropboxd

You could also strace open/stat/read/write syscalls to verify that, aside from shared libraries and the like, the Dropbox Linux client doesn't access files outside of your Dropbox directory.

Other OSes have different file monitoring capabilities though. Anyone up on file monitoring on Windows / OS X? Is directory-specific monitoring possible?

[1] [https://www.dropbox.com/install?os=lnx](https://www.dropbox.com/install?os=lnx)

<comment><USER12> > Other OSes have different file monitoring capabilities though. Anyone up on > file monitoring on Windows / OS X? Is directory-specific monitoring > possible?

yes

<comment><USER14> But ReadDirectoryChangesW notoriously misses updates. Also it would scale horribly to large amounts of files.

NTFS has a feature called Change Journals where you can view a volume as a stream of changes.

</comment></comment></comment></comment><comment><USER15> The cycle of security is this:

1\. Security experts see a security hole and note that it could only be used by a widely trusted company or government.

2\. People note that it's also possible that it's _not_ happening, and claim that the widely trusted company or government would never use the security hole.

3\. It is discovered that the widely trusted company or government has been using the security hole.

<comment><USER16> "Touches files it doesn't have to" is not a security hole.

<comment><USER15> "Users install program that touches files the users might not want it to" is a security hole. The unknown is whether Dropbox comes with malware which takes advantage of that security hole.

<comment><USER16> A hidden function or update could enable malicious behavior on all files whether or not it had preexisting behavior of touching all files. Only in certain detailed permission structures would preexisting behavior matter.

<comment><USER15> If a hidden function enabled malicious behavior, causing it to touch all files, the hidden function would very quickly cease to be hidden.

Are you seriously arguing that it's okay for Dropbox to touch files you didn't give it permission to touch? This is ridiculous.

<comment><USER16> >If a hidden function enabled malicious behavior, causing it to touch all files, the hidden function would very quickly cease to be hidden.

I'm not sure where you're going with this. Yes, a security hole would become much more visible after it was exploited. That doesn't imply that anything visibly weird Dropbox does is a security hole.

The only notable flaw in security here is that it's a program on a normal OS outside a sandbox. This is a huge flaw but it applies to most programs.

>Are you seriously arguing that it's okay for Dropbox to touch files you didn't give it permission to touch? This is ridiculous.

I am. Touching files does not mean taking information from files. And between the explorer extension and the way file monitoring works on windows it's going to be fed a list of your files no matter what.

Security holes are a subcategory of "things a program can do, but shouldn't be able to do". They are described entirely in terms of potential behavior, not current behavior.

<comment><USER15> Okay, if you want to be pedantic about the meaning of the words "security hole" instead of addressing the actual concerns people have with Dropbox, then we can just call Dropbox "potential malware" and be done with it. Does that address your terminology concerns? Can we move on to talking about the important stuff now?

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Read their TOS and compare it to Google Drive's TOS.

The insane rights the Google TOS grants to Google are why it costs ~ 1/2 as much.

It is also an indicator that Dropbox is less shady. They don't grant themselves rights to do anything with your data outside of the normal things you need them to do to offer the dropbox service for your use.

Unlike Google, which could for instance, use your personal photos of your kid eating ice cream to try to sell you ice cream via road side LED billboards.

<comment><USER18> I think you're misunderstanding the TOS. I do not think Google is subsidizing their storage costs by abusing your private photos.

<comment><USER17> I think you aren't actually reading it. I do not think Dropbox is less good at running storage than Google or Amazon, yet Google is 1/2 the cost.

<comment><USER19> The reality here is that the cost to operate doesn't matter to Google. They can keep subsidizing Drive with revenue from Search Ads long after they have pushed Dropbox out of business, if they choose to do so.

This is why Dropbox (smartly) does not want to compete on price -- instead they want to compete on quality. There's no way to be cheaper than Google, Microsoft, Apple and Amazon in the long run, because they each have other businesses that are licenses to print money. If one or more of them decide to heavily subsidize their online storage product, they can outlast you.

However, it turns out that all of the money in the world can't magically make a great product. You still have to actually do the hard work.

</comment></comment></comment></comment><comment><USER20> " 1 - Create a large-ish file (1MB) outside of the Dropbox folder

2 - Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file

"

I can not really say if Dropbox steals them or not. But if i were a Dropbox engineer and want to know about those newly created files, i wouldn't want to send the whole file to server at all.

\- Send file name with its extension

\- Send file size

Compare these to dropbox's blacklist file (imagination only) in another server. If there are any matches, mark user as "whateveryouwant"

As long as there is a network activity when a new file created, it is and will always be suspicious to its users.

<comment><USER21> And they don't have to steal the whole file at once, why not chunk it out and do bits at a time over a few days. This is tinfoil hat territory, but they'd still get the file and network traffic wouldnt be overly suspicious.

<comment><USER22> You don't need to retrieve the file if you already have it.

</comment></comment></comment><comment><USER23> As an aside, I've been using Sparkleshare (built on GIT and SSH) lately. It's pretty good, and sucks up less battery on my MBP than the Dropbox client (maybe because it's not watching every file in the system!) And not only is it open source, but you can see a log of all the git commands and fix things manually if necessary.

My only lament is that it doesn't work that well over the intermittent connections. It'd be neat to have something robust like mosh ([https://mosh.mit.edu](https://mosh.mit.edu)) for file sync.

<comment><USER24> There is also unison; it is not automatic (custom inotify script is required to mimic Dropbox, and it will force manual intervention upon conflicts) nor stores history, but handles large blobs, many clients and crappy connections quite well.

</comment></comment><comment><USER25> The original article is titled "Dropbox Is Probably Not Stealing All Your Files". From bandwidth consumption, you can tell it's not stealing all of them. Whether it does so selectively, on command from the mothership, is another matter.

</comment><comment><USER26> "The Dropbox application uses a filesystem monitor to detect when changes are made by monitoring filesystem write events. This is, by necessity, a system- wide process. So DLP alerting that Dropbox is "acccessing" a new file shouldn't be surprising."

I think this SHOULD be surprising to any competent software engineers. That isn't how the file system watcher works.

</comment><comment><USER14> About every form of backup software will use change journals to identify what to backup and how it changed.

Change journals are streams that are per volume (so to monitor some directory in C:\ i have to monitor the C:\ change stream).

It's just how NTFS works. It's shocking that this was allowed to reach this kind of publicity because it's just a guy attaching a diagnostic tool to a system where he doesn't know whats happening and then proceeds to freak.

Software like this will have plenty of file access for metadata, not only on the backed up files.

<comment><USER27> And this is where having the API actually support, say, monitoring only items in a single directory would be good.

<comment><USER14> Well there is, but it's unreliable in certain edge cases. At least not reliable enough for a backup solution.

<comment><USER27> In which case the API is broken and should be fixed.

Also, what edge cases?

<comment><USER14> For example you have to allocate a buffer to hold the information you receive. If that's too small, you miss stuff. There is also a lot of intricacy with permissions and you can mess up a lot when multithreading without knowing how to properly interact with the OS then.

<comment><USER27> Wouldn't that be worse, if anything, for the whole-drive case?

</comment></comment></comment></comment></comment></comment><comment><USER28> This article makes me irrationally annoyed by how lazy the author was. I was able to produce a test in under 5 minutes that disproves the article's core assumption:

> The Dropbox application uses a filesystem monitor to detect when changes are > made by monitoring filesystem write events. This is, by necessity, a system- > wide process. So DLP alerting that Dropbox is "acccessing" a new file > shouldn't be surprising.

THAT IS NOT HOW THAT WORKS!

Sorry, I am calm now. As someone who has spent quite a lot of time using Windows' File System Watcher functionality, I know that that is nonsense. Windows monitoring/watching is conducted at the kernel, when an IO operation occurs that hits a registered monitor it fires off an event (windows message) to that process to let it know, the process itself never accesses that file directly.

But just test it for yourself.

1) Download Process Monitor [0]

2) Start Process Monitor, turn off Registry, Network, Profiling, and Process events.

3) Set the include (included processes to monitor) to [whatever executable you build]

4) Build this (see examples section) [1] in C#/VB.net and run it

5) Set the process name in #4 in the include in #3

6) Write to a file in C:\ (that's the default in the example program/source)

7) You should see some Console.WriteLine() output indicating the file watcher is working. If not run as administrator.

8) There you go. As you can see, no direct file accesses to the file. The monitor events are fired as you can see, but the file remains untouched directly by your program.

The author could have done this. Why didn't they? It isn't like I had to even write one line of code or have some kind of specialist knowledge of low level kernel functionality...

PS - I don't know/care if DropBox is stealing your stuff. I just wish the article's author had at least fact-checked before they claimed that "that is how this works!!!" when in reality that is untrue. That is how it works for Anti-Virus because AV scans within files to see contents, it isn't how it works for most processes which just use the file watcher functionality. If DropBox chooses to look inside files, then why? There is no need for that.

PPS - If DropBox do have a system wide file watcher, that is just lazy. It will reduce system performance, and they could have just as easily set it up to point just to folders DropBox is configured to watch.

[0] [https://technet.microsoft.com/en- us/sysinternals/bb896645](https://technet.microsoft.com/en- us/sysinternals/bb896645)

[1] [https://msdn.microsoft.com/en- us/library/system.io.filesyste...](https://msdn.microsoft.com/en- us/library/system.io.filesystemeventhandler%28v=vs.110%29.aspx)

</comment><comment><USER29> It's very unlikely that dropbox would upload every changed file from your computer, that would not go unnoticed.

A desirable capability would be on-demand upload or download of any file on the clients system. For that you would need the entire filetree+checksums so, imo, that's what it's syncing.

</comment><comment><USER30> Dropbox has too much to lose and not enough to gain by stealing your files. The accusation borders on paranoia. That said, Dropbox is a closed system, and I always trust open systems more.

</comment><comment><USER31> The tin foil hat is strong with this thread. People should read up on Windows Explorer shell extensions before making comments. It's like saying regexing email addresses to check for valid input is the same as stealing emails addresses.

</comment><comment><USER32> If dropbox get to send metadata about files outside of the folder could be damning enough.

Hey you have in your downloads folder 3 new files per day whose file names hints they were send by FB user X. I could make an educated guess about their content.

</comment><comment><USER33> Reminder that Dropbox was mentioned, by name, in NSA documents released _two years ago_ as the next target they intended to subvert. Also reminder that not long after _that_ they named Condoleeza Rice, celebrated apologist for warrantless wiretapping during the Bush administration, to their board of directors.

Yes, it's _possible_ they named her to their board in good faith, and it's _possible_ they also resisted the NSA somehow, where Google and Microsoft and Yahoo and countless others failed. But, do you consider it likely enough to bet your privacy on it? It seems to me you would be foolish to do so.

The only other excuse for it I can think of is that it's _so obviously corrupt_ that it proves they aren't corrupt after all - that no one could be that stupid. I reject such meta-reasoning. They are simply corrupt.

</comment><comment><USER34> If you are an ordinary guy then even if Dropbox steals a file it won't matter much. If you are a government, Airbus, Snowden, Aselsan, or Comodo you should not install Dropbox even if you trust Dropbox.

</comment><comment><USER3> Pure speculation follows.

I wonder if they could be calculating hashes of files and sending them off? That would be useful for automated exfiltration and targeting.

For example:

        1. Calculate the SHA-256 hashes for files in places of interest.
        2. Report the hashes upstream.
        3. Hey, this file matches one that the FBI/NSA is looking for via NSL.
        4. Download more stuff. Also identify the person and their location.
        5. Send agents/drones after them.

This is unlikely, but still in the realm of possibility. It's also untestable without more information. (Packet captures from the DLP device would be far more helpful in determining if anything of the sort is happening.)

<comment><USER35> To calculate the hash, it needs to read the whole file, which this post claims it isn't doing.

<comment><USER36> Did the author actually verify this with strace (or the mac/windows equivalent)?

It sounds like he guessed this based on I/O activity of the process. It could be enough to hash the beginning of the files, and compare the rest if a match is found in the database.

<comment><USER37> Dropbox doesn't read the file content. There is also no proof that Dropbox directly accesses those files.

</comment></comment></comment></comment><comment><USER38> Speaking of which, does anyone run apps like this with a different user than their own?

I'm thinking of something like

        /home/dropbox drwxrwx--- dropbox <youruser>

</comment><comment><USER39> Separate from the privacy concerns, what about network traffic? "a few hundred kilobytes" for every file you create adds up.

</comment><comment><USER40> Any thoughts on SafeMonk, which they claim end to end encryption and piggyback on dropbox?

</comment><comment><USER41> Uhh... no, no we are not. s/probably //

</comment><comment><USER42> Dropbox Is Probably Ready To Do So As They Want

</comment><comment><USER43> I stooped trusting dropbox when condoleeza rice got added to the board.

</comment><comment><USER44> Surely tradition requires that the title of this piece be "Is Dropbox stealing your files?". I mean, it's a complete waste of a Betteridge event.

<comment><USER45> It's in response to an earlier-submitted article: [https://news.ycombinator.com/item?id=9136546](https://news.ycombinator.com/item?id=9136546)

<comment><USER44> That is, in fact, titled in the correct manner. Maybe Betteridge doesn't count if the thrust of the article is actually to point out that "no" is the correct answer. I hadn't thought of that.

</comment></comment></comment><comment><USER46> You upload your files to dropbox servers, how in the world can you come to the delusion that you would notice when they accessed/searched/data mined your files?!

<comment><USER47> (The article is about uploading files outside your dropbox folder)</comment></comment>


Blockchain and Hackathons are poised to redefine the tech innovation lifecycle - <AUTHOR> http://www.forbes.com/sites/rogeraitken/2016/11/03/the-rise-of-blockchain-hackathons-the-hackonomy/#a011869110a3A <comment><USER2> "And, one of the most interesting outliers in this diverse space is hack.ether.camp, a global virtual Hackathon. It is a Hackathon designed to operate and be managed completely on the Blockchain through the use of Smart Contracts and disruptive attributes." HackerGold.

<comment><USER3> I've registered to the hackathon and wish everyone the best of luck.</comment></comment>


CRISPR-like 'immune' system discovered in giant virus - <AUTHOR> http://www.nature.com/news/crispr-like-immune-system-discovered-in-giant-virus-1.19462 <comment><USER2> Getting a look at that mimivirus makes me think whatever gets infected by it failed its saving roll.

<comment><USER3> I think you mean "role", though I love the image of a virus rolling a d6 to determine whether it succeeded or failed.

<comment><USER4> What, did you see the picture?

That virus is literally a D20.

<comment><USER5> pretty much all virii are "D20"s.

<comment><USER4> Really? The pictures I've seen of ebola make it look like spaghetti.

<comment><AUTHOR> You're quite right, GP is being mistakenly over-broad. Mimivirus (APMV) is an encapsidated virus, and the capsid is what forms that shape. Capsids[1] generally contain the DNA or RNA of the virus' genome and often appear quite geometric. Capsids have a T-number, which determines how many faces of triangles or hexagons+pentagons exist. It's a deeply mathematical field of study since these are, essentially, tiny repetitive building blocks.

Some (tobacco mosaic virus being the most famous) are helical, while others (bacteriophages) look completely different[2]. Viruses appearing spherical are generally enveloped, meaning they contain part of the cellular plasma membrane surrounding their capsid (HIV). Ebola is part of the filovirus family[3], which are characterized by, among other things, their long, filamentous shape (hence the name).

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

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

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

<comment><USER6> this is fascinating... makes me want to go back to school and study viruses (what field would that be?)

<comment><USER7> Virology, I believe.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Really makes you wonder if viruses were the first forms of life, contrary to popular opinion.

<comment><USER9> No. The viruses were probably the second. You need some form of self replicating metabolism, before having a virus to be able to feed on it.

<comment><USER10> I would imagine the earliest forms of life (proto-life if we use cellular structure in the definition of life) were free-floating strands of genetic material, more similar to viruses than to fully formed cells. Or if that's on the right track, we could say the first "cells" were large bowls of the primordial soup.

<comment><USER11> Take a look at the videos at this link. (the ones showing the fatty acids holding onto each other)

[http://exploringorigins.org/fattyacids.html](http://exploringorigins.org/fattyacids.html)

</comment></comment></comment></comment><comment><USER12> There is a related Radiolab episode: [http://www.radiolab.org/story/shrink/](http://www.radiolab.org/story/shrink/)

</comment><comment><USER13> Fascinating article, but it was hard for me to get past 'Immune defence'. I'm sure they meant no offence, but it coloured the rest of the text for me. (If it had been on a .co.uk, I'd have left them alone, scout's honour).</comment>


Ask HN: How do entrepreneurs find programmers to team up with for startups? - <AUTHOR>

I wanted to try to find out how startup entrepreneurs without a programming background (like myself); can find a programmer to team up with for a new start up. Do you find potential partners at events? Is there a website with a list of events that you can go to, to meet these programmers or other aspiring entrepreneurs with programming experience? Is there a network? I have the idea but getting the idea onto a website and making it work is what I'm having trouble with. Any help would be much appreciated. <comment><USER2> Startup Weekend is a big one that sounds like the perfect thing for you. It goes on twice a year (i think) in many cities. Just ask people you meet there what else is going on in the area? I have also used sites like meetup to find specific types of events for my interests.</comment>


Ask HN: Which system books developers must read? - <AUTHOR> Hello,
I have interest in low level systems and Distributed Systems. I want to go deep into these fields. I started reading following books
1. Linux Kernel Development by Robert Love
2. Designing data-intensive applications
Can someone recommend me more books to increase my knowledge? <comment><USER2> Something about networks from the hardware to layer 7 protocols.</comment>


Rust 2019 and beyond: limits to some growth - <AUTHOR> https://graydon2.dreamwidth.org/263429.html <comment><USER2> That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers.

I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. And there already is one example from a company whose founder I knew that made serious bank on just knowing what they were not, so this advice has applicability far outside of computer programming language design.

Thanks for posting this.

<comment><USER3> _> Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. _

One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what _not_ to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing in one thing is the clearest way I know to free up mental capacity for the things I do want to put care into.

<comment><USER4> I see the value of deciding what _not_ to do _for version(s) X of something_ , but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?

<comment><USER5> There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on.

Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time the version number is incremented. "Not in the foreseeable future" is effectively understood as a far out roadmap item, no matter how much you don't mean it that way.

I'd rather see a humble "we thought that we would never X, but we were wrong" repeated for many different X than a single misleading "we absolutely commit to not be adding GOTO before 2025".

<comment><USER6> > Eternity can be surprisingly short when everybody agrees that it is time to > move on.

That relies on having a decision-making process and culture that accommodates that. In my current job I'm stuck dealing with inadequate tools because of tool choices made in 2002 that no-one has the political capital to revisit.

</comment></comment></comment></comment></comment><comment><USER7> I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases.

For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of length 3 you still need to use the old style (3) notation. So now there is just one more thing to learn.

It is much easier to add "one more thing" to a language than it is to later take it out.

<comment><USER8> Let's revisit this when Rust has...

\- the number of users

\- the amount of mission-critical legacy code that _has to_ compile

\- the number of compiler vendors

\- age

... comparable to C++'s.

<comment><USER9> According to that we should all be using COBOL

Did you hear they're finally making it object oriented? The name will be ADD ONE TO COBOL

<comment><USER10> Cobol is already OOP for several years now.

<comment><USER11> > _Cobol is already OOP for several years now._

I think that was supposed to be a joke, mocking Cobol's verboseness (compare "C++", which adds 1 to C and which extends C with OOP).

</comment></comment></comment></comment></comment><comment><USER12> I have written non-trivial code in Go and Rust. My situation is C++ dev -> Go -> Rust -> Go (current day job). The shifts have been due to various circumstances on my day job.

The thing is when I moved back from Rust to Go, I had forgotten how productive Go is and I felt something like this:

[https://youtu.be/1i_Eqj7wu88?t=50](https://youtu.be/1i_Eqj7wu88?t=50) (20-30 sec video)

As someone who tried to "sell" rust in my org, I see the biggest issue is:

1\. Steep learning curve (it is true)

2\. When lot of people talk about #1 it gets amplified in the minds of people who make calls on the tech to be used

A great effort has been spent on #1 and I agree the payoff is worth it. But #2 is perception/marketing issue.

PS: I am huge fan of both Rust & Go.

<comment><USER13> Big fan of Rust as well, but this is why both Go and Rust are going to co- live. They are both amazing languages.

<comment><USER14> Personally, in my heart, I'm kinda keeping fingers crossed for a future where if one needs to/has to, one uses Rust (mostly where one would use C/C++ today, including for "squeezing the last drop of performance", and especially high risk everpresent libraries like libpng; plus as an extra, probably for highly ambitious parallelism like in Servo); otherwise, one just goes with Go (for the amazing general productivity and readability).

Though then there's also Luna-lang, which I'm hoping even stronger to become long-term a new breakthrough paradigm/tech in programming & scripting...

On a mostly unrelated note, but continuing with off the sofa predictions, I'm curious on a few more developments:

\- whether WebAsm will become the new de-facto universal architecture — at least for VMs, but I wonder if we won't eventually end up living on purely WebAsm CPUs at some point in future? (Unless WebAsm has some inherently hardware-hostile design decisions; I'm not a CPU/ISA guy to know that.)

\- then RISC-V; will it become the ultimate personal computer/device CPU in the meanwhile? Also, what may happen if both RISC-V and WebAsm start naturally competing in this domain eventually?

\- Fuchsia off-handedly dethroning the Linux kernel & ecosystem (and maybe even Windows) as the sudden standard mainstream OS (and thus also, amusingly, suddenly swinging the Tannenbaum's argument up through a semi-random caprice of Google's deep pockets)?

Especially per the last point, I wonder if we'll eventually end up in a world with much more... "secure"... personal devices. And if yes, will it end up being net good or bad (or just neutral/hard to say/nuanced, a.k.a. both, as usually) for humanity. Given that I'm recently realizing that "secure" unfortunately seems to be a very close sibling, or even maybe just an other face of, "closed" — think DRM, walled-garden ecosystems, no more rooted Android or XBOX... or even no more control at all over your PC, a.k.a. no general computing for the masses, potentially. Though I personally stay mostly hopeful on this front; in part because I think I believe people are as a sum too chaotic for this to be able to happen completely.

<comment><USER15> "Secure" Personals devices with a Kernel developed entirely by Google? Sounds like a nightmare.

</comment></comment></comment></comment><comment><USER16> As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?

<comment><USER17> Some stuff is quite nailed down, some stuff is not. In the end, not breaking existing code is the most important thing.

These things are always on a spectrum. Just because a spec exists doesn't mean that it has holes; Go's spec isn't formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof?

The answer is that it's all a spectrum. Many languages don't have anything resembling a spec at all!

(We are interested and actively working on such a thing for Rust, but we're shooting high. It's gonna take a while.)

<comment><USER18> > Go's spec isn't formally proven, for example, so you could make a similar > claim: how can people know that it all works without a proof?

that's moving the goalposts. let's see Rust's language spec finalized first, then we can talk about it being proven. without the two you shouldn't throw stones.

<comment><USER16> I actually think a mathematical-flavored spec where a proof would be meaningful would be a bad idea to the extent that it makes the spec less readable by ordinary users. For example, Dart has a more mathematically flavored spec and it's not readable by most people.

Of course, formalisms can still be useful, but as a matter of writing style, maybe it's better to put that sort of thing in an appendix? (As sometimes done for grammars.)

<comment><USER19> One can generate an informal spec from a formal spec.

One can NOT generate a formal spec from an informal spec (or else that "informal" spec would actually be formal, after all).

So, a formal spec is strictly better than an informal one — it enables all the benefits of an informal spec, via the ability to generate any number of informal specs from it in many human languages, cultures, levels of detail, etc., and of course enables things like compiler reproducibility (which you cannot do at all without a formal spec).

That being said, any spec is probably better than no spec.

<comment><USER16> Since many programmers are not mathematicians, a formal spec will always have a smaller audience than a well-written spec written in English. You cannot automatically derive good writing from pure mathematics.

As a result, neither is strictly better than the other. They have different audiences and serve different purposes. The audience for pure mathematics is quite small.

</comment></comment></comment></comment></comment></comment><comment><USER20> > Reputation for overcomplexity, loss of users. Becoming the next C++ or > Haskell.

I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this.

What you can do is look to make simplifications as you add complexity.

And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having them.

<comment><USER21> There are only two types of languages, those that are too complex and those that aren't yet.

<comment><USER22> There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

<comment><USER10> And sadly lost its opportunity to Java in the late 90's.

So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.

<comment><USER22> If you are interested, I can recommend the Oberon compiler OBNC: [https://miasap.se/obnc/](https://miasap.se/obnc/)

<comment><USER10> Thanks for the heads up, I am quite aware of Oberon's ecosystem though.

You can check Oberon's history on my website.

</comment></comment></comment></comment></comment></comment><comment><USER23> It's interesting to see this critique of the Rust language's development process. There's a lot of process. Most of it aimed at adding new features. That may be part of the problem. The Go crowd seemed to know when to stop.

I've criticized Rust's growth here before. The big breakthrough in Rust was the borrow checker. Finally, one could have memory safety without garbage collection or reference counting. Huge improvement.

"Unsafe" opened too big a hole. I was looking forward to seeing more work on eliminating almost all need for "unsafe". Backpointer support. A way to talk about partially initialized objects. More static analysis. But that didn't happen. Instead, feature after feature was piled on, like C++. Individually, the features aren't bad, but cumulatively, Rust is now a very big language.

Meanwhile, C++ has been trying to retrofit Rust ownership semantics using templates. There's too much "be very careful" associated with that.

<comment><USER24> All of those unsafe "hole fixes" are features, meaning your desires are for adding even more features.

Additionally, useful back pointer support (i.e. for anything more than a toy doubly linked list) is probably a bigger feature than anything else added since Rust 1.0, and probably harder to work with.

<comment><USER17> ... and basically an open research question, whereas the features we're talking about adding are generally less novel.

</comment></comment></comment><comment><USER25> I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likely to make those who know the most, more powerful (they know how to use all the features), and its negative impact is on new learners, i.e. those who have little or no voice in these decisions (for obvious and often good reasons). Thus, it becomes a form of pulling up the ladder after you. Not that this phenomenon is in any way limited to coding, of course.

<comment><USER26> As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.

<comment><USER27> Yes, I think you could know "all of" of JavaScript in 2009, in the ES5 era. Does anyone even remember that anymore? I'm shocked at how much the language has changed.

I was experimenting with server-side JS in 2009, before node.js was released, and I hacked on Brendan Eich's Narcissus interpreter, which gave me a good sense of the language.

Now when I look at example JavaScript code on the web, I invariably find something foreign. I'm not saying it's bad -- just foreign for somebody who uses the language only occasionally.

I don't believe JS should be a language only for "full-time JS programmers". I use 3 or 4 other languages regularly, so it's not nice when one language wants to hog my mental bandwidth (unfortunately C++ is one of those languages, so I know this problem well).

It seems like everybody forgot what Crockford was saying back then? He talked a lot about the failed ES4 project (which ironically Graydon Hoare was a part of (?)). And ES5 was very restrained as a result, and I think mostly successful.

It seemed this idea of restraint went completely out the door soon afterward, and nobody even remembers what was discussed 9 years ago. Crockford seems to have moved on (as well as Ryan Dahl). I haven't followed the JS language changes that closely, so I could be wrong, but I have the impression that it's completely changed.

\-----

I don't think I'm alone, as I remember that Bryan Cantrill recently said that "Brendan Eich never wrote a book about JS". In other words, the language was left without a founding philosophy. It's been an accretion of convenient features, some of which may be regretted in a couple years' time.

There was a Strange Loop talk about this too regarding the lack of history/culture in JS.

It seems like the same thing may have happened with Rust, since Graydon isn't an active contributor by his own admission.

<comment><USER26> Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time.

I was reserving my thoughts about ES6 until I worked with it for a while, but now that I have, I have to say for those reasons you cited I don't like it as much as ES5.

<comment><USER28> Can you give an example of the aspect of restructuring you consider confusing?

<comment><USER26> "Confusing" is perhaps too harsh (although destructuring over several levels can be terribly confounding). By "hard to read" I mean primarily the fact that when you are "scanning" code, destructuring statements are syntactically way too similar to literal declarations. It severely degrades, IMHO, the speed with which you can effectively "scan" code in JS. It's not really that you _can't_ understand it when you slow down and analyze - it's that you _have to_ slow down to see the difference between "let a = [0,1]" and "let [,a] = [0,1]". Whereas in ES5, whenever you saw the brackets you could know without reading into the code there was an object or array being declared.

That's not to say that I think destructuring is all bad - it certainly saves lines of code - but aftet working with it for a few years, I would gladly trade it back for more scannable code, easier syntax for beginners, etc.

</comment></comment></comment></comment></comment></comment><comment><USER13> I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.

<comment><USER29> `failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`.

There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate.

The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it in applications but avoid it for libraries.

<comment><USER30> Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust.

Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines of error handling. It still does all the exact same stuff, and if you use its generic Error impl it behaves the exact same way as the std trait.

If Failure stops getting updated.. fine? It doesn't need changing if it works right now, on the 0.1.3 release, for you. If Rust's error trait changes it breaks all libraries anyway and would only happen in the next edition. Thats probably three years out!

<comment><USER29> > Anything that would break failure in libraries written now would break all > libraries because it would mean the fundamental Error trait has changed. > Since failure is Error compatible you don't lose anything using it. Its only > ~2500 lines of Rust.

If you expose failure in your public API and failure makes a breaking change, it is a breaking change for your API because your clients need to be on a compatible version of failure.

<comment><USER30> Your clients don't though, you can have multiple versions of a crate in your build tree. Your failures aren't then compositable with newer failures as failures but they do impl Error and can be used as standard errors.

The alternative is to just use... standard errors anyway? With the aforementioned sizable boilerplate? There's no downside to failure unless there's a less volatile error replacement you'd use instead.

<comment><USER31> That you can have multiple versions of your crate is exactly what enables the issues caused by public dependencies. It's not about multiple versions of _your_ crate, but rather, multiple versions of the failure crate. If failure 0.2 is released (and doesn't use the semver trick), then you'll have two versions of the Fail trait, and thus, two versions of the failure::Error trait object. Madness then ensues for anyone using failure::Error (or dyn Fail in general).

failure is a victim of its own success. I think most everyone believes it's pretty close to what we want Rust's error handling story to look like. But it's a public dependdncy and everyone started using it. Now it's more difficult to evolve.

</comment></comment></comment></comment></comment></comment><comment><USER32> The Rust documentation is a bit outdated:

[https://www.google.com/search?q=rust+tour](https://www.google.com/search?q=rust+tour)

the 1st result is "A 30-minute Introduction to Rust". Going through it requires 4 navigations from the user to get to a valid page, everything in between is deprecated

<comment><USER17> Interesting! That page has been deprecated for something like four years... thanks for pointing this out. I've seen people mention other pages before, but never this one.

<comment><USER33> I'd also like to mention that getting to the documentation for anything with Rust is fairly annoying, mostly because a ton of the stuff in the book links to the first edition and getting from the first edition to the current one is really cumbersome. It'd be great if you would be redirected from the old book to the latest version instead of getting to it and only get a warning that it isn't the latest version. Especially since there's no easy way to go from the first edition chapter to the corresponding one in the latest, it's at least three-four clicks and annoys me every single time.

<comment><USER17> Can you please file bugs when you see this? I'd be happy to update them to point in the right place.

We have some constraints that make plain redirects really hard; we cannot run a web server or use a ton of JavaScript, for example. Maybe this situation is painful enough for community consensus to change...

<comment><USER34> > we cannot run a web server or use a ton of JavaScript

Just curious, why are those constraints there?

<comment><USER17> The documentation is distributed locally, as static files, as well as being available on doc.rust-lang.org. This is considered a big feature.

I personally would love to tell people "sorry, you have to run a basic web server, even locally" for a few reasons, but it doesn't feel socially viable at the moment, sadly :/

<comment><USER34> Here's one way you might be able to make the case: If you require a web server even locally, then the docs can be installed as a single file (zip archive, SQLite database, etc.). This would eliminate the overhead of lots of small files on at least one popular desktop OS, speeding up installation and updates.

<comment><USER17> This is already an active discussion, yep. We'll see...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Excellent. These are things designers of other languages should have considered but didn't. Looking at you, C++. I write mostly C++...

<comment><USER36> To be fair, C++ did a lot of research that the Rust designers then could learn from. I hope that C++ will get replaced by something simpler but it's a phenomenal success story.

</comment></comment><comment><USER37> The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this:

GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languages are forgettable sugar, and making consistencies of various sorts tractable.

I would argue that even outside of languages as we conventionally think of them, the lack of separating functionality into core languages/interfaces and sugar is the central failure in letting complexity spiral out of control. And indeed, just about everything has.

<comment><USER38> That is not an important facet at all. It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users.

No amount of pretending otherwise will change that. No amount of separation will change this. It does not give you any more ability to change the syntax over time, or get it righter.

Your users care _only_ about this syntactic interface. In a good world, they do not care how the rest happens in practice.

Worse than this, the idea that a mid level IR should be the "thing that keeps the syntax in check" seems beyond broken. The lower levels do not drive the higher level in roughly any case. Instead, they exist to serve the higher levels. First you understand what users want at a high level, then you try to understand how to make it fast/well. If you need to change the mid level IR to do so, you do.

There are nothing but tradeoffs in mid level IRs, and those tradeoffs change over time based on the needs of languages, not the other way around.

Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language"

<comment><USER39> While I generally agree with your point, D/Walter Bright slightly disagrees with the sentiment. One constraint for D is "must not require data flow analysis" because that incurs a cost on compilation time. Afaik this was mostly inspired by Javas definite assignment rule [0]. If fast compilation is a goal, then a language is constrained by implementation and IR aspects.

[0] [https://docs.oracle.com/javase/specs/jls/se6/html/defAssign....](https://docs.oracle.com/javase/specs/jls/se6/html/defAssign.html)

<comment><USER40> This is a perhaps over-fine semantic distinction, but I would argue that there's a qualitative difference between IR/language implementation and compilation speed. The former should not drive the language's features; the latter _is_ a language feature.

<comment><USER37> IMO most discussion of the compilation speed is incredibly narrow-minded. We _incremental_ compilation more than anything else. Programs barely change each rebuild, so that should solve all the performance problems without having to maim ourselves.

</comment></comment></comment></comment></comment><comment><USER30> Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language?

The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they _need_ them. And in the absence of having this functionality (example - we JUST got const fn this month in stable) you have to work _around_ the weaknesses of the language in often obtuse and cumbersome ways... such as hacking the macro system with lazy_static.

I think a lot of this sentiment comes back to what makes a language _hard_. I recently started learning CSS properly for once, now that Grid is in and I can just do all my styling by hand again in the same way I can use ES6 instead of JS frameworks. I needed Bootstrap and JQuery back in the day because despite the simplicity of the fundamental languages there were things I _wanted to do_ that I _could not do_ in an intuitive way. So other people wrote thousands of lines of code to make what should have been simple and accessible but the languages weren't expressive enough.

On the inverse, you need some degree of intuitiveness to your design. If I didn't read about the syntax of [<name>] col [<name>] col in CSS Grid I would have never intuitively thought you could name Grid regions. The syntax is completely arcane and arbitrary, isn't based on anything else common to CSS, and just happens to be. _That_ is the source of real complexity in a programming language, not how long the book is or how many pages long the standard library is. Nothing worth learning or doing is so simple as to be digested in a weekend and trying to make a programming language like that, especially a systems one - one that has to expose all the jank complexities of how computers actually work - would have you make a really pretty paper weight nobody could use to get real work done.

The complexity in C++ is not in how big the template library is, or how many glyphs the syntax uses, but in how much mental stress it is to see void* = 0 or new Foo and have to juggle all the edge cases and eccentricities of the grammar and model on every single line. Its a massive weight on ones shoulders and _that_ is what will drive a newbie away, at least a newbie with the mindset to take advantage of what they learn. Not the length of your book, so long as all those chapters are about things people want, need, and that are beneficial to the user, rather than warning them about all the ways they can break everything with a single character or how arbitrary decisions were made incongruent with the rest of the language because thats just the way it is.

C++ and C are not complex for their expressiveness, they are complex for their arbitrariness and lack of consistency. Same way Javascript and CSS are complex. Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would. Until they need const functions they don't need to touch them and can write all the non-const Rust they want. But now they _have_ const when they need it and can often never touch something crazy like lazy_static again.

<comment><USER37> Yes this hole thread makes me think we have a bunch of people who think complexity = initial learning curve. No wonder most of our industry is an inscrutable inconsistent mess.

<comment><USER41> Allow me to summarise the pitfalls of any sweeping 'keeping features out of the languge spec will prevent users from having to deal with the complexity burden of those features' assumption with a story:

Once, long ago, there was a new programming language. It was lean and mean. Partly to keep codebases understandable to all, and to make the language easy to learn and straightforward, it eschewed both having too many features, and having any feature that was too abstruse. People marvelled that the whole language, standard library and all, could fit in a nutshell. The name of the language was Java. The end.

<comment><USER37> Yeah understanding the forest is more important than understanding the trees!

</comment></comment></comment></comment><comment><USER42> Rust can force a programmer to be disciplined and that's good as far as it goes, but sadly no current language can force (or even encourage) a programmer to think critically at an architectural level. Indisciplined coding leads to security issues (at least immediately), but a poor architecture can mean a complete failure of the project to meet its goals, never mind exceeding them.

<comment><USER17> One claim about Rust that's increasingly common is that its language constraints _do_ require you to reconsider architecture. See [https://kyren.github.io/2018/09/14/rustconf- talk.html](https://kyren.github.io/2018/09/14/rustconf-talk.html) for example.

</comment></comment><comment><USER43> I'd read the other two latest posts on this blog for context:

The Planning System: h[https://graydon2.dreamwidth.org/262512.html](https://graydon2.dreamwidth.org/262512.html)

More Galbraith: [https://graydon2.dreamwidth.org/262669.html](https://graydon2.dreamwidth.org/262669.html)

</comment><comment><USER44> Sure, we can limit the language growth, as soon as we get all the critical features in!

<comment><USER45> Every feature is a "critical feature" to someone. You have to know when to stop.

<comment><USER46> Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.

<comment><USER47> Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code?

SIMD at least has hope of running on bare metal. I suppose the ideal is to have it adjustable: compiled to non-SIMD, using typical SIMD hardware, using implicit threads (and thus needing OS support), or using SIMD hardware with threads.

I fear the high-level web developers are in the driver's seat, which may doom rust as a systems language. I'm hesitating on rust because I would miss bitfields and various unsafe performance features. I like the opt-out safety of the "unsafe" keyword, but I want more things that I can opt out of. I want goto, computed goto, no-default switches, something like Microsoft's __assume keyword, and all the other low-level stuff you'd want for making boot loaders and high-performance kernels.

<comment><USER48> > Async/await appears to require runtime support, possibly even a modern OS. > Wasn't rust supposed to be suitable for writing bare-metal code?

You're probably thinking of Tokio, the library for async network IO, which obviously depends on an OS. The async/await language feature compiles down to basically a state machine and has minimal runtime requirements. I'm looking forward to using it on bare-metal microcontrollers.

</comment></comment></comment></comment></comment><comment><USER49> Have other languages or libraries anything like the proposed anti-feature RFC that bans adding features in a particular direction?

Go with its ban on generics that they hold for 10 years comes to mind. Anything else?

<comment><USER50> Go never banned generics, it just set a very high bar of integration with the rest of the language.

The idea is that Go is one language with a very specific personality: if it changes that much it just becomes another language and can as well be called something else.

</comment></comment><comment><USER51> any shop that is considering Rust would need to consider the question of how to hire or train a sufficient number of programmers. With any mainstream language you have a big pool of programmers up for hire, my guess is that this is more of a problem with a new languages like Rust.

Maybe that's the reason why they did hype Java to such an extent when it was a new platform, i think SUN understood that it is quite difficult to gain acceptance as a mainstream player in this game.

</comment><comment><USER52> >Magnifying inequality: only the most-privileged, available, energetic, well- paid or otherwise well-situated participants can keep up. >privilege this privilege that

Shit like this is why I will never touch this language.</comment>