Ask HN: Why no tags on HN? Is there a 3rd party HN index with subject tags? - <AUTHOR> I often find myself willing to look at a list of everything that was posted on HN on a particular subject. E.g.  machine learning, neuroscience, privacy, education, Android or whatever... Is there such a list somewhere? <comment><USER2> This may sound snobbish, but I love the barebones design of HN.

Makes it very inaccessible, and the only ones who stay are those that really want the content.

Acts like an artificial barrier that keeps the more trigger happy out.

<comment><USER3> Excuse my simple mind, but how would that possibly sound snobbish?

<comment><USER2> Because the UI is innately designed to be exclusive and not inclusive, and I would like for it to stay that way.

The implication here is there are certain well intentioned people who the community would rather not have on HN.

Clearly only tech-savvy people and those with a knack for sticking with things with a learning curve would stay on HN.

This makes the nature on discussion here wired towards people of that kind. These people (for better or for worse) on an average tend to take questions at face value and answer them than assume an ulterior motive behind an opinionated comment.

I like that about HN, and would not want it to become like other internet comment threads.

<comment><USER4> There's nothing particularly "exclusive and not inclusive" about Hacker News' UI, it's just a basic forum. If it only offered an API and required users to write their own clients, you might have a point about it filtering out nontechnical users who are willing to deal with a learning curve, but literally anyone who uses the web knows what they need to to use this site - type into a textbox, push a button.

4chan has an equally simplistic layout with arguably more of a learning curve than here, yet its culture doesn't have the qualities you describe.

The inverse correlation you're trying to draw between the simplicity of a site's layout and the intelligence of its userbase appears to be contradicted by lobste.rs, a more deeply technically oriented forum than Hacker News, which uses tags. Also by simply _reading_ most threads here, you'll find little more depth or intellectual insight to them than a similar thread on Reddit might provide.

<comment><USER5> lobster.rs requires an invite, no? I know it's not hard to get one, but that's an actual step you have to take in order to engage, which keeps the lazy out.

The same thing goes for HN. Why would you go through the effort to make an account for an ugly site when there are better looking options available (Reddit, Facebook, etc)?

Yes, it doesn't have much to do with intelligence, but it certainly drives away many of the people who would otherwise make low-effort submissions. In fact, I wish it were even _more_ barebones (e.g. remove the user points in the corner).

I used to think HN should have more features, but then I used Reddit and came back wanting fewer features. I like how it's simultaneously inclusive (anyone can create an account) and exclusive (somewhat ugly, no memes).

<comment><USER4> >Why would you go through the effort to make an account for an ugly site when there are better looking options available (Reddit, Facebook, etc)?

The effort is minimal, and I don't think most people choose whether or not to join a site based on how pretty it is. Just look at Craigslist for instance.

>but it certainly drives away many of the people who would otherwise make low- effort submissions.

I don't think there are actually a lot of people being turned away from Hacker News because of the layout who otherwise might join if it had more features. Remember that the entire pool of potential users for Hacker News includes anyone who even knows that it exists -- this is not a mainstream site and it doesn't have a lot of exposure outside of technical circles. No one browsing the main subreddits or Twitter or Facebook is likely to ever see it even mentioned.

That an "ugly" layout keeps low-effort users away seems to be a common belief and I think it's one espoused by pg, but the claim seems a bit like that made of a tiger repelling rock ... the only "evidence" that it works being the absence of any tigers.

Although... Hacker News has plenty of low-effort submissions, and people who complain about it "turning into Reddit," which was once cited as a "common semi-noob delusion" in the site guidelines, it's such a common occurrence.

</comment></comment></comment></comment></comment></comment><comment><USER6> Tagger News might be what you're looking for: [https://www.taggernews.com/](https://www.taggernews.com/)

It was a TC Disrupt hackathon project that generates tags using AI, and seems to still be functional.

<comment><AUTHOR> Thanks. Looks exactly what I'm looking. Just sad the set of tags is so humble.

<comment><USER7> Humble is bit of an understatement. Enough of them are just assigned wrong.

</comment></comment></comment><comment><USER8> I'm glad there's no obvious tagging on the front / new pages. I open way more links because something sounds interesting in the title. I'm sure if there was tags it'd bias my clicking...

</comment><comment><USER9> While it's not broken down into such specific categories, Hacker Newsletter [0] is a great way to get a weekly summary of posts separated into topics. For instance, here's [1] their most recent one, where you can see posts broken down into sections like code, data, design, learn, etc.

[0]: [https://www.hackernewsletter.com/](https://www.hackernewsletter.com/) [1]: [https://mailchi.mp/hackernewsletter/424](https://mailchi.mp/hackernewsletter/424)

</comment><comment><USER10> [https://hn.algolia.com/?query=machine%20learning%20points%3E...](https://hn.algolia.com/?query=machine%20learning%20points%3E10&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

[https://hn.algolia.com/?query=neuroscience%20points%3E10&sor...](https://hn.algolia.com/?query=neuroscience%20points%3E10&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

[https://hn.algolia.com/?query=privacy%20points%3E10&sort=byD...](https://hn.algolia.com/?query=privacy%20points%3E10&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

[https://hn.algolia.com/?query=education%20points%3E10&sort=b...](https://hn.algolia.com/?query=education%20points%3E10&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

[https://hn.algolia.com/?query=Android%20points%3E10&sort=byD...](https://hn.algolia.com/?query=Android%20points%3E10&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

</comment><comment><USER11> That's one of the reasons I created MediaTag [0], to be able to save pages and see associated tags next to the links. Here is how my HN favorites look like: [https://mediatag.io/gui/items/f117244b-mediatag- hn](https://mediatag.io/gui/items/f117244b-mediatag-hn)

[0] [https://mediatag.io](https://mediatag.io)

</comment><comment><USER12> There's a search box at the bottom of the page. Have you tried that?

</comment><comment><USER13> For what it's worth, I prefer it without such lists. Although HN has guidelines on what are acceptable posts, I like the fact that quirky, interesting and completely irrelevant posts occasionally make it through.

If HN had sub-lists, I'd feel compelled to use them, and I'd miss out on a whole bunch of things.

I also agree that keeping a simple UI is what helps keep, in part, HN exactly what it is.

</comment><comment><USER14> Funny that you say "machine learning", because that's exactly what you can use to replace tags with.

<comment><AUTHOR> I know but I find it rational to check if there actually isn't a sufficiently good implementation of your idea already before you start "inventing a bicycle".

</comment></comment><comment><USER15> I prefer to not have tags on HM. -> Keep It Simple

</comment><comment><USER16> For what it's worth (I know you specifically mentioned HN), Lobsters has tags.

[https://lobste.rs/](https://lobste.rs/)

<comment><AUTHOR> Looks very curious. Thanks.</comment></comment>


How to Hire a Head of Customer Success for Your Startup - <AUTHOR> http://tomtunguz.com/customer-success/ <comment><USER2> This really isn't about how to hire a head of customer success so much as why you need one, which you absolutely to. Not necessarily in name, but in practice. Churn is a killer, a first silent (because at small revenue, new growth masks it) then very noisy.</comment>


Ask YC: team that you wanted to fund, but one member you didn't like? - <AUTHOR>

A couple guys I collaborate with want me to join them on their YC application. I'd like to do it, but I'm old and I've already been rejected by YC twice in the past (once with written, once I made it to the in person interview). I'm worried that having me a part of their submission will lower their chances of getting in. I think they have a good chance otherwise.<p>Have you ever had a team that you wanted to fund, but ultimately decided against because of just one member of the team that you didn't like? <comment><USER2> Depends how many total founders there are, and whether the one we were dubious about was CEO. I don't think we'd fund a co if we didn't like the CEO. Whereas if there were 3 founders and we disliked one who wasn't the CEO, it probably wouldn't be a problem.

Incidentally, you are probably overestimating the degree to which you'd lower their chances. We often fund groups on the nth try. PagerDuty was those guys' fourth try. Even Dropbox was Drew's second try.

<comment><USER3> In the case of solo founders, what do you do?

<comment><USER4> Here's Drew's application <http://dl.dropbox.com/u/27532820/app.html>. It's a good read.

<comment><USER5> It is on Google docs ;)

</comment></comment></comment></comment><comment><USER6> OT (but i am really interested in hearing the answer): how old is "too old" to apply for YC?

<comment><USER7> And another question: what is the average age?

<comment><USER8> 26 on their FAQ page</comment></comment></comment>


Ask HN: To work at Google or a Startup? - <AUTHOR>

My career is at a crossroads and I would really appreciate the community's insight and experiences.
I'm 22 and graduating next year. I'm currently an intern at Google in a business development role. It's likely they will offer me a role in the AdWords sales team which would interest me but having spoken to existing people in the sales team, I am beginning to think it's not for right role for me.
My passion, however, is in startups and I've dreamed of moving to the Valley to join a startup and soak up the entrepreneurial spirit and network among the people I have read the blogs of for so long. In the past I've worked at a fast growth tech startup in a European Incubator (business development) and loved the challenge and the fact I could make a big impact.
Do I take the 'ok' role at Google for a few years and enjoy the perks, stable pay, and brand recognition? Or do I follow my dream now and join a startup in the Valley? It's hard to turn down Google (my parents can't understand why I would even think about doing that) but I know I'll end up in a startup anyway so I feel 'why wait'- join one in a years time.
It's important for me to move to San Francisco- I feel I need to experience it at least for a few years. I'm interested to hear your thoughts based on your experience on what would be the best way for me to develop my skills out of college. It's a tough life decision and I really appreciate your insight and advice. <comment><USER3> Andy Rachleff has advice about this: "go work for a big company and learn how the best of breed does it, then go start something when you know how and are ready." There are a few caveats to this:

1\. Make sure you have a great manager who will help you learn, expose you to good experiences, and support you in your career 2\. Join a company where you will be doing something where you learn a lot. Google is a mixed bag for this from what I understand.

I specifically didn't follow this advice. I graduated (from grad school) and started something immediately, but I do believe roughly in the mantra: "if you aren't sure if you want to do a startup, you probably don't want to do a startup."

My advice, if you go to a big company, though, is to extremely aggressively save. Live like you would on a startup paycheck (or less). If you get used to sweet benefits and a big paycheck, it will make it much harder to leave and start something.

<comment><AUTHOR> Thank you for your thoughts. It makes a lot of sense to work for a large company, see how things are done, and then apply these to either my own company or a startup I join.

</comment></comment><comment><USER4> (Re-posting comment since edit doesn't seem to work?)

I'm 23, and I graduated from Computer Science in 2012. I worked 8 months at a subsidiary for a FTSE 100 company, then I left and joined a much smaller company. Through that move, I gained an opportunity to work in Asia, which I took, and I've been here for almost 12 months now. I love every single minute of it. Rather than try to advise you on decisions I've only recently made myself, I'll offer a brief overview of my time at each company:

Startups/small companies in general are different (I did several bits of work between school and leaving University, my two jobs listed above are only "salaried" experience, not all my experience). Things are "fast and loose" \- I read that somewhere, but it's true. I've had decisions made one day turned over the next, and this really screws with the development process. They're fun places to be, with people motivated and passionate about the company vision, and every opinion counts in a small company.

Larger companies let you learn things. I learned so much from my time at a large company, I'm still figuring some of it out. At least half of my marketable skill-set came from those 8 months. When I left University, I'd written a single implementation of Boids in JavaScript. Now I am employed full time as a Front-End JavaScript developer in a foreign country. Larger companies can still be fun places to be, but they're a lot more _robust_. Things change slowly, and this can be frustrating. But they also use some awesome tech, and they can be an excellent place to "skill up".

With regards to other comments:

If a startup fails, you are _not_ going to be thoroughly screwed unless you had a primary role in screwing it up - you took a risk, you took initiative and you will have had significant input on the company's product or solution - employers will value that

The comments about getting used to benefits and a big pay-check are true - <USER2> variety of factors caused to me to move companies, and I took one hell of a pay-cut doing it - that's not an easy thing to adjust to

Great managers are a must. If you go for an interview anywhere, ask to meet your supervisor, or whoever you'll be reporting to most of the time. I learn as much from my managers as my colleagues.

Talk of larger companies exposing you to other large companies and brands is true, but at the same time we are a company of <150 employees working in partnership with Google, Red Hat, and Samsung. Smaller companies do not automatically equal smaller opportunities.

Sometimes I think I should have chosen the smaller company first. However, I realise that I only think that because I have the experience of a larger company to draw upon. If I _did_ choose the smaller company first? I imagine I'd sometimes think I should have chosen the larger company instead :P

One final comment: I'm originally from the UK, and we don't have anything like the Valley, despite what various MPs and Ministers would like to believe. San Francisco is not a requirement for life in a startup, and I've never understood the glamour associated with it - maybe that's because I've never been so I don't know what I'm missing, but I'm perfectly happy here :)

</comment><comment><USER5> The founder of the startup I'm at now, imgix, had this to say about it:

[http://blog.chriszacharias.com/cruise- ships](http://blog.chriszacharias.com/cruise-ships)

Google is a cruise ship. You're young and agile in a way that you'll likely never be again. As a result, you're more risk-tolerant as well.

Risk accordingly.

Despite that, don't confuse commitment and risk. The bay is a big place. It's expensive to live in, and full of unlikely opportunities in equally unlikely places.

Find a month to month lease if you can, or crash with somebody you know. Don't lock yourself down with a long lease, the environment moves too fast and your priorities will evolve even faster once you hit the ground here. I think you'll appreciate the agility. It's a mistake I made, and would probably change given a do-over.

Another miscellaneous thought: there are so many startups and things like this going on in the bay that it's actually a bit of a blur, and while it's easy to meet many people doing what you describe, they're all very much wrapped up in their own version of the story. A job at google actually gives you proximity to bigger names, for longer, and with more purpose. From a networking standpoint, that has value. I don't think it negates the sole-suckingness of a giant org for someone with your personality, but it's at least worth noting.

</comment><comment><USER6> Experience trumps all, whether you start at a large corporation or a bootstrapped startup.

I know a handful of people who've worked at YouTube, Microsoft, etc. who earned great experience and ended up starting their own companies shortly after.

My personal recommendation would be to go the startup route, and even if it doesn't pan out, future employers will take notice of your effort and will make you more employable.

</comment><comment><USER7> Just remember, live the present! So follow your dreams, it must be difficult to say no to Google. But it will be more difficult to regret all your life, that you did not follow your dreams when you can. Just keep in your head, you only live once, so follow your DREAMS, it's your life you have TOTAL control of it, and never regret from any decision you take and took because all of them are Correct in the time you take or took them, there are not incorrect ones just less accurate, and more accurate ones, but you only will discover that in the future! So good luck! and be sure whatever you choose will be the CORRECT decision.

</comment><comment><USER8> If you work at Google but that doesn't work out, you can always leave and do the startup thing.

If you work at a startup and that doesn't work out, you're thoroughly screwed.</comment>


Symply | Ask yourself important questions every day - <AUTHOR> https://symply.me?ref=hn <comment><AUTHOR> Ask yourself important questions every day to keep yourself accountable for your life. Track your habits and goals</comment>


Xiaomi Offers a Phone, Laptop, Mi Band 3, BT Headset for the Price of an iPhone - <AUTHOR> https://www.xda-developers.com/xiaomi-offer-smartphone-laptop-wearable-headset-same-price-iphone/ <comment><USER2> and i don't want any of them, because i don't trust xiaomi with any of the personal data these things store</comment>


Darpa's Simulated Cat Brain Project a 'Scam': Top Scientist - <AUTHOR> http://www.wired.com/dangerroom/2009/11/darpas-simulated-cat-brain-project-a-scam-top-neuroscientist/

<comment><USER2> If this is true that it is simply an Artificial Neural Network, then it really is a scam. I was under the assumption that it was part of the IBM Blue Brain project, but it is obviously not. For some real ground-breaking research, take a look at Blue Brain: <http://bluebrain.epfl.ch/>

<comment> a-priori (Disclaimer: I work for the Blue Brain Project. What I say is my own opinion.)

It's not just an ANN like you may have learned in school. They refer to their model as "single-compartment phenomenological spiking neurons, learning synapses with spike-timing dependent plasticity, and axonal delays" in their _The cat is out of the bag_ article.

In simpler language, it's a spike-based model (when someone says "artificial neural network" they usually mean a rate-based model) where they adjust synaptic weights based on the correlations of spikes (Google: spike-timing dependent plasticity), and add a transmission delay before a spike arrives at the post-synaptic cell.

It sounds very much like the model described in _Hebbian learning and spiking neurons_ (Gerstner et al., 1999).

This is a more sophisticated model than most neural network models, but it's still very much abstracted from biology. For starters, it doesn't sound like they model a diversity of neuron structures, nor even ion channels or dendrites.

This is where this "Blue Matter" project differs from the Blue Brain Project, which is attempting to model the biology is as fine detail as the science (and the computing hardware!) allows.

EDIT (forgot to get to the point):

Is it a scam? That's open to interpretation, but I agree with Dr. Markram that they are making fantastic claims and glossing over the fact that they are _not_ modelling anything resembling a cat's brain except in neuron count.

<comment><USER3> You work for the Blue Brain project? That's amazing. Do you have a blog or anything where I can find out more? Can you tell us more about what it's like? I think it's one of the most fascinating projects going on right now.

<comment> a-priori I'm just finishing up an internship with the project, and I don't keep a blog. Sorry :)

That said, it's a very cool project with a great group of smart people. I'm very optimistic about its future.

<comment><USER4> I follow AI quite a lot and I'm curious if there is much talk about the future of memristor and brain emulation within the project seeing as a hardware variable analog would seem the ideal medium for such things. I know when this technology came out AI was what first came to mind.

Working for the Blue Brain Project would be my dream job as a programmer/engineer. I'm curious how you came about your internship? I'm desperately looking for a challenge and this type is research would definably be my first choice.

<comment><USER3> That would be my dream job too. One obstacle is that it's in some foreign country, Switzerland I think?

</comment></comment></comment></comment></comment></comment><comment><USER5> "I think the proper response here is: mee-yow!"

No, the proper journalistic response is to _investigate the facts_ and find out what is really going on.

</comment><comment><USER6> This is awkward. I hope someone investigates this thoroughly.

</comment><comment><USER7> Looks like the source code to this already leaked:

1 PRINT "Meow"

2 GOTO 1

</comment><comment><USER8> Cats are easy, Darpa should aspire to simulate a dog's brain.

[http://images.google.com/images?start=0&q=far+side+what+...](http://images.google.com/images?start=0&q=far+side+what+cats+hear&btnG=Search+images)

Edit: OK, cheap humor is not rewarded on HN. Here's one for the downvoters: <http://images.google.com/images?q=beyond+the+far+side></comment>


Google may be skewing how the public views nanotechnology - <AUTHOR> http://arstechnica.com/science/news/2010/05/is-google-skewing-how-the-public-views-nanotechnology.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss <comment><USER2> It's easy to lament the shift in coverage away from basic science and towards applied topics, but I think it may be a good thing. Nobody understands science or math, so the choice is to leave it out of the press, or else go the pop-sci route and basically make stuff up. At least with the applied articles you can accurately describe what we get, if not how.</comment>


Google Search NoAPI - <AUTHOR> http://blog.databigbang.com/google-search-no-api/

<comment><USER2> I was an early user of the SOAP search API - definitely disappointing when that was shut down.

For several years, I have been using the Bing search API for very low volume stuff - works really well.

</comment><comment><USER3> Google has told me (and other users of the now deprecated AJAX Search API) to switch to their paid Custom Search API.

The new API is missing some features that were in the old API, which is unfortunate. And, also unfortunate, the most accurate Google results (Local, Web, Image, etc.) come from scraping in ways like this article describes. Hopefully, Google will address these issues in its Custom Search API. If they don't many people will still continue to scrape.

<comment><AUTHOR> But the Google Custom Search API is a different thing. It's a search based on a set of sites. What's important is to have an API to search for the "whole" indexed Internet, and Google is the most advanced search engine in town. If you play with more complex queries you quickly note the difference between Google and Bing, Yahoo or Blekko.

<comment><USER3> Yes, which is what we thought too. But, you can setup a "custom search engine" with some default site (we used www.google.com), then change the settings to that it uses the entire web, and remove the site that you originally put in.

The Bing and Yahoo APIs are definitely a lot better, IMO. But, as long as Google wants me to use their Custom Search API, then that's what I'll use.

</comment></comment></comment><comment><USER4> _If you go to Google and look at the html source code you'll be astonished to see pure Javascript obfuscated code._

If you turn off javascript on your browser, I'm pretty sure you get straight html. That used to be the case anyway. Most scripts don't signal javascript- support.

</comment><comment><USER5> The CSE API replaces it and provides a JSON based API: <http://code.google.com/apis/customsearch/v1/overview.html>

</comment><comment><USER6> you can easily scrape google without having to use something as bulky as htmlunit.

When I teach people how to scrape, exercise #1 is scraping Google with Ruby Mechanize and Nokogiri. xPath is your friend</comment>


Android devs, what's your salary? - <AUTHOR>

Hi, I'm interested in an Android dev position and I want to know what will be a good offer.
Please mention your country and experience (years).
Cheers. <comment> brad-curran Australia. 80k. 2 years. I could go 120k, but it would involve losing the cultural and company benefits.

<comment><AUTHOR> Interesting. 40k is not a small difference. I'm intrigued by your decision. Would you mind elaborating a little?

</comment></comment><comment><USER2> Seattle, USA. Hired at 110k w/ two years freelance experience.

</comment><comment><USER3> 300k starting developing high-scale distributed financial systems using cloud technologies leveraging interactive rich-media applications written in enterprise Java heavily relying on database end-points and client to server communication without major outages or system hiccups

</comment><comment><USER4> I have seen 55 - 65k for ~1 year experience in NYC. 75 - 100k+ for 3 years experience in NYC.

<comment><USER5> "i have seen...."

ads, offers, or friends salaries?</comment></comment>


How Might We - <AUTHOR> http://blogs.hbr.org/cs/2012/09/the_secret_phrase_top_innovato.html

<comment><USER2> We've been using How Might We... to do ideation internally and with our partner organizations and have found them as a great way to spark creativity and a generate a lot of ideas. I would recommend checking out more of IDEO's resources around the design process as well. The Human Centered Design Toolkit (<http://www.ideo.com/work/human-centered-design-toolkit/>) and its corresponding community (<http://www.hcdconnect.org>) are great, especially if you have a focus on the developing world like we do. Alternatively there is the Bootcamp Bootleg ([http://dschool.stanford.edu/wp- content/uploads/2011/03/Bootc...](http://dschool.stanford.edu/wp- content/uploads/2011/03/BootcampBootleg2010v2SLIM.pdf)) which D-School publishes as a less prescriptive resource with a lot of similar content.

</comment><comment><USER3> This 'secret' advice is pretty old and it's very useful for prompting a perspective shift. The version I have in my quotes file (from 1998, surely not the first time anyone ever noticed the trick) is:

"Beware 'We should', extend a hand to 'How do I'... --Alan Cox, from [http://news.slashdot.org/story/98/10/13/1423253/featurecathe...](http://news.slashdot.org/story/98/10/13/1423253/featurecathedrals- bazaars-and-the-town-council) (The rest of the paper is pretty good too!)</comment>


Our Ghost Kitchen Future - <AUTHOR> https://www.newyorker.com/news/letter-from-silicon-valley/our-ghost-kitchen-future <comment><USER2> That bleak graphic at the top with all the out-of-business signs captures one of my biggest long-term worries about the pandemic. This passage, while not quite so bleak, sums it up:

 _There is something utopian about Reef's project, which inspires visions of greener, less congested, more accessible cities, in which delivery fleets zip around on electric bicycles and people congregate for cocktails in rooftop gardens, planted atop defunct parking structures. It is also a little sad. Decentralized, delivery-only restaurants—to say nothing of the WeWork- ification of restaurant kitchens—point to greater problems and complexities, like widening inequality, the high cost of living in coastal cities, the tenuous financial model of restaurants, and a culture in which, whether by preference or necessity, people prioritize convenience even in their leisure activities._</comment>


The De-Electrification of the U.S. Economy - <AUTHOR> https://www.bloomberg.com/view/articles/2017-04-12/the-de-electrification-of-the-u-s-economy <comment><USER3> LED and CFL lights, SEER ratings, LEED certifications, Energy Stars all are having an impact.

Just in computers there have been huge advances. My MacBook Pro requires about 1/6 the electricity of my 2007 Desktop, and my LCD monitor is about 1/6 a CRT.

Transition to EVs may start to soak up all the gains we're making in efficiency so the usage may start to tick back up. But we're building Solar and Wind sources at an increasing rate that will effectively start trading oil for renewable electricity.

These are all positive trends.

<comment><USER4> > My MacBook Pro requires about 1/6 the electricity of my 2007 Desktop

Apples to Oranges though (or Apples, but still). The comparison should be a laptop from 2007. I ran a house on solar electricity and windpower back then, my laptop was about 35 Watts according to the e-meter connected to it, my present day laptop is roughly the same.

Laptops have always been substantially more efficient than desktops.

<comment><USER5> > _Laptops have always been substantially more efficient than desktops._

Yes but a decade+ ago, they weren't a _replacement_ for a desktop, so you ended up having both. Now even mid end laptops (or "low end" Macs) are totally feasible as replacements.

I bought my last desktop in 2010 and I can't imagine buying another one.

<comment><USER6> > I bought my last desktop in 2010 and I can't imagine buying another one.

I still do 95% of my development on a desktop, I just can't see ever not doing that, I'm older now and a good desk, good chair, 3 big screens takes up enough space that a tower isn't taking up much more space.

That and I can put hardware into a PC for half the price of a Macbook Pro that will absolute annihilate the laptop on performance.

Portability and power efficiency does impose a constraint.

For me the trade off of having two machines is worth it rather than having one machine that is permanently hobbled by been designed for a use case I rarely use makes no sense.

<comment><USER7> > I'm older now and a good desk, good chair, 3 big screens takes up enough > space that a tower isn't taking up much more space.

I do the same, 95% of my development with a Macbook Pro with 2 big screens, keyboard and mouse attached. Don't even touch or move it on most days.

A desktop would be much cheaper - but I would still need a decent laptop for the 5% time when I'm not at my desk, so the savings aren't that much any more. And keeping development environments, VMs, config files, keyboard layouts, etc syncronized on two separate computers is too much extra work.

<comment><USER6> I have an oldish but fairly beefy Vostro that does in a pinch, keeping things synchronised isn't that hard in practice since the vagrant files and project files all live in git but yeah there is some overhead but I have that anyway since I have a desktop at the office and at home.

<comment><USER8> > keeping things synchronised isn't that hard in practice

I disagree, I think how difficult it is to keep things synced varies significantly between users. Sure, its easy if your work is consistent and you're disciplined but if you find yourself switching between very different projects frequently the overhead of syncing machines and setting up software repeatedly can become significant.

<comment><USER6> > frequently the overhead of syncing machines and setting up software > repeatedly can become significant.

It takes some discipline.

I run a small consultancy/agency, in any given week I'm switching between 3-5 projects (and odd bug fixes to others).

I've automated my entire workflow with vagrant and ansible.

I have

        /projects/<client>/<codename>/site (pr /app)
        /projects/<client>/<codename>/vagrant
        /projects/<client>/<codename>/<others>

Each client gets a "team" in bitbucket and orchestration becomes no harder than

git pull && vagrant up.

It works great on projects that have a simple structure (webserver/db) and projects that have complex configurations with ES/Redis as well.

The trick is to _always_ treat configuration as code and _never_ make manual changes to a VM (or more correctly, always make a manual change _then_ a change to configuration code).

As an entirely added side benefit I can pull a project from two years ago down and be up in a fraction of the time without polluting my host OS.

Even when that project is currently on 14.04 with particular weird dependencies (exactly _this_ version of wkhtmltopdf etc).

Longer term I'll probably look at docker or something but vagrant/ansible has worked out great (some projects aren't even using ansible, just a bash script).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> What's weird -- not to say ignorant -- about this article is that it ignores the base-load / peak-load issue that lies at the heart of actual utility economics.

Electricity is sold to households at a flat rate by the joule (metered by the kWh), typically with a fixed monthly fee tacked on.

But wholesale electricity price fluctuates based on demand. Everybody knows this: in the height of summer when everybody's A/C is cranking away, the utilities have to fire up their nasty diesel-powered generators. They beg their commercial customers to reduce demand. Long distance transmission lines warm up and sag a bit. If worst comes to worst, the utilities reduce the voltage on their sendout.

The utilities have to invest capital in well, capacity. If you know you never need more than 1 mW, and never less than 0.5 mW, you can build your distribution system for the peak, install four 0.25mW generators, and run two of them all the time and the other two when you need them. But if you might need 10mW on a hot day, and 0.5mW all the time, you have to spend a bundle on reserve capacity.

Load management is persuading energy users to avoid surges, and to shut off nonessential stuff when not needed.

But the typical electric grid isn't smart enough to handle this automatically. The load manager at the power company has to telephone Wal-Mart stores and ask them to turn off some lights and raise their thermostats. My electric vehicle charges at an appointed time of day, not when there's excess power capacity.

The smarter the grid gets, the better use of capital the power company can make.

Restoring power from blackouts is the worst. Electric motors draw a surge of power when they start. If a large city gets power restored all at once, the surge is huge.

</comment><comment><USER10> > the power consumption of our disk drives and screens is rising

Uh. SSDs use, what, 1/2 the power of a spinner? And LED screens use less than fluorescent, which use way less than cathode rays

The switch to virtual machines, now docker on servers saves a bunch of extraneous running computers too

<comment><USER11> I'm not sure VMs really changed that much. Before VMs, people just ran more services on the bare metal. You had your web server, database, email, etc. daemons all going. Hosting services separated things by accounts and filesystem permissions. VMs made a lot of things easier/more secure but the raw number of physical machines has still exploded. VMs are bottom line less efficient than bare metal due to virtualization overhead.

<comment><USER12> Maybe in the internet-focused UNIX sysadmin world.

Your average small to medium business in meatspace has a closet running:

\- Windows Domain Controller

\- Exchange Server

\- File server

\- Accounting server

\- Several line of business apps from different vendors, each with an onsite server component (often just a distribution of MS SQL Server).

\- Card access control server (if there are more than the ~4 doors that fit on one beige-box-on-the-wall controller).

\- Security camera DVR.

\- Cisco, Avaya, or similar PBX.

\- HVAC system controller (if you're a large, modern building or complex).

The DC, file, and Exchange servers, as well as desktop management and support, are probably handled by your primary IT contractor who sells you all your servers, network gear, and desktops. They'll tell you it's not good practice to colocate any of these services on the same Windows install, and resell you (with heavy markup) a different Dell/HP box for each one.

Each line of business app has its own vendor, which created and manages your site's installation of its package.

The door controls and security cameras are likely installed and managed by the same company that does your fire alarms. The two software packages likely state they should each have a Windows Server to themselves.

The HVAC system controller is likely installed and managed by a company that knows barely enough IT to be dangerous, and also doesn't want to colocate.

The PBX for your VoIP desk phones is likely installed and managed by the same company that ran the old DEC PBX for your analog desk phones in the 80s. They might have also done your ethernet wiring.

None of these guys trust all of the others enough to share an OS instance. According to the old-timers, you previously you needed a separate server in the closet for each one. Now your Microsoft Partner is also a VMWare Partner and gives each other vendor their own little slice of an ESXi box.

Oh, and there is probably no one on your payroll who understands this stuff or even has the passwords. Just the operations manager type who manages the relationship with each vendor and knows which one to call under what circumstances.

<comment><USER13> This sounds like an opportunity for someone to combine all of these into one appliance and charge less.

<comment><USER12> That's the opportunity VMWare capitalized on, and that Microsoft is trying to worm its way into with Hyper-V.

A conservative nontechnical business is unlikely to invest in an unproven desktop management system, office suite, email/messaging, security, and building automation system just to beat virtualization overhead. They're even freaked out by Red Hat.

If you're adventurous, you'll just use Macs/Chromebooks, the Google suite, and cloud-based "IoT" building automation (or you won't have a building automation problem because your office is small or nonexistent). You'll use Skype/Hangouts/Slack/Hipchat/cell phones instead of a PBX.

If you're less adventurous, there's something to be said for widely used components, backed by tech giants who are likely to stick around for a few decades, which multiple interchangeable sales/support firms in your area know how to work with.

</comment></comment></comment></comment></comment><comment><USER14> The decline in the industrial sector seems more likely correlated to the general decline of US manufacturing capacity.

The rest is less clear to me. More efficient lighting and HVAC seems more likely to move the needle than anything related to computers.

Nice breakdown of where the electricity goes from the EPA: [https://www.epa.gov/sites/production/files/styles/large/publ...](https://www.epa.gov/sites/production/files/styles/large/public/2015-08/electricity- consumption-by-sector-commercial-industrial-residential.png)

<comment><USER15> This is a common misconception - manufacturing output, beyond drops during major recessions, has steadily increased[1]. Recently, increases have slowed but outside recessions, "the general decline of US manufacturing capacity" is just not happening.

What is dropping are inputs for the same output - employment being the most obvious / painful, but power, raw materials, etc. are all being used more sparingly as manufacturers improve processes and adopt new technologies.

1\. [https://fred.stlouisfed.org/series/OUTMS](https://fred.stlouisfed.org/series/OUTMS)

<comment><USER16> Actually, it's not. Those manufacturing output numbers are both tricky and misleading. They are dominated by computer/electronic production and automotive. Because of how the statistics account for imports and technology advancement, the electronic components in particular are frequently overstated. For example, when Intel was shipping chips that were 2x more powerful than the last generation, that effectively doubled the measured output.

Simultaneously, the stats under account for services and non-market production. So things like Medicare/Medicaid ($1T annually) are measured at their cost, not based in the value delivered.

The reality is that industrial production in the US is 15-20% less than it was 20 years ago. Automation kills employment but most of the value creation has been exported to Asia. Denying that is denying reality.

Some articles: [http://www.economist.com/news/briefing/21697845-gross- domest...](http://www.economist.com/news/briefing/21697845-gross-domestic- product-gdp-increasingly-poor-measure-prosperity-it-not-even)

[http://www.realclearpolicy.com/blog/2015/05/27/the_hidden_de...](http://www.realclearpolicy.com/blog/2015/05/27/the_hidden_decline_of_manufacturing_output_1308.html)

[https://www.bloomberg.com/news/articles/2009-06-03/growth- wh...](https://www.bloomberg.com/news/articles/2009-06-03/growth-why-the- stats-are-misleading)

<comment><USER17> Can you please supply a direct quote from one of those articles to support this assertion?

> The reality is that industrial production in the US is 15-20% less than it > was 20 years ago.

I wonder how recently and carefully you have read these articles. For example, the Economist and Real Clear Policy pieces are directly contradictory on the subject of measuring value vs. price for electronics.

The Bloomberg piece is 8 years old. And even then, it says:

> After the adjustments, however, the new growth rate for manufacturing output > might be as small as 0.8% a year,

Growth of 0.8% a year, while anemic, is not a decline.

</comment></comment></comment></comment><comment><USER18> Of course, his last point is probably the most telling:

"Dig more coal...the Teslas are coming."

One of his major sources is eia.gov, and their 2015 report has electric power use at 38% of total use.

Transportation is another 28% of total energy use, so the sooner that can switch over the electric, the sooner we can drop the 36% of energy being sourced from petroleum.

<comment><USER19> Better than that! I prefer to look at the actual, most recent up to date data that EIA has collected. It goes all the way up to January 2017. In the 12 months rolling up through January, coal was just 30.5% of US electrical generation: [https://www.eia.gov/electricity/monthly/epm_table_grapher.cf...](https://www.eia.gov/electricity/monthly/epm_table_grapher.cfm?t=epmt_1_01) Below gas (33.5%). And below carbonfree energy at 35.4%.

That 35.4% carbonfree electricity can be broken down into: 19.8% nuclear (this part we really should fight to keep operating as long as possible, certainly until we shut down every fossil fuel plant... going from 80% renewables to 100% renewables may actually be harder than going from the current 15.5% to 80%).

7.6% wind, geothermal, small hydro, and maybe some biomass (unfortunately, EIA doesn't break these out separately)... though most of this is wind and geothermal

6.7% conventional hydro.

1.4% solar. (and this includes distributed solar)

AS recently as 2003, over 50% of our electricity was generated from coal. We're now at 30.5%.

As long as we keep nuclear operating, it should be fairly cheap to squeeze out the rest of that 30% of coal by installing high capacity factor wind turbines where it's windy (and perhaps anti-correlated with other sites), lots and LOTS of cheap utility-scale solar, mounted on single-axis trackers to increase capacity factor, and lots in Texas and the American South where it's not already common.

Adding 15% additional grid penetration of solar and wind both, along with probably some storage (lots of pumped hydro in Appalachia to replace coal, batteries everywhere else) to smooth out demand and UHVDC powerlines and East- West interconnects, we can squeeze out the rest of that 30% of coal without huge costs.

If we try to do this without that ~20% nuclear, we'll either need a lot more gas or a LOT more money.

<comment><USER20> Just FYI, you can get a more fuel and technology specific breakdown of generation and inputs from form 923, but it's timelagged and many plants don't show up in the monthly reports, so you have to wait for the annual.

</comment></comment></comment><comment><USER21> We are living in the age of efficiency.

As population growth slows it's only natural for electricity to as well.

We aren't limited by our raw computing power, we're limited by our inability to apply it.

<comment><USER5> I remember my college desktop and how happy I was when I got a 400W power supply! Now the Mac I travel with that has 100x the processing, storage, etc uses a 85W supply if it's plugged it. If you do that at scale with more efficient everything, it makes sense.

Remember when turning off the lights saved money? It was dubious then but with bulbs that use 1/10 the power, it's almost humorous.

<comment><USER22> Ya, that 8 watt LED bulb will cost you $8/year running 24/7 at 10cents/kwh. If it takes 2 seconds to turn it on and off each day, that's 24 minutes a year saved by leaving it on. If your time is worth >$20/hr, consider uninstalling the switch.

<comment><USER5> And in Austin, energy rates are 1/3 of that. If your light is on 1/3 of the time, we're down to < $1/year.

Without any time/value aspects, saving $1/year isn't on anyone's radar.. especially since the AC turning on is going to be much more.

<comment><USER23> > And in Austin, energy rates are 1/3 of that.

Are you saying electricity delivered to the home costs 3 cents/kWh in Austin? I flat out don't believe that. We're paying over 20 cents on Cape Cod. I can believe 10 cents in some areas. 3 cents, sorry; no.

<comment><USER5> As of December, the Austin Energy rates are 2.8c/kWh at the bottom tier, ranging up to 10.8c/kWh at the top.

Once you add all the extra fees and "one time charges" that happen every month, it's more but that's the base.

Ref: [http://austinenergy.com/wps/portal/ae/residential/rates/resi...](http://austinenergy.com/wps/portal/ae/residential/rates/residential- electric-rates-and-line- items/!ut/p/a1/jZCxTsMwEEC_pUNGx66j0sAWDAqhLZlIgxdk0mtiybEj-0okvp5ULIBa6G0nvac7PSppTaVV77pVqJ1V5rjLq1fGU_4gGC_yJU9Zlovb1aJ6ms_XbAJevgPlfXnHiqqssnIlWC6SC_0zk7H__McLDnC_EZuWykFhR7TdO1p7CHoHFrUyBAw06HVDvEIIRNkdMdoC0Qh9OPqZfUvSyfewBw8-PvgpTIc4hJuIRWwcx7h1rjUQN66P2CmlcwFp_ZOkWyr_-p4ni9_AibxfwPl- Q_9cf6xhm-J1obPZ7BPxDgh_/dl5/d5/L2dBISEvZ0FBIS9nQSEh/)

</comment></comment></comment></comment></comment></comment><comment><USER24> A few years ago I measured the power consumption of various devices around my home, using an inline meter of unknown accuracy (e.g., TV plugs into meter, meter plugs into wall outlet).

There weren't many surprises, but my cable TV boxes were disappointing: Two different models both used the same amount of power, 25-30 W, regardless of whether they were 'on' or 'off', and no matter how long they were 'off'. No other devices that drew any significant power behaved this way; in comparison, my laptop used 1W when asleep.

The cable boxes are merely computers, and not even general-purpose ones - i.e., only a small number of predictable features have to be implemented - <USER2> the vendor is complete control of the hardware and software. There is no reason an effective sleep mode couldn't be implemented. And think about the mass deployments of these devices by the cable companies - how much power could be saved by investing in some very standard, available tech, and add up the impact on customers' electric bills and the environment.

However, I wonder if other models of cable boxes are the same.

<comment><USER9> Yeah, I measured the same thing on the cable box, an object which gets about 40 minutes use a day in my household.

So when my local utility (UK-owned National Grid) did a promo for power strips that shut off all the plugs when one plug stops drawing power, I bought one. Works great. Takes about two minutes for the cable box to boot up when I need it.

National Grid lost a 35w base load (24x7 load) by selling me that strip. 35w costs me about $45 a year, and the power strip cost me $15.

<comment><USER24> If my cable box loses power then it loses all its channel guide data, and it takes maybe 15 minutes to reload.

It really seems unbelievable. Why isn't the data stored on the local disk? How much data could that be and why does it take more than 10 seconds to download? On my box, it is all text.

<comment><USER9> Agreed. The monopoly regulators who tell the cable companies what to do should give them a limit on the electric load their customer-premises equipment (cable boxes) may draw when idle.

It should be no more than dozens of milliwatts. When the load exceeds that, the cost of that electricity to their customers should be refunded via a credit line item in each bill. That will give the cable operators a way to transition to better equipment, and an incentive to get the transition completed.

Accountability: there's no other way.

</comment></comment></comment></comment><comment><USER25> The article doesn't make it clear if this is commercial production of power, or if it include private owned solar etc. I could see centralized commercial energy production dropping due to home solar alone, but TFA isn't clear.

Either way, I'd bet that the electrification of our cars and trucks over the next few decades will absorb most of the excess capacity and drive the need for more production.

<comment><USER26> The article addresses private solar, though admits to incomplete data and some uncertainty:

"The Energy Information Administration actually started estimating power generation from small-scale solar installations at the end of 2015... and found that it accounted for only about 1 percent of U.S. electricity. That estimate could be off, and there's surely room for more study, but mismeasurement of solar generation doesn't seem to be the main explanation here."

</comment></comment><comment><USER27> Seems like it's mostly about traditional manufacturing, or the lack thereof. Energy price spikes (2008) kill off energy-intensive businesses. But even when prices come back down these businesses don't start back up in the US, because a competitor in China has already expanded to fill the gap, and they do it cheaper.

</comment><comment><USER28> There's a much simpler, technical explanation: the transition from linear power supplies to switch mode power supplies, in devices of all sorts including but not limited to computers. The timing of the peak and beginning decline in per capita power demand coincides with the point at which SMPS's became a practical option for new designs beginning at the end of the 1970's. The decline since then may just be the result of gradual replacement of linear supplies by attrition.

</comment><comment><USER29> Efficiency of CPU's and tech do not drive electricity demand. If anything, we use more power for tech now than ever before. This is the direct result of cheaper natural gas being on the market, which removes demand for electric heating/heat pumps, electric appliances, etc. There is also a shift in industrial use. Just this year Washington lost a large aluminum arc furnace smelter, for instance.

</comment><comment><USER30> _" Consider the shift to cloud computing. From 2000 to 2005, electricity use by data centers in the U.S. increased 90 percent. From 2005 to 2010, the gain was 24 percent. As of 2014, data centers accounted for 1.8 percent of U.S. electricity use, according to a 2016 Lawrence Berkeley study, but their electricity demand growth had slowed to a crawl (4 percent from 2010 to 2014). What happened? The nation outsourced its computing needs to cloud providers, for whom cutting the massive electricity costs of their data centers became a competitive imperative. So they innovated, with more-efficient cooling systems and new ways of scaling back electricity use when servers are less busy."_

I am torn because centralization leads to more R&D and cost savings and better security. I just wish the innovations would propagate to everyone. Decentralization is much better for everything except those things that come with economies of scale.

<comment><USER31> The R&D being done here doesn't only apply if you run extremely large data centers. Facebook, Google are contributing back to the Open Compute project [1] , and anyone could use this knowledge if they want to build a small data center with things like the Open Rack[2].

[1] [http://www.opencompute.org/](http://www.opencompute.org/) [2] [https://code.facebook.com/posts/1687861518126048/facebook- to...](https://code.facebook.com/posts/1687861518126048/facebook-to-open- source-ai-hardware-design/)

<comment><USER30> But it seems to me that when it comes to security, efficiency etc. only large centers can get it right, because they have more at stake. The majority of small providers will mess up. Like compare AWS uptime and security to a regular host.

And sadly this explains the rise of centralized everything including gmail and facebook and iOS app store and - for thousands of years - centralized cities and states and federations.

</comment></comment></comment><comment><USER32> Alternate title: the Un-Reality of the GDP

Rather than this being a measure of energy efficiency or reduction - could it not be a measure of GDP artificial inflation?

Though that would be a bit of a sensational title, the trend also suggests a decoupling of GDP from physical processes (mfg, service jobs) directly requiring power for their use..

<comment><USER33> > decoupling of GDP from physical processes

Well, yes: much of the growth is in services. E.g. education or health can get a lot more expensive without necessarily consuming more electricity.

</comment></comment><comment><USER34> Short version:

Electricity generation (and use?) is below its 2007 levels. Is this a trend? Let's skip to the last paragraph (as one always should when beginning to read these clickbait articles):

"So is electricity use in the developed world fated to decline for years to come? Well, not exactly fated. Check out that bottom line in the last chart. Transportation now accounts for just 0.3 percent of retail electricity use in the U.S. If the shift to electric vehicles ever picks up real momentum, that's going to start growing, and fast. Dig more coal (or drill for more natural gas, or build more nuclear reactors, or put up more windmills and solar panels) -- the Teslas are coming."

So, no.

Get this trash out of my Hacker News.

<comment><USER35> If you just skipped to the end of the article, you missed the fact that the last sentence is a slightly tongue-in-cheek reference to this article from 1999:

[https://www.forbes.com/forbes/1999/0531/6311070a.html](https://www.forbes.com/forbes/1999/0531/6311070a.html)

</comment></comment><comment><USER36> Interestingly he's stating that the transition to electric vehicles (EVs) will make up for the flat energy usage / non-existent growth. However, his own argument should negate a substantial amount of that: if large players such as tesla/GM/lyft/uber/whoever own the majority of future transportation, they will also have a strong incentive to be energy efficient.

Never thought of it that way, but large players don't just make efficient use of hardware, but of the resources (energy etc) they consume too. That means the traditional energy industry is in for a beating...

<comment><USER37> Or a strong incentive to vertically integrate electricity production. I believe Google have done this in some form to secure and reduce cost of datacenter energy.

</comment></comment><comment><USER38> Excellent breakdown of energy consumption by sector since 1950: [https://www.eia.gov/totalenergy/data/monthly/pdf/sec2.pdf](https://www.eia.gov/totalenergy/data/monthly/pdf/sec2.pdf)

The source is the same as the original article (U.S. Energy Information Administration), it just shows a much broader (and deeper) picture. As a result, you may draw different conclusions.

</comment><comment><USER39> Should we consume more? I would actually like to see electricity prices to go down, but it seems like research in that area nearly stopped.

</comment><comment><USER40> I don't think it's related to this plateau, but it sparked the question:

If the global temperature were to increase by 1° would that cause a net gain or loss in electricity use?

If you oversimplify you'd assume that since heating is more expensive than cooling consumption would decrease, but I imagine it might also depend on where the majority of humans are located in terms of climate?

<comment><USER41> A gain, I would guess, because pretty much all cooling is run on electricity, whereas some of the heating is done by gas.

<comment><USER42> Some of the electricity is also done by gas.

</comment></comment></comment><comment><USER43> The first thing I notice about this article is that it talks about _generation_ , not consumption. Where is the data on US energy consumption? It's especially odd given that he compares US generation growth to China's consumption growth toward the end of the article.

<comment><USER44> Aren't generation and consumption very close to equal?

</comment></comment><comment><USER45> That's great! Just wait for EVs though, you'll suddenly get all that electricity use back, and a lot more. But, overall energy use per GDP will fall through the floor due to their much higher energy efficiency vs gas powered cars.

<comment><USER46> "That's great!" It is likely a sing of a sinking standard of living. Had to come sooner or later, so I would not call it "bad".

"But, overall energy use per GDP will fall through the floor due to their much higher energy efficiency vs gas powered cars." Highly improbable.

Wealth And Energy Consumption Are Inseparable [http://www.declineoftheempire.com/2012/01/wealth-and- energy-...](http://www.declineoftheempire.com/2012/01/wealth-and-energy- consumption-are-inseparable.html)

<comment><USER45> It looks like you discard the whole notion of 'energy efficiency' at all?

<comment><USER46> Hm. No. Just the outcome:

"1993 and 2005, air conditioners in the U.S. increased in efficiency by 28%, but by 2005, homes with air conditioning increased their consumption of energy for their air conditioners by 37%."

Jevons sends you his greetings I guess.

</comment></comment></comment></comment><comment><USER47> Closing all the factories in the Midwest would have a lot more impact than efficient light bulbs.</comment>


A Fresh Look at Rust - <AUTHOR> http://lucumr.pocoo.org/2014/10/1/a-fresh-look-at-rust/ <comment><USER2> I've been using Rust to process a large text corpus, and as Armin suggests, it's a really interesting experience. Here are a few things I've noticed so far:

1\. Writing Rust code definitely takes more time than Python or Ruby, but it's not bad in practice. I can't measure the productivity difference yet, partly because I'm still learning Rust. I do spend more time thinking about how to write zero-allocation and zero-copy algorithms, and trying to get my code to compile (but see 3, below).

2\. It's possible to write very fast code without compromising memory safety. It's great to see key parsing operations happening in ~100 nanoseconds, with no allocations.

3\. Rust is one of those languages where I need to work to make the compiler happy, but once I manage that, the code generally works on the first try.

4\. The tooling is very good: library management, unit testing, benchmarking, documentation, error messages etc., all work very nicely.

Overall, it lacks the instant gratification of a really good scripting language. But I keep finding myself back in Emacs, writing more Rust code for the fun of it. And I really enjoy the combination of low-level code, memory safety, and a useful selection of functional programming features. I'm glad to see a new language in this niche.

<comment><USER3> This is great feedback, thanks. And if there's anything that you _don 't_ like about Rust, please let us know now while we still have a chance to possibly fix it! Only a few short months left until all of our mistakes are forever entombed in Rust 1.0. :)

<comment><USER4> Hi! I use F# for most tasks (from websites/JS generation, to packet capture and indexing, call routing and billing processing), and some C where required. Rust looks fantastic, and would give me the memory control I need when I need extra performance. A LOT of it comes down to simply being able to stack- allocate things; in F# I'm essentially forced to use the GC heap for even the most trivial things.

Rust looks fantastic, and I'm very excited about using it. When I found out about it and started reading how it worked, it was almost exactly what I had been wanting, on almost every count. I really wish it had existed a few years ago.

My comments are from someone that's just been playing around with the getting started guide of Rust.

\-- Lack of custom operators limits expressiveness. For instance, look at Parsec or FParsec. Why shouldn't they be allowed to exist in Rust? But if custom operators _are_ totally out of the question, then what about user- defined infix functions? (And then, why not functions with nearly arbitrary codepoints as identifiers?)

\-- It seems that currying, partial application, and function composition are sorta cumbersome in Rust. Is this a conscious decision, that idiomatic Rust shouldn't be doing such things? Like " add >> inc >> print " being equivalent to "|a,b| -> print(inc(add(a,b)))" ? In F# I use this kind of stuff all the time, especially when processing lists.

\-- It seems there's a difference between function types. Like if I do "fn foo(a:int, f:proc(int)->int)", I can call it with foo(1i, inc) if inc is a fn. But if I first do "let f = inc; foo(i1, f)", that's an error. Offhand, I'd assume this is due to lifetime management, but it feels a bit strange. When writing HoFs, do I need to implement a version for each kind of function? Or am I totally misunderstanding things?

\-- Sorta related, does Rust allow something like:

      let inc =
        let x = ~0
        || { let res = *x; *x += 1; res }

The idea is to expose a function that contains some private state. I remember hearing that Rust changed the ownership stuff around a few times, but the basic idea is to create a globally-accessible closure. Is this impossible, requiring us to use statics to store the global state?

\-- Why doesn't Rust warn when discarding the result of a function if not unit? Is it idiomatic Rust to return values that are often ignored?

\-- Even without higher kinded types, monadic syntax is useful. Is Rust planning any sort of syntax that'd let users implement Option or Async? How does Rust avoid callback hell? Or is this quite possible today with macros and syntax extensions?

\-- Has Rust considered Active Patterns (ala F#)? With that, I can define arbitrary patterns and use them with matching syntax. E.g. define a Regex pattern, then "match s { Regex("\d") => ... , Regex("\D") => ... , _ => ... }"

\-- Consider allowing trailing commas in declarations; why special-case the last item?

\-- And last but not least: Please, please, _please_ , reconsider type inference. It's baffling why "fn" requires type annotations, but a closure does not. What's more, why is there even different function syntax in the first place? I've heard the reason that "top level items should have types documented", but that's a very personal decision to make. It certainly isn't something the Rust compiler should force me to do in all my code. Why do ya gotta limit _my_ expressiveness? (Same argument I'd use for custom operators.) Statics/consts should also have type inference. And note that these items aren't necessarily public or exposed - but a private fn on a module still requires type annotations.

<comment><USER3>
      > Lack of custom operators limits expressiveness.

I understand that this is going to be hard for some to swallow, but it is explicitly a non-goal of Rust to be maximally expressive. :) New features are motivated almost solely by solutions to concrete pain points in Rust code (especially Servo). This may sound particularly Blubby, but the devs are well- versed in Haskell (and Lisp, and Scala, and ML, and...). With respect to custom operators and infix operators, they're taking the cautious approach of leaving the option open for future versions of Rust, since they can be added completely backwards-compatibly if there's significant demand for them post-1.0.

      > It seems that currying, partial application, and
      > function composition are sorta cumbersome in Rust.

There are two different camps in competition here. One camp wants Rust to have default function arguments as per C++. Another camp wants Rust to have automatic currying. These camps are in opposition because they both want to control what `foo(bar)` does for a function `foo` that takes more than one argument. So far the devs have resisted entreaties from both camps. Experience post-1.0 may change this.

      > It seems there's a difference between function
      > types.

Closures are really terrible right now and are in the midst of getting a complete overhaul to be more useful and less hacky. :) Procs won't even be a thing afterward. Please excuse our mess!

      > Why doesn't Rust warn when discarding the result of
      > a function if not unit?

It does warn, for any type that has the `#[must_use]` attribute. This includes the stdlib's `Result` type, which is basically Haskell's `Either` except explicitly intended to be used for error handling.

      > Is Rust planning any sort of syntax that'd let
      > users implement Option or Async?

I'm not sure what this means, as users can already implement Option. It's not special-cased by the language in any way.

(As for the lack of HKT, that's a hotly-desired feature for post-1.0. It's still a bit pie-in-the-sky, but the devs have acknowledged that it would be very useful to improve our error handling story.)

      > Please, please, please, reconsider type inference.

Not going to happen. :) Requiring type signatures on top-level functions is so useful that even the languages that allow it to be inferred tend to enforce their presence via social pressure. In addition to providing powerful self- documentation, this vastly improves error messages. Finally, I suspect that Rust's trailing-semicolon rule (especially combined with the willingness to ignore the return value of most functions) would interact poorly with function signature inference.

      > Statics/consts should also have type inference.

IIRC this isn't possible, but I've forgotten the reason for now. It certainly isn't motivated by any sort of philosophy.

<comment><USER4> While I strongly disagree with limiting expressiveness, operators, etc., and the thing about top-level functions is misleading (because a nested, private, module isn't really "top level), this is a fantastic response and helps me understand Rust a lot better. Thank you very much.

I hope things will change (esp. type inference, which while playing around is really annoying, even if I eventually end up wanting to annotate. A REPL could fix a lot of the pain.). But there's nothing out there that competes with Rust, and the C-friendliness means I can fairly easily interop with languages with more expressiveness ;).

As far as async/option, I meant something like Haskell's do notation or F#'s workflows. This allows implementation of async code without callback hell or the huge limitations of promises or whatnot. (But without HKTs, you can't mix multiple monad types within one block.)

<comment><USER3> While this is far from a promise, any future implementation of HKT would likely be accompanied by a do-style notation. The `do` keyword is unused yet reserved for precisely this reason ([https://github.com/rust- lang/rust/blob/master/src/libsyntax/...](https://github.com/rust- lang/rust/blob/master/src/libsyntax/parse/token.rs#L519)).

</comment></comment></comment></comment></comment></comment><comment><USER3> I adore that someone like Armin is so delighted to use Rust. From what I've seen of Flask and his other Python libraries, the level of consideration that he devotes to API design is absolutely inspiring.

At such an early stage in the language's history, I'm optimistic that his thoughtfulness in API design will become the baseline for the entire Rust ecosystem. In this vein, I'd also like to credit Chris Morgan's Teepee ([http://chrismorgan.info/blog/introducing- teepee.html](http://chrismorgan.info/blog/introducing-teepee.html)) and Sven Nilsen's Piston ([https://github.com/PistonDevelopers](https://github.com/PistonDevelopers)) for devoting a great deal of energy to figuring out how best to structure Rust APIs that play to the strengths of the language. It's a process of discovery for all of us!

<comment><USER5> Don't forget Aaron Turon (employed by Mozilla to work on the design of the std library), who, among other things, wrote the "fluent" APIs for process[1] and task[2] spawning, which possibly inspired the redis-rs API Armin describes in this post.

[1]: [http://doc.rust- lang.org/nightly/std/io/process/struct.Comma...](http://doc.rust- lang.org/nightly/std/io/process/struct.Command.html)

[2]: [http://doc.rust- lang.org/nightly/std/task/struct.TaskBuilder...](http://doc.rust- lang.org/nightly/std/task/struct.TaskBuilder.html)

<comment><USER6> I'm so glad that Aaron is on the core team, focusing _specifically_ on API design and ergonomics, rather than just the language. He has definitely been applying much needed polish that we need for a slick 1.0 release.

<comment><USER7> Just wanted to also add that in an area of design with lots of strongly held subjective opinion and rampant bikeshedding, Aaron has shown himself to be incredibly thoughtful, well-measured, and diplomatic. Really a great addition to the team!

</comment></comment></comment></comment><comment><USER8> > The truth is that the borrow checker is not perfect. The borrow checker > prevents you from doing dangerous things and it does that. However it often > feels too restrictive. In my experience though the borrow checker actually > is wrong much less often than you think it is and just requires you to think > a bit differently.

I would love to see this explored in more detail. The borrow checker is, from what I can tell, one of the most important and novel parts of Rust. I'd love to see more detailed examples of where:

1\. it kept you from doing something idiomatic that you _knew_ was safe but you just couldn't convince the borrow checker of it.

2\. it kept you from doing something that _seemed_ safe, but then you realized that it was actually telling you something important.

Also:

> Even if it would turn out that the borrow checker is not sound

Wait, is this an actual risk? Is there some lingering doubt that the borrow checker is actually sound?

<comment><USER3>
      > it kept you from doing something that seemed safe, but
      > then you realized that it was actually telling you
      > something important.

One of the reasons that I know Rust is on to something is how often I've seen this scenario occur on IRC. It's great to watch someone come in with a complaint about appeasing the borrow checker, only to later realize that what they were attempting to do was actually subtly unsafe.

For the former point about things that the borrow checker doesn't have enough information to allow, see [http://www.reddit.com/r/rust/comments/279yw3/borrowing_from_...](http://www.reddit.com/r/rust/comments/279yw3/borrowing_from_an_array_need_help/) for an example.

<comment><USER9> It's also really a pain now to get the borrow checker to be happy with boxed structures now that box isn't implemented in the compiler. You need to first borrow the whole structure, and then things within it.

</comment></comment></comment><comment><USER10> _I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry._

I really don't understand why STL gets so little love. It's a little lean on features maybe but in my experience it just works, and it's _fast_. Once you get your head around the iterator concept it's pretty simple to use. And with lambdas in C++ I can write code that's almost as concise as Ruby or Scala.

Any strongly-typed, flexible collection & algorithm library is going to be complex and require a learning curve.

<comment><USER11> In my experience the people who have strongly negative opinions specifically about the STL have it rooted in one of these two things:

\- They haven't used it much in a very long time and have very bad memories of tracing through the completely opaque SGI STL implementation and its derivatives.

\- They include std::string and/or std::iostreams as part of the STL, neither of which are part of the original STL and have all sorts of weird warts and poor interactions with the generic algorithm-focused core parts.

Not to say there aren't other reasons people dislike it, but these are big ones.

<comment><USER10> Probably true. I wasn't much of a fan either when I first used it in 1996. It was extremely verbose, slow to compile, and tended to generate compilation error messages that filled the screen.

But the experience of using the STL today with the niceties of C++11 and a good compiler like Clang is _vastly_ better. I can now write code almost as concise as Ruby that runs 100x faster, without usually having to worry about memory management. I avoid using the streams stuff though. That chunk of the library could use a serious overhaul.

I'm rooting for Rust because it's designed to address the problem spaces I care about most but C++ has improved by leaps and bounds in the last few years.

<comment><USER6> Yeah, Clang has really improved the ecosystem as a whole, as has this decade's updates to the language and libraries. But unfortunately they are all band- aids over some very deep foundational problems that were decided decades ago (I don't blame Bjarne by the way - he didn't have the benefit of hindsight).

I am glad we have a new language that takes the best from C++ and sets in on reasonably solid theoretical foundation inspired by languages like ML and Haskell. It's not watertight yet (unlike the formally verified ML), but it is damn better than the current status quo.

<comment><USER12> Are you coding currently in C++11/14 ? It doesn't feel "bandaid-y" at all.

</comment></comment></comment></comment></comment><comment><USER13> I rarely have to do anything as low-level as rust would demand. More often than not I find myself using Python, but I had the same feelings when I started looking into rust a few weeks ago. It was exciting seeing the full pattern-matching, especially.

I have a desire to get some experience in the area, but the problem is what to make. Does anyone have any ideas for some smallish libraries that would benefit the community? I'm certainly not a networking or concurrency expert, so it's difficult to come up with ideas.

<comment><USER6> What kind of areas are you interested/experienced in? What would you like to learn? I'm sure there are tons of gaps out there that you could help fill. Maybe the folks on irc.mozilla.org #rust might be able to give you some ideas.

<comment><USER13> Thanks. I'll definitely try out irc for some ideas. My general projects are small automation tasks for myself as well as small web-based apps for myself and friends. That's part of why coming up with ideas for something like rust are a little tricky.

The only promising thought I've had is maybe implementing some sort of template preprocessor that I can find a way to work into an existing rust framework.

</comment></comment></comment><comment><USER14> Started using rust just this week.

Used more hours than ever expected on it. Simple put you'll fall in love with the compiler, because it point out so well your mistakes.

Another thing to note is that it greatly encourage you to fix your warnings too. which for me coming from java and php world isn't something you'd give much thought.

<comment><USER3> I agree about the warnings. Normal Rust code is already so strict that a lot of the warnings that you'd get from other languages are already compiler errors, which means that issues that are merely good style (e.g. declaring a variable as mutable when you never actually mutate it) can spit out warnings without overwhelming coders and causing them to lapse into "I've already got 200 pages of warnings so screw this" apathy. It's a fine line though, and something we have to remain mindful of as we add more warnings by default.

</comment></comment><comment><USER15> Rust actually makes me think a lot about Ada, if you want to program, you need to program correctly.

Probably the reason I will not use Rust is the same reason I only look at Ada in a professional context, I usually start projects with something quick and dirty, then gradually refactor it into something better, rather than piece by piece. Being forced to do it right the first time would likely just push me more into doing less programming.

</comment><comment><USER16> In addition to being a great lang, I love all the little things. Like he mentions, the doc tools and compiler are very nice.

<comment><USER6> > the [...] compiler [is] very nice.

No doubt clang has been a good influence in setting the standard for gorgeous, readable error messages with nice colored squigglies and arrows. Borrow check errors probably the hairiest you get, and you get less and less of those as you internalise the rules.

</comment></comment><comment><USER17> I've been very interested in Rust for a while, but put off by the early development status and the fact that it's undergone a few major redesigns. I don't hold them against the language team in any sense, and actually think more of them for it, since redesigns early are good if you realize something else might be better or one of your original ideas just didn't work out.

Rather, I'm just curious when I can expect Rust to settle down and not have frequent breaking changes, major redesigns of language features, etc. I've heard it's the aim of the 1.0 release to have this property (which is a reasonable goal in my mind).

Does anyone have a timeline on when it would be reasonable to start eyeing Rust if I want more stability (in terms of language features) than it's had during its development phase?

<comment><USER18> You want to wait for 1.0. The plan is a release candidate around the end of the year.

</comment></comment><comment><USER19> I found the python version of the code so much more readable... is putting "unwrap" and "ignore" everywhere becoming idiomatic in Rust ?

<comment><USER20> Python made the choice to sacrifice performance for much better readability, and it shows. You can see the difference between code elegance when working with strings in either languages, for example. The downside is that Python's benchmark numbers are poor. Rust can get to within 1x C's performance; Python would be lucky to get within 100x.

But I do share your concern about `unwrap`. Is it idiomatic to do `unwrap`s, or is it better to define functions to accept and return Option<xxx>?

<comment><USER21> Unwrap only appears in simplistic examples. The correct "unwrap" is the `try!` macro.

<comment><USER22> Once you reach the main function, you have to deal with the errors, since you can't propagate them any further.

<comment><USER21> Your main function is most likely pretty empty and that's the only place where you need to deal with hard failure. And that's the same in _all_ languages. If you write in Python you don't just not handle exceptions either. Somewhere you catch them down and present them to the user in a good way.

</comment></comment></comment></comment></comment><comment><USER23> This is a good write-up.

I still think some kind of vanilla ML would suit a lot of people very well.

<comment><USER6> What do you mean by 'vanilla ML'? I wasn't sure there were any really around... Ocaml has tons of stuff added, and SML also has lots of added extensions.

<comment><USER23> OCaml would be fine. It's a good language with a very efficient run-time.

I'm arguing that you could throw out most of the advanced features and that would be enough for most people. Its best features are the core ones. That's why I don't really care which specific flavor of ML you pick. Any would be a big win over many languages in wide use today.

</comment></comment></comment><comment><USER24> let the hype cycle begin

</comment><comment><USER25> Annnd if you'd like to be able to write code as fast as Rust but get it done faster than Python or Ruby, take a look at Haskell.

\- ex-Python and Clojure user, teach Haskell now.

[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

<comment><USER26> Rust is meant to be practical, Haskell is more for academia (horrible ML syntax etc.).

<comment><USER27> Arguably that is either wrong or depends on taste.

Haskell has very little syntax in comparison to something like C or Python and what little is has is very obvious.

I'd much prefer ML/Haskell-ish syntax in Rust, but I know I'm in a minority.

<comment><USER28> I agree with you, but Rust is mostly targeted at C++ developers so it makes sense that they'd use C++isms where they it wasn't crazy. Examples of crazy being resource declaration mirroring use.

</comment></comment></comment></comment><comment><USER29> Easy cross-compilation, motherfucker! Do you have it?

<comment><USER3> Yes, by passing a target to the compiler via the "\--target" flag.

</comment></comment><comment><USER30> Disappointing how this author's hyper-criticism of Python is not applied equally to Rust, presumably because Rust is newer and this author has other bones to pick with Python. If Rust has a problem, he will sell that it is charming (e.g. "it makes you think", "you just need to think differently", "needs more love"). The glass will be full any day now! But if any new effort in Python is not absolutely perfect or just not to his personal taste, he will sell that it's because Python is a horrible pile of shit because nobody listens to him. The glass isn't only half empty, it is also too hard, too brittle, too cold and actually also too warm and it turns out that not even its transparency is a good feature.

After several years of this routine, it has become very old. For God's sake, if your ex is so bad then just move out of her house already. Don't just keep eating the dinners she prepares and complaining about them and saying you'll move out. Actually move out and stop talking about her all the time. Yet another article about how you can't stand how she clips her nails is not helping anyone.

<comment><USER31> The criticisms of Python covers about one sentence, and they're all to the point. I don't see how you can turn a well-written post 99% about Rust into "hyper-criticism of Python".

> he will sell that it's because Python is a horrible pile of shit because > nobody listens to him

I'm not sure we're talking about the same Armin here...</comment></comment>


Linux Lab v0.2 rc1 released - <AUTHOR> Linux Lab (https://github.com/tinyclub/linux-lab) is an instant environment for Linux kernel learning, development, debugging and testing.
It is based on docker, qemu, novnc, gateone ...
Now, 7+ processor series, 14+ boards supported, with prepared cross compilers, default configs, prebuilt kernel and rootfs images, demo qemu boot scripts.
Simple make targets added to do kernel downloading, patching, configuration, compiling, booting, debugging and testings. The same logic to related packages: u-boot, buildroot and qemu.
Showterm videos:
* Booting Risc-V 32/64
  http://showterm.io/37ce75e5f067be2cc017f
* Testing a specified kernel feature
  http://showterm.io/7edd2e51e291eeca59018
* Testing multiple kernel modules
  http://showterm.io/26b78172aa926a316668d
* Batch testing all supported boards
  http://showterm.io/8cd2babf19e0e4f90897e
* Learning Assembly of all processor series
  http://showterm.io/0f0c2a6e754702a429269
Just try with three commands (In Ubuntu system, in others, please install docker at first):

    $ git clone https://github.com/tinyclub/cloud-lab
    $ cd cloud-lab
    $ tools/docker/run linux-lab
 If no error encounter, It will launch a browser, than, login, open the terminal on desktop and type:

    $ make boot
 The default vexpress-a9 board will boot, login in as root with empty password.
Boot with nfsroot:

    $ make boot ROOTDEV=/dev/nfs
 Boot without Uboot:

    $ make boot U=0
 List all boards:

    $ make list
 For more help, please read README.md:
https://github.com/tinyclub/linux-lab/blob/master/README.md <comment><USER2> So wonderful job! My favourite feature is providing a whole development environment with docker, it can save me a lot of time, and make me focus the source code.</comment>


SQL for NoSQL: Couchbase N1QL Tutorial - <AUTHOR> http://query.pub.couchbase.com/tutorial/#1 <comment><USER2> This is an interactive step by step introduction to our new SQL style query language.</comment>


How to Track NBA Player Movements in Python - <AUTHOR> http://savvastjortjoglou.com/nba-play-by-play-movements.html

<comment><USER2> This is pretty great. I did not realize the NBA kept this type of data on games. I wonder if the MLB, NFL or NHL do the same thing. Very cool regardless.</comment>


Nodejs native windows port (node.exe) released - <AUTHOR> http://nodejs.org/#download

<comment><USER2> can't get seem to get npm/cygwin to work with this release, anybody else have luck with this?</comment>


How to build a startup on ThinkVitamin - <AUTHOR> http://membership.thinkvitamin.com/library/business/

<comment><AUTHOR> "We're celebrating our 1-year birthday on Think Vitamin Membership (now up to 410 videos!) so we thought we'd try to do something nice for you all by giving you some free content :) For the next 48 hours, you can view my Web Business course for free."</comment>