Ask HN: What makes a good hackathon? - <AUTHOR> We're in the early stages of planning a hackathon with Heavybit (http://www.heavybit.com/) but haven't had much experience running an event like this.<p>What do you think makes a successful and enjoyable hackathon? Is it the prizes? Is it the theme? Would you prefer it on a weekend or a weekday? Anything else, big or little, that makes for a good hackathon? <comment><USER4> I've noticed two things that have ruined hackathons for me:

\- People that say they have skill in XYZ, when in fact they have little to no experience in XYZ. It would be nice if I could have some reasonable confidence in a stranger's ability to be experienced in a skill they claim to have.

\- "Entrepreneurs" interested in getting free dev labor for their unicorn app idea. I sign up for a hackathon to have some fun and write some code with hopefully cool people, usually for some cool or good cause. I don't come there to make a beta for some greedy MBA student.

<comment><USER5> Along the same lines, participants who spend all their time running around and "networking". Socializing and meeting people is obviously one of the draws of these events, but a few bad apples do tend to ruin the atmosphere for everyone.

</comment></comment><comment><USER6> What makes a good hackathon? As a frequent attendee, these patterns have stuck out as successful to me:

1\. Set over the course of a weekend. Allows greater breadth of attendees. Not 24 hours (which is somewhat manic) but rather a more leisurely schedule of Friday: beers/pitching/team-forming; Saturday: hacking; Sunday: polish, pitching-practice, pitches, award ceremony.

2\. Strong focus/process/timetable. Ensure everyone knows the schedule and judging criteria they're hacking towards. Set out the support infrastructure and resources at the top of the weekend so people can get up to speed in the methodology of the weekend. Startup Weekend tells attendees to create a plausible startup, then links them to Lean Startup resources and hands out lots of post-its for their business-model canvases. Major League Hacking tell people to make something "cool", then feed them boxes of Red Bull and loaner- hardware. Horses for courses.

3\. Experienced organisers and mentors. Have at least one person for whom this isn't their first time running a hackathon, and knows how to sort out and prepare for all the little things that can (and will) go wrong. Mentors are invaluable for setting the tone of the hackathon and guiding everyone through the event and criteria (see point 2).

4\. Pizzas/generic junk food are fine (and expected!) once in a weekend. ONCE. Similarly, lots of caffeine and beer (at the beginning and end) is great for getting a buzz on, but put out plenty of water and maybe some juice/herbal teas as well. There'll be plenty of natural highs by wrap-up time, and reasonable adults won't attend if they think they're gonna feel terrible the day after (see point 1).

Other thoughts:

\- Thematic hackathons provide an opportunity for hackers to learn about a new domain, and for domain specialists and otherwise interested-persons to get involved where they might not at an event specifically organised for them, but OTOH it can dissuade some hackers from attending who don't think they'd be interested. In order to resist any gimmickiness, there should already be a dialogue or narrative - either an existing community which has already expressed interest in the domain (e.g. an open data community regarding city- infrastructure), or more general hype and interest (think Startup Weekends).

And remember, it's people in a room to have fun together in a slightly unconventional way. Make sure that you build up the community and teamwork of it all the way through, look after everyone, go have beers after, and start planning the next one if people are asking for it!

<comment><USER7> Thanks for sharing, this is both informative and reassuring as I'm currently organizing my own hackathon coming up in 2 weeks.

It's a thematic hackathon ("Startup Weekend Immigration") happening on May 29-31 in SF.[1] We'll be hacking on ways to make it less difficult for immigrants to achieve a better life in a new country, and we have some great speakers including the CTO of Zenefits, who struggled with visa issues himself while co-founding Zenefits.

If you know anyone who would be interested, they can use the promo code "hn" on Eventbrite[2] to sign up for $25, which includes all meals during the weekend. (Early Bird pricing ends tonight at 11:59pm PST.)

[1] [http://www.up.co/communities/usa/san-francisco/startup- weeke...](http://www.up.co/communities/usa/san-francisco/startup-weekend/5961)

[2] [https://www.eventbrite.com/e/startup-weekend-immigration- tic...](https://www.eventbrite.com/e/startup-weekend-immigration- tickets-16092734803?discount=hn)

</comment></comment><comment><USER8> I've done a lot of hackathons, and even the most high profile ones usually suffer from one of the following:

1\. Internet and Working space

If you're expecting a high turn-out. Make sure the facility has a comfortable work environment and enough tables and chairs for everyone to work in. Ensure that the internet will not overload due to too many connections. This is a very common problem

2\. Judging

Different hackathons have different purposes, and make sure the judging aligns with it. Some hackathons focus on business-viable projects, while others aim to build something "cool". Make it clear what the criteria is. If you're looking for cool projects, make sure the judges don't elect a winner because their project made the most business sense, especially if it's just a front- end hack, where the back-end doesn't even work (very common).

Have a way to check that projects weren't built ahead of time. Fraud is a major problem in hackathons.

Good luck

<comment><USER9> "...weren't built ahead of time." Where's the line for this? Surely I'd be permitted to reuse libraries (that I've written; that I got from github; whatever) and perhaps the "project" is a smattering of glue. Am I disqualified because 99% was written "ahead of time"?

<comment><USER8> libraries are fine of course. in higher profile and more competitive hackathons, i've seen quite a few teams who complete the whole project (or re- use the same project from another hackathon).

</comment></comment></comment><comment><USER10> I think of hackathons (and game jams, which I'm more experienced with) as extended parties. You do sit down and get work done, but the atmosphere and presentation are important and make it special. Everyone wants to start near their comfort zone, but also leave happy and with some new perspective.

That means getting all the details right, starting with clear statements about what the event is and what kind of people are expected, the time and schedule, achieving physical access to the venue, who to contact for questions, and what kind of refreshments(if any) will be on tap. Every one of these things will change who actually decides to come: For example, if the venue is in a seedy part of town, people who feel most vulnerable will stay home without assurance of a ride or escort. Photos of an appealing venue can often swing people who were on the fence. Prizes are a question mark as they can massively shift the participation incentives from "do something I like" to "beat the competition", putting a sour note on the whole thing. Unless you have a specific agenda that naturally leads to a competitive context, I would keep it light and try to achieve an "everyone wins" model.

Once on site, the role of the host is one of making sure quality conversations are being had. Team size and makeup is important; teams that are too large and too full of strangers tend to get bogged down in establishing a process and buying in on a project idea. Teams that are too unbalanced in their skillsets get bottlenecked. Teams entirely consisting of friends can usually be very productive, but sometimes the event just becomes a vehicle for whatever they planned to do(which is not always bad). The host can help in all of these by using their position to reach out and make connections that the teams aren't inclined to make on their own.

After the event is over, it's time for followups. A little push can help everyone finish and clean up their project - if you offer to put their project in the spotlight, they'll do a little more than they would if they feel like it's a throwaway, and they'll develop more of a lasting connection with you, the organizer.

</comment><comment><USER11> I've been to around a dozen in the past year, here's my take:

Stable Wi-Fi. Don't charge for admission. Adhere to a strict fresh code rule. Limit teams to 4 or 5. Stick to your judging criteria (fun, business, innovation -- whatever it is, be consistent from start to finish) and find non-sponsor judges to choose the overall winners of an interestingly themed challenge. Provide enough water and food for everyone. If you're hosting it in San Francisco, there are plenty of hungry people who will eat the leftovers. Have 2 rounds of presentations if there are more than 30 submissions. Have someone go around and tell hackers to simplify their ideas and explain the meaning of a weekend MVP.

Follow these and you should have an acceptably successful hackathon. If you want to be memorable though, try something new!

<comment><USER12> Hey! I'd love to learn more about your favorites of the ones you've been to- would you mind sharing which ones they were?

<comment><USER11> Sure! They've actually varied a lot and I've liked them for different reasons, but across all categories I can say I don't like science fair style, really appreciate non-pizza food, and won't wear low-quality t-shirts more than once.

Competitive: Salesforce, Capital One, and AngelHack events are fun because there's a clearly defined goal and some concrete metrics. I really enjoy seeing the pitches at the end and thinking about how we all interpreted the challenge and responded.

Creative: YC Hacks, GitHub Music Hack Day, Yo Hackathon, and Brainihack all elicited some pretty fun stuff. I missed the Brainihack this year though, too bad! Techendo was pretty cool too, albeit small.

Cooperative: Some hackathons had lots of small prizes or none at all. Paypal Battlehack was really fun, a Change.org hackathon was stress-free and friendly, and I learned a lot at a Swift "hackathon" where even the smallest accomplishments were celebrated.

I haven't been to any college hackathons yet, but I'm looking forward to Hacking EDU in October!

</comment></comment></comment><comment><USER13> I've done quite a few hackathons and can speak to this a bit. Feel free to email me if you have more detailed questions. Here are some of the things that have stood out to me over the years (good and bad):

\- Be clear on what you want people to build. Some hackathons want a cool hack or feature while others want a prototype/MVP that could be an actual startup.

\- Have real prizes (cash and/or useful things). I was at a healthcare hackathon recently and the prices were ... engraved plaques.

\- Have some real, experienced VCs help with the judging. They are generally good at knowing what's actually useful and spotting BS. Plus they're a good draw because people love to network with them and hear them speak.

\- Get other companies and services involved by offering sponsor or API prizes. A big, "winner-take-all" hackathon isn't fun. If you don't win the grand prize, it's nice to know you might still win a gift card or iPad from a sponsoring company. It should be easy to get such companies involved (cheap exposure for them).

\- I don't like "science fair judging" (i.e. judges walk around to each group/table and do a private demo). Make everyone present with a time limit and a projector. Part of hackathons IMO is being able to present your product and do a live demo under pressure. If it's a big hackathon, you might need 2 rounds of judging ... but it's the best way.

\- Require entries to be new, working software or hardware. Unless you're explicit, people will try and enter anything from mockups, powerpoint slides, to a "feature" bolted on to an already existing product/service.

\- I think 36-48 hours is the sweet spot for time. But I personally don't work through the night.

\- I've seen some hackathons _require_ teams (i.e. no solo people). I don't see the point. A max size of 5 or 6 is a good idea but there's no good reason to not let people enter alone. You can even have a category "solo" winners.

\- Despite the above, people will still cheat. Don't sweat it.

\- Good wifi

\- T-shirts ... lots of t-shirts

Hope that helps. The best hackathons I've been to were AngelHack, Twilio, and On Deck Cup.

</comment><comment><USER14> From my experience of going to 20+ hackathons, few things come to mind

1\. Have a well defined target audience and reach out early. People make weekend plans.

2\. Be very clear about judging criteria.

3\. Heavy presence of organizers throughout the event. It's not always easy for newbies at hackathon's, and organizers/mentors being around during the whole thing is great motivation.

4\. A good venue where people can find quiet space/at the same time space to socialize.

5\. Find a good balance between cheerleading during the hackathon and people working. Sponsor events are important, but continuous interruptions do not help flow work.

</comment><comment><USER15> It helps to have fairly young people who are desperate to prove themselves in the arena of strict meritocracy.

It helps if they don't have anything else to do for a weekend except cobble together a prototype or even a design document, though the latter is more acceptable if progressive women are involved.

Other than that- hiring booth babes as masseuses for the marathon coding sessions usually involved would absolutely increase success of your Next Hackathon (tm)

</comment><comment><USER16> Judging - consider not having any. None at all. You can talk all you want about "collaborative atmosphere" but if your introducing judging then there is going to be friction, and the better prizes there are the more friction there will be. What's most likely to happen is you'll get ppl coming in preset teams who will studiously avoid talking to anyone else all weekend, which can really kill the atmosphere for anyone who actually wants to work with others.

This doesn't mean you can't have prizes. I saw a hackathon where the presentation at the end was just everyone showing off the cool things they made and then they handed out prizes totally at random. It was great.

What this really comes down to is a much wider issue - what do you want your hackathon to achieve? Just tech ppl who hacked round on a new technology and learnt a cool now thing? Actually a new idea for a thing, but with no plan behind it? Should ideas have a business plan behind them? Do you actually want new start ups to form at your hackathon? Whether you have judging, and if so who judges and the criteria you set will be a very large part of this.

<comment><USER17> This would be pretty interesting. Personally, Im super competitive, and I've found most others are too.

About 4 hours from presentations at my first Startup Weekend, we drastically needed to downscale what we were trying to do. I asked my team "Do we want to build this product, or do we want to win?". All of them said "Win."

And so we did. But that app that won Startup Weekend never saw the light of day, so what was the point?

<comment><USER16> :-)

It all goes back to what the point of the hackathon is really.

For hackathons that are about people actually starting a project and continuing it afterwards (and certainly the Startup Weekend organisers I've talked to locally say this) I think this is the massive blind spot of hackathons - in reality very few projects will continue afterwards. I've seen many things tried to help improve this, and I don't know what the answer is - but I haven't seen anything about the judging helping.

(Edit: congrats on winning tho ... um, after what I've just said!)

</comment></comment></comment><comment><USER18> I'll answer the opposite question; follow none of this advice and you'll probably have a winner.

How to make an awful hackathon:

1\. Familiarize yourself with the "hacker league" but don't affiliate with them; better yet, check their schedule so you can pick a date that conflicts with a better hackathon in the area.

2\. Require that all submissions be new work, but limit the winners to people who have demonstrably worked on their entry for weeks.

3\. This one I picked up from TechCrunch Disrupt SF- determine how much square footage your hackathon used in previous years, then try to cram the next year's into a space half that size.

4\. Also from TechCrunch- get some A-list VC's to speak, then put no effort into soundchecks to ensure people can actually hear them.

5\. Put no one in charge of making sure the event is lively and safe. If participants get the laptop stolen out of the backpack they're using for a pillow, or get drenched by a super soaker, that's their own dumb fault for bringing a computer to a hackathon.

6\. Make all of your prizes in-kind donations of services that hackers either already have in spades or would never use, like discounted Rackspace hosting, entry-level coding classes, or unpaid internships with your own firm. Never offer cash, as the best hackers treat cash offerings as an insult to their professionalism. If you have to offer cash, make the cash a nominal amount, like $10. Better yet, make it a starbucks gift card for $15 - whatever your favorite drink was when you bought it. During the awards ceremony, announce the recipient of the card but never see they get it.

7\. Start advertising for your event three months out, then stop the advertising two and a half months out when you run out of time or money. Make sure no one carries any updates about your event so it can happen quickly and quietly. Only the best hackers will show up because they hate competition, have long memories and mark their calendars. Advertising really is a waste of money and most people spend way too much on it.

8\. Make the presentation process as frustrating as possible for presenter and participant alike. Give people less than 5 minutes to present their idea, and ensure that everyone spends at least 3 of that trying to figure out how to make your AV system work. Ensure you're violating the fire code by making the space small, and make the speakers and projector (not projectors) undersized. Make sure your projector connection is Thunderbolt (for windows-themed hackathons) or HD15 VGA (for Mac-themed hackathons).

9\. Charge for admission to make clear how you're underwriting the event. If you offer $5000 in prizes and expect 100 hackers to show up, charge $100 per entry. Better yet, offer a dual-tier charging structure so prospective investors and members of the public pay nothing. Don't bother checking if the free tier submits entries. Also encourage the free tier to mingle with the hackers while they work. Hackers need suggestions.

10\. Cater the event by the lowest bidder. Costco pizza and Coca Cola products are looked upon fondly by hackers because they don't care about their health. Offer lunch leftovers for dinner, dinner leftovers for breakfast, and so on. You should only really need to place one order of food. Offer an unappetizing vegetarian option and don't label it. Leverage your frugal use of space by doubling hacker workspace as the line for the food.

11\. Ensure your event has too few bathrooms and too few garbage cans. People can crap and throw their trash away at home.

12\. When winners are announced, do it on the down low. Don't put that information on your blog, so when 2019 rolls around and someone wants to find out who won or attended, they can't.

13\. If your projections show you'll be able to sell 1000 tickets to hackers at $50 each, use an easily-gamed system that makes 2 batches of 250 available for $25 each at random unannounced times. Selling out your event ensures the highest quality of hacker.

14\. Buy (6) 3' power strips from Costco and leave them unopened in a corner of the space. For Wifi, use whatever the building already has available. Make the wifi password more trouble to ask for than it's worth.

</comment><comment><USER19> Check out guide.mlh.io for a really detailed walkthrough of everything you need to run an awesome hackathon.

The MLH guide is student focused but you should still be able to get a ton of great advice out of it!

If you're planning on being more business oriented startup weekend has a similar guide.

</comment><comment><USER20> Adding on to what others have said already:

Success: A successful hackathon is where interests are aligned and everyone gets value from the event: the producers, sponsors, api providers, organizers, hackers, volunteers, event scribes, mentors, emcees, judges, audience, bloggers et al. Generally many things generally need to come together to make this magic.

Objective: What is the hackathon's objective? to test an api or tech (sf chatter 2010)? popularize it? build things on it (google wave hack '09)? cross pollinate apis? supercharge a conference (launch '15)? introduce a new tech paradigm (uc berkeley btc hack '14) start a developer program? build a dev program? find great devs or a great team (lady gaga backplane sxsw '12)? to find out whether to release tech (twitter annotations '10)? to pre-accel teams (angelhacks)? to have fun [go hack w/ rbodo @ singularityU:]? create solutions to problems (amex creative-currency '11)?

Prizes: can inspire (pp's 100k prizes), be complicated (sfdc $1m prize(s) '13 hack), be too little (as some have commented) or be just right - which depends on the objectives & aligning interests.

Setup: a page with links to all tech offered / available for the event. If setup is complex & lengthy consider creating virtual machines for devs (transparency & blockchain hack '14). Consider having an harassment policy (tcd sf '13).

Rehearse: if it's your first and you've many people coming, rehearse when doors open & devs pile in. Rehearse the hacks, make sure presenters can easily connect to the projector, have screen settings correct, sound on or off, have right sound level, know how to use a mic. If you've lots of demos - <USER2> have two podiums. If someone's preso can't start or gets stuck, you can quickly switch over to other podium.

Scribe: Have a hackathon scribe. Blog before/after the event. Create a tweet handle. During rehearsals create tweet for each pitch describing what it does & handles or name of at least the team leader. During each pitch, send out their tweet. Tweet each and every winning team. Tweet thanks to your sponsors.

Guides: hackathon.guide hackdaymanifesto.com socrata.com/open-data-field- guide/how-to-run-a-hackathon

</comment><comment> cam- We did a hackathon today. Several things made it a successful hackathon. First; a Product Owner ran the early brainstorming and problem setting. This made a big difference. The engineers were coming up with new products but with the discipline of what works in defining a real product.

Next they broke up into teams of two or three and worked on a specific product idea or feature/improvement. There was a break in the middle of the day when everyone had lunch together, and then back into coding afterwards. The hackathon started at 9am and ended at 4pm with every team having working features to demo.

At least one of the features demo'd will go straight into the existing product, the others will be demo'd to other stake holders and will most likely end up in the existing product but as a more polished feature.

So in summary having a Product Owner over see the brain storming, having everyone work in the one branch together in small teams, and making the new features or products demo'able by the end of the day.

</comment><comment><USER21> There is a lot of good advice here, but let me add my 2 cents

1\. good wifi - a lot of hackathons are not prepared for the number of devices connected when 100 people arrive...

2\. set a clear schedule. My favorite is Fri night - intro session, people present ideas, team building Sat morning - starting to work 10am workshops at 11am end of coding Sun at 12pm presentations Sun 1-3pm Judgement - <USER3>

3\. team building is a critical part in the event. I normally have a few people from the organizing team helping people find who to work with. We have tried using colored stickers for different expertise - developers, designers, ideas, FEDs, etc. Most hackathons do not have sufficient designers.

4\. Food - keep in mind that Pizza is great for males. But women may like lighter food. Given you have an over-night event, you need to take care of that. Same goes for beer - have a wine option

5\. As many organizers as possible in the event. People have questions and need help all the time. The more people you have to help the better.

</comment><comment><USER22> Sandwiches from a local deli make awesome lunch. One hackathon I went to had these ginormous bean bag chairs, so that was cool. Don't make people attend certain sessions/presentations. You can offer them for those interested, but don't require attendance. Having a very open prompt/challenge is appreciated. If you want to make it more specific, that's fine, but keep it open ended within that specific theme. i.e. "do something creative related to xyz and abc", not "design a solution that will do xyz and also does abc and of course meets the criteria of jfk".

</comment><comment><USER23> I haven't been to many, but I'll throw in my 2c regardless.

\- Venue. The space available can make a _massive_ difference in how people collaborate and get creative.

\- Prizes. Most people need external motivation as well as internal motivation.

\- Time/Convenience - I'd put it on a weekend. Most people (students, working adults alike) can't afford to use credit hours on a hackathon, regardless of what the prize is.

\- Sponsors. The greater and more "prestigious" the sponsors are, the more likely teams are to network and get assistance in valuable ways. Mentorship is the most valuable part of the MLH hackathons I have attended.

</comment><comment><USER24> We need more 'hack' and less 'thon'

Too many hackathons try to motivate people with incentives, but that creates winners and disappointed people.

I think a 1-day, or 2-day hackathon with a no pressure show-and-tell keeps people excited, motivated, and happy. It should be about the joy of hacking, but in community and in a great setting where people with different strengths are able to share and try out new ideas. It shouldn't be a race against the clock where everybody does what they do best to compete - it should be a safe setting where people can experiment and dabble and mingle.

</comment><comment><USER25> I do a lot of hackathons. My record is 4/26 for winning 1st, 16/26 for winning 1 or more prizes, mentored 3 times and judged once.

Do it on a weekend, have interesting sponsors with prizes, and make the judging/presentation criteria very clear from the start. Also attendance can be hard to estimate, not everyone will show up and not everyone will come back, plan accordingly.

Also, three pieces of advice I always give at hackathons:

      1. work backwards from the presentation
      2. only build what you show
      3. only show the interesting parts

Happy to mentor/judge, email@example.com.

<comment><USER16> You seem to be being downvoted a bit, not sure if it's your ridiculously boasty first paragraph or your 3 bits of advice.

But if it is your 3 bits of advice, I'm actually going to say that for a certain type of hackathon, those bits of advice actually make perfect sense. So many hackathons are obsessed with judging and prizes, usually based off judges seeing very little in a brief presentation. If you really want to win, your strategy makes sense. While I haven't adapted it wholesale, I've certainly been in situations where I have prioritised technical work by what will play best in the presentation.

Personally tho, I find this a little sad and the atmosphere at these hackathons can be a little rubbish.

</comment></comment><comment><USER26> From personal experience: Pay the winners!

</comment><comment><USER27> hackathons seem to divide into two main types - one where people get together to build stuff and advance the state of a (usually popular) open source project via a concentrated sprint, and the other where people or teams compete for prizes.

personally, the latter strikes me as betwixt and between - if i wanted the competition, i'd rather enter a pure programming contest with explicitly artificial problems and well-defined judging criteria, and if i wanted to build something i'd rather be doing it cooperatively than competitively.

</comment><comment><USER28> @idbthor I run a wearable/iOT hackathon called WearHacks.com and I tried reason from first principles.

What is essential for a hackathon? 0- Branding: Sponsorship Decks and "About us" documentation. 1- A Venue 2- A Food provider 3- Sponsors 4- Judges 5- Mentors

Make Three teams:

Operations: In Charge of the schedule/logistics and 1,2

Sponsorship: In charge of 3,4,5

Community/Marketing: In charge of getting the hackers and can help get community mentors.

Hope I helped! If you have any other questions email me at shehaaz @ WearHacks.com

</comment><comment><USER29> It really depends on how big of a hackathon you are running. In the previous year I have organised one ~50 person hackathon, and one ~200 person (part of a larger 1500 person event). Vastly different logistics.

Have a read of the Hack Day Manifesto, as it will probably trigger at least one 'aha!' moment of something you forgot: [http://hackdaymanifesto.com/](http://hackdaymanifesto.com/)

</comment><comment><USER30> Adding some ideas I've seen work:

* Raffle tickets given out to people who are "caught" helping others or generally helping out.

* Dedicated person who knows all the movers and shakers and is familiar with the attendees and skill sets, who can be reliably found in a fixed physical location on site, and who can summon helpers to track down people, solve problems, make introductions. Basically a concierge on steroids.

* Random access session at the start where people line up and have 60 seconds to say either: what idea they would like to work on, what skill set they have, what skills they lack and would like to pair up with. At the end of this people can talk to each other and form project teams if they like.

* Kid friendly - no ridiculous age rules for kids (but sure, kids need to be supervised by their guardians, that's perfectly reasonable). And kids categories for some of the contests if any. But no sequestering kids off in "kid" activities. Encourage them to participate in the same projects as everybody else.

* Generous food choices, including copious amounts of ice cream, sweets, and caffeine, and maybe a healthy thing or two for those who want that. Popcorn is not a generous food item. You burn a lot of calories. Food doesn't have to be gourmet... pizza is great.

* Lots of comfortable spaces and seating including nooks, tables, offices, open areas... a variety but most importantly plenty of spots for everyone with plenty of extra left over, so people can get a tiny bit isolated to focus with their team, if they want to.

* Open hours at the end where family or friends can come in without tickets (if tickets were even required) to watch the final demos / contest.

* A good platform or topic that engenders enthusiasm.

* If there's a contest for projects, have some funny prize categories. Leave room to make some up to fit the entrants. Encourage humor.

* Don't fixate on rules. Safety, sure. But lighten up.

What doesn't seem to add a lot:

* Huge money prizes... sure I have nothing against them but the fun seems to be more important.

* Group photo... this is always a drag, interrupting the flow and disrupting work as people run off to join it and you invariably get dragged along. And the photo is too few megapixels to really be worthwhile.

</comment><comment><USER31> * all participants retain 100% ownership of all digital assets produced during the hackathon

^ if that's included then it some kind of a scam IMHO. Why would an team want to program in a legally onerous environment as opposed to say, a mall food court ?

</comment><comment><USER32> Rigid flexibility. Have a well defined end goal, with judging criteria available from the start, but don't restrict contestants in what resources they can use, tech, people, etc

</comment><comment><USER33> Assign people a random team. Try to make sure each team has people with different skills, so that everyone can bring something to the table.

Good internet connectivity.

</comment><comment><USER34> Learning something.

</comment><comment><USER35> Meeting people.

</comment><comment><USER36> Good food.

</comment><comment><USER37> If the participants are teaming up to produce a product, there needs to be some agreement on how any resulting equity will be divided. You can't just assume they'll split it equally.

</comment><comment><USER38> Just make sure that there is enough Apple equipment in the room and that the hackathon itself produces a lot of useless stuff that no one will ever need. Perfect hackathon.

<comment><USER39> idk that doesn't sound like it's focused enough on the benefits of proprietary apis or flashy UIs</comment></comment>


Weaving the way to the Moon - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/8148730.stm <comment><USER2> David Mindell gives more details of the AGC rope core memory in his book Digital Apollo. The software was stored in the wiring pattern, not in the cores themselves. The MIT programmers had to deliver final code three to four months before each mission. That turned out to be an advantage because "risky last minute changes of the program just before the flight were physically prevented," according to program director David Hoag.

<comment><USER3> IIRC, and this is secondhand from folks at MIT Instrumentation Lab, it was a simplified version of core memory. Ones were represented by cores and zeroes by the absence of cores, so the memory woudnt need the write cycle after the read to restore the state of the memory and there was no need to boot the memory.

</comment></comment><comment><USER4> I think 'LOL memory' could become a new meme.</comment>


Ask HN: Are self hosted SAAS generally provided as source or compiled? - <AUTHOR> Question is in the title. If you're offering a self-hosted version of your SAAS, is it expected that you hand over an unobfuscated copy of your source? Or do you generally distribute compiled files? <comment><USER2> I obfuscate using UglifyJS before sending. I send it with a file that runs the program and all the dependency libraries built in so it is self contained in a zipped folder. The customer downloads the folder, unzips it and runs it.</comment>


Async and Await in Rust: a full proposal - <AUTHOR> https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/ <comment><USER2> Note that this post is from April, and a lot of experimentation and reams of discussion and debate have taken place regarding the details of the two RFCs in question (along with other related RFCs such as the one for the Pin trait). In fact, one of the RFCs linked at the top of the OP has been closed and superceded by a newer one: [https://github.com/rust- lang/rfcs/pull/2418](https://github.com/rust-lang/rfcs/pull/2418) . I've actually heard that tomorrow (Monday) the futures and networking working groups will begin a series of regular blog posts on design and implementation leading up to the release of Futures 0.3 (which IIRC intends to be more-or- less the final design for Futures 1.0).

As for this article, I _think_ the broad implementation details that it talks about are largely still accurate, just don't take it as gospel. :)

</comment><comment><USER3> And yet we somehow don't acknowledge the fact that this is just do-notation for some specific monad--yeah, that powerful abstraction that can't be expressed in Rust because we don't allow higher-order polymorphism. Don't get me wrong, i'm bitter because i feel like Rust really is almost in the right direction for the future of language design. Yet there is a long time before we get a language with a really precise type system (linear, "pure") and thus with highly efficient code generator (~rust), that at the same time has all the higher abstraction goodies, maybe even dependent types (cf quantitative type theory [1]). Of course they took that into account, it's even explicitly mentioned in the rfc, and it got turned down for being too experimental, but at some point you gotta make a bold step forward and force people to actually care about abstractions.

Now that Rust is getting some maturity i worry that it gets too complex in too much direction just because it's not powerful enough to express the few common abstraction, of which several instances are being added as distinct concepts (async&try, const datakind, higher-order poly--especially for lifetimes, named impls, before-after memory state for references...).

[1] [https://bentnib.org/quantitative-type- theory.pdf](https://bentnib.org/quantitative-type-theory.pdf)

<comment><USER4> I don't have time to write a whole essay, so let me just establish my credentials:

\- I wrote the generic associated types RFC (how Rust will implement higher kinded polymorphism).

\- I wrote the const generics RFC (the closest Rust will get to dependent types).

\- I wrote the async/await RFC, as well as the linked blog post.

That is to say that I am intimately familiar with how Rust's type system can be extended to support more "powerful" abstractions.

Monads as implemented in pure functional programming languages like Haskell cannot usefully abstract over asynchronous and synchronous IO in Rust for a variety of reasons having to do with the way the type system exposes low level details by virtue of Rust being a systems programming language. I do not believe that `do` notation could be a useful mechanism for achieving either the ergonomics or the performance that async/await syntax will have in Rust.

I'm responding to you because you're the top comment, but I could write a similar response to a lot of comments here. Monads, stackful coroutines, green threads, CSP, etc - we've heard of them! :) We have well-motivated reasons to choose async/await: its the only solution that meets our requirements.

<comment><USER5> > Monads as implemented in pure functional programming languages like Haskell > cannot usefully abstract over asynchronous and synchronous IO in Rust for a > variety of reasons having to do with the way the type system exposes low > level details by virtue of Rust being a systems programming language. I do > not believe that `do` notation could be a useful mechanism for achieving > either the ergonomics or the performance that async/await syntax will have > in Rust.

Sorry, but I don't buy it. I had a half-baked, unfinished proposal for an effects system that would have allowed Rust to implement async/await just as efficiently (no stackful coroutines) along with any number of other effects [0]. Maybe it wouldn't have been a good idea due to stretching Rust's complexity budget too far, but that's very different from saying it's impossible. Having watched the development of Rust closely I really think that the design team just didn't understand the theory side well enough to be able explore the design space here. (I'm not being as critical as I might sound, PL theory is _hard_ and the Rust devs have wielded it _much_ more competently than the designers of any other non-research language).

[0] [https://internals.rust-lang.org/t/start-of-an-effects- system...](https://internals.rust-lang.org/t/start-of-an-effects-system-rfc- for-async-etc-is-there-any-interest-in-this/7215)

<comment><USER4> The first part of your comment is unresponsive to mine; the last part is pretty rude & factually wrong (we are not _motivated_ to implement an effect system right now; we understand the theory).

Sticking to the first part: an effect system is not what the user I was responded to was talking about. They were talking about building do notation on top of type classes with higher kinded polymorphism, which cannot effectively abstract over the monadic operations in Rust.

<comment><USER5> > The first part of your comment is unresponsive to mine;

I interpreted OP's comment as complaining about the lack of more general abstractions in Rust that would allow you to implement async/await. Your comment specifically mentioned Haskell-style monads (eg. a `Monad` trait), but that's not the only way to implement something like this.

> the last part is offensive & wrong

Quoting steveklabnik:

> it's an open research problem if do notation can work in Rust. Until that's > solved at all, we're just not sure it's possible. ... "Open question" > doesn't mean "impossible", mind you. But nobody has ever come up with a > design. In the meantime, we have users to support...

Isn't this what I was saying? "We don't know how to do it, so we're going with the easier option."

 __Edit: __To be clear, I don 't think async/await we've ended up with is necessarily in the wrong direction. But I also don't think that "we thoroughly explored the design space of do/monads/effects and concluded that they were impossible to implement ergonomically/efficiently" is really true.

<comment><USER6> "impossible" is a highly contextual term here. Adding this to Rust isn't "impossible", of course it isn't. We can "just" slowly turn Rust into Haskell using the edition mechanism. Done.

When folks say something is "impossible" in such a context, they mean "given the constraints", which include goals the lang team has for the language. An effects system is pretty heavyweight and may violate these goals.

<comment><USER4> I think that there is not a definition of the Monad trait - not just undesirable, not possible - that can abstract over all Futures and Iterators _as implemented in Rust_. You would have to use some kind of trait object & lose the incredible inlining benefits that Rust gets from how these interfaces are designed today.

This is separate from effect systems, which I never said was not possible. rpjohnst's parallel response sums up the key differences between monads and an effect system.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This thread is so confusing to me. Not because of complex differences in a language theory, but on choices that developers do follow due to experience in 'the past', regarding light threads. I understand that rust has no stdlib, that go has, and that js just doesn't have switchable stacks. But _why_ does almost everyone inclined to async-await in general? The answers I got in other threads (not on this exact question, but along the lines) is that async-await makes runloop-tearing points explicit. But is it really so important? How does a regular js guy manage a state incapsulation in-between their futures' callback invocations? All the code I see is then-then-catch and it doesn't account for, well, asynchronous effects like races; it just occurs naturally by not modifying other chains' states. Why not just go with seamless coroutines then? Why making functions explicitly async? (Or sync, if that matters.)

Maybe I'm misunderstanding something, but since people here are so fluent in concurrent execution, can someone point me to an in-depth explanation why are light-threads, coroutines, current-continuations, etc. so opposed by async keyword (and futures in general) today?

I have some experience with low-level runlooping via coroutines in luajit and understand it to the point to be able to create asynchronous system, consisting of mix of os threads and coroutines (and it worked smoothly until our project was closed due to company's external issues). I can say, I never felt the need of something different, neither met the 'complexity' of everything-can-yield rule. And the possibilities that open, i.e. scalability of simple code around io and cpu cores is just outstanding. I am genuinely curiuos what's so great (or different) in futures, which seem to me, for now, just poor man's light threads implemented via lexical closure overhead along with syntactic snow, running on a single-core cpu. This topic seems to be so narrow that modern google is too shallow to answer that. I believe there should be a LtU or similar thread that discusses it in classic depth. Thanks in advance!

<comment><USER8> Note sure if I fully grasped your quesiton but here it goes.

Light threads and stackfull coroutines require stack allocation. That is their cost and it is unbearable for system-level language priding itself in zero- cost abstractions. Eg. AFAIK, it's the main reason that is making Go calling C code slow.

Also, (again AFAIK) Rust stackless coroutines and futures compile down to state machines, so I don't understand the "lexical closure overhead".

There's nothing forcing futures to be "running on a single-core cpu" in Rust, since Rust can reason about thread-safety.

Personally, after couple of months of using JS at dayjob, I very dislike JS (as I thought I would), but I love coroutines/yield. I think they will be glorious in Rust: they will allow writting reasonably nice code with an amazing performance.

<comment><USER7> To clarify: not why extreme requirements discourage heavier methods, but why people don't use them for daily jobs that don't require anything than fastest delivery time.

</comment></comment></comment><comment><USER9> I'm somewhat disappointed that rust is going with async style stackless continuations. I'm a huge fan of stackfull coroutines/continuations as they are much more elegant and flexible. The downside is that they need a full stack, but I strongly believe (but can't prove) that rust has enough annotations and lifetime capabilities that it should be able to guarantee single frame allocation (or even no allocation for fully scoped coroutines, like many generator use cases) in every situation that the async model would.

There is an ongoing discussion in the C++ world between traditional C# style async, a more extreme non-type erased version (similar to the rust implemation I think but unsafe) and stackfull coroutines. Some (like me) hope that an hybrid solution might be possible.

<comment><USER10> We already have stackful coroutines. They're called threads. If for some reason you want M:N threading, we have that too, via the mioco library. (If you think mioco's M:N threading will provide far superior performance to regular 1:1 threads, though, you will probably be disappointed.)

If you look at the performance numbers of these approaches, you'll see why stackless coroutines are desired.

<comment><USER9> I want stackfull coroutines, with custom, fast user space scheduling and task switching with guaranteed optimisation to a single stack frame and no allocation where possible.

I also want the ability to convert internal iterators to internal iterators with no overhead and even (especially) if the internal iteration function has not been specifically marked (i.e. no red/blue functions).

Hey, a man can dream.

<comment><USER11> > guaranteed optimisation to a single stack frame and no allocation where > possible

You are literally describing _stackless_ coroutines. And the generator state transform _is that optimization_.

If you want to get this _without_ using generators explicitly, it's still stackless coroutines just not how Rust supports stackless coroutines. There was some discussion about making it more implicit but no progress was made in the implicit direction.

<comment><USER9> Very much not. I want first class stackful continuation semantics that behave as stackless in at least all (but ideally more) scenarios where a stackless continuation would.

</comment></comment></comment></comment></comment><comment><USER12> This is exciting. It allows programmers to model their problems in code that fully accounts for the parallelism.

For comparison, here is async/await in Zig: [https://ziglang.org/documentation/master/#Coroutines](https://ziglang.org/documentation/master/#Coroutines)

Zig decided to go the other way - when you async call a function, it _does_ eagerly evaluate until the first suspend point. This is less overhead than immediately suspending, plus it removes the dependency of the language feature on a userland event loop. Users who want the immediate suspend feature can call a userland utility method of the event loop which suspends and then tail calls the async function in question.

<comment><USER13> It's exciting to see so many systems programming languages implement async/await.

For a further comparison, Nim works in the same way as Zig when it comes to eager evaluation. Something that I'm particularly proud of when it comes to Nim's async/await implementation is that everything, right down to the macro which defines what `await` means, is implemented in the standard library. The compiler only implements the coroutines. This means that the language isn't bloated by this extra feature and makes it much easier for developers to implement their own async/await.

I believe there was talk to do the same in Rust, but for some reason the developers decided to implement it in the compiler instead.

<comment><USER14> Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere?

Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so you can write your own if you want.

<comment><USER15> Pinning is almost entirely a library feature; it does use the unstable "auto traits" functionality of the language, so it's a _bit_ special in that regard. But it's provided by the standard library.

</comment></comment></comment></comment><comment><USER16> As an embedded system dev, I'm wondering if these async features can be implemented on bare-metal (or without runtime)? Maybe I'm dumb and it might be a wild thought but it would be great if I could easily integrate async language features with hardware interrupts.

<comment><USER17> Definitely. We're currently blocked with the builtin await using thread local storage, but that's planned to be removed and replaced with something that will work without an OS before stabilisation.

I have had the old macro based async code in Rust running on a Cortex M device, completely runtime free. Once the TLS stuff is sorted I plan to port this forward to work with the builtin syntax.

<comment><USER18> What's the TLS stuff to be sorted out?

<comment><USER15> IIRC, the initial implementation of async/await requires TLS. Eventually it won't.

<comment><USER18> Oh! For some reason I jumped to Transport Layer Security, not Thread Local Storage... duh.

Yeah the Pinning stuff is supposed to help with this as I understand.

<comment><USER15> Ah! Super reasonable, yeah. It can be confusing.

</comment></comment></comment></comment></comment></comment><comment><USER19> I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call.

If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

<comment><USER20> Having made "async" the default, you've just returned to regular threading, which is what we should have stuck with all along. The thread model is actually pretty useful, the pitfalls are well understood, and the tooling very mature.

<comment><USER21> Threading sucks. It's a situation where you have some external process (the operating system) deciding when different pieces of work should be woken up, with no way of feeding this back (so it just bases it on relatively naive schedulers).

In practice, most of your threads are in one form of wait loop or another and you've just got polling both inside the threads and with the scheduler.

Have a look at Erlang if you want a better model :) the erlang "processes" (different to os processes) can intelligently only wake up when there is work for them to do.

For a language to efficiently use cores, it really needs to include it's own scheduling.

<comment><USER22> To pick some nits and generally elaborate, Erlang's VM also has a scheduler; it's not the presence or lack of a scheduler, it's how efficient it is and what guarantees it allows the programmer to make about their system. For example, OS schedulers are typically pre-emptive, which means your OS thread can get interrupted anywhere. On the otherhand, Go's scheduler (I'm using Go because I'm more familiar with it than with Erlang) only allows context switching at well-defined points in your program. Further, operating system threads have more overhead than in Go (presumably also Erlang) because they're fixed stack size (yes, I know this isn't true for all OSes).

<comment><USER23> >only allows context switching at well-defined points in your program.

Erlang works the same way. The VM scheduler will only context switch on a function call. for or while loops don't exist in Erlang which means there is no risk of blocking the scheduler.

<comment><USER22> I assumed it must, I just wasn't familiar. Thanks for clarifying!

</comment></comment></comment></comment></comment></comment><comment><USER24> I just finished reading the proposal and I'm super impressed and even excited. I really appreciate the commitment to not leaking implementation details into the standard library (i.e. exposing only the interface). This is fantastic for both embedded and (operating) system applications. Nice work everyone.

</comment><comment><USER25> I want to reflect on that this is still done without any garbage collector.

<comment><USER26> Why would anyone assume that a GC is needed for async/await?

The Future object seems to do the all bookkeeping needed by the borrow checker (which I believe is what rust uses to track the lifetime of objects).

<comment><USER27> Maybe because most future implementations (e.g. in Javascript, the proposed C++ solution, Seastar, etc) work by scheduling a continuation on an event loop. Which obviously requires at least some form of dynamic memory for queuing up these continuations.

<comment><USER9> I think seastar futures are allocation free. Standard c++ futures are not really a paragon of efficiency or good design. Still no GC though.

<comment><USER27> I haven't read the code, but there are 2 areas where I expect allocations:

\- The continuation which is passed to .then, and which is typically a closure, must be type-erased, which requires an allocation. Storing the continuation in a std::function would allocate too. A short glance at [https://github.com/scylladb/seastar/blob/master/core/future....](https://github.com/scylladb/seastar/blob/master/core/future.hh) also confirms that there is a make_unique there.

\- Since continuations are most likely not called inline on completion but deferred into the next eventloop iteration there needs to be a dynamically sized queue to hold the ready continuations. I am not 100% sure if that's the case for seastar too, but I would guess so.

<comment><USER9> I do not think the continuation is type erased. I belive that then, at least optionally (depending on the actual futurator passed in) can returns a future whose type encodes the continuation type and stores it inline.

The queue might be dynamically sized which might eventually require allocation, but that can be ammortized across many futures. A large enough queue might never require reallocation.

I'm also not 100% sure as I have never used seastar.

</comment></comment></comment></comment></comment></comment><comment> Const-me I think the hard part here is not language design, it's implementation of the runtime.

Linux is especially problematic, asynchronous IO has arrived late, years later than IOCP and kqueue. It took multiple kernel versions to make it usable, and still the APIs are questionable, e.g. files and sockets use different ones.

Even MS failed to do it right, see a bug I found: [https://github.com/dotnet/corefx/issues/25066](https://github.com/dotnet/corefx/issues/25066)

</comment><comment><USER28> I know this may sound silly, but can someone make a quick rundown of the pros (and maybe cons) of Rust as compared to NodeJS, Go and Erlang? Why would people use it as opposed to these far more mature ecosystems, especially if it's hard to master based on the comments I have seen from Rust users? (Not trying to be biased, actually want to ask people who do choose it.)

<comment><USER29> Hard to master doesn't mean it isn't worthwhile to master. And the only reason the Rust ecosystem is not more mature is because not enough effort has been put into it. By learning the language and working in it, both of the problems you point out will solve themselves.

This is a classic "being traffic" comparison. If you're in a traffic jam, you are as much the cause of it as anyone else is. Likewise, if the ecosystem is immature, you are as much the reason for that as anyone else who doesn't participate in it.

<comment><USER28> The same could be said about any charity or relief effort, but typically people join the ones that are already easy to join.

<comment><USER29> I wasn't meaning to imply any obligation that you should be using Rust or anything. My point was only that the reasons people do things are already very familiar to you, so it doesn't do much to be incredulous of their motivations. I don't watch baseball, but I understand why people do it even if I can see no real value in it. People are motivated by a rational advantage far less often than by things like accessibility, familiarity, habit, curiosity, popularity, culture, counter-culture, identity, or need -- all of which are reasons that people use programming languages not present in your list.

Perhaps this is just obvious. But I do frequently see people pretending to be objectively objecting -- complaining about traffic that they are themselves the cause of as if they didn't already know the answer to their question.

</comment></comment></comment></comment><comment><USER30> How about lightweight threads, or are they there already?

Going to Go with its LWT goroutines was awesome. Would never want to go back to async, which is really just a manual way of implementing LWT.

<comment><USER15> You can sort of think of tasks as green threads. It just really depends on exactly how you define your terms; this area has a ton of similar sounding terms that different people define differently.

The downside of Go's approach is the overhead of calling into C; Rust can't afford this. Go can. IMHO both languages are making the correct choices with regards to their constraints.

</comment></comment><comment><USER31> Usually we add notes like (2016) to old articles. In this case it would be appropriate to add (April 2018) to the title given how fast the futures ecosystem is moving in Rust.

<comment><USER32> 2018 is assumed

<comment><USER33> But April isn't, and (April 2018) is less confusing than just a bare (April).

</comment></comment></comment><comment><USER34> Why does it have to be either one? Why not the possibility of choosing the implementation you want to solve the problem? A language where you could easily run whatever you want would have my vote. Not having it shoved down my throat (I'm looking at you JS). While it's possible to build most of it yourself you should have the possibility to choose.

<comment><USER35> Be careful with this. I'm not saying you should not do it, but consider you'll have to design it very carefully.

In python you can chose what event loop to hook to async/await, and hence we have gevent, qt, uvloop, twisted, asyncio, tornado, trio and curio as competing implementations.

They are very difficult to mix, and their ecosystems are mostly isolated, dividing the man power to add features, fix bugs, provide support, create libs or frameworks and write docs or tutorials.

Another problem is that you have (except for gevent which causes other problems by monkey patching the stdlib) to setup the event loop explicitly.

Those mechanisms are complicated, easy to get wrong, confuse beginners, make docs introduction long and annoying or misleading before getting to anything interesting.

E.G: to use asyncio, you are exposed to an event loop, an event loop policy, awaitable, coroutines, coroutine functions, futures, tasks and task factories.

But there is worse... You can setup any event loop any way and time you want, and because the api is public, another lib can come and swap it. No lib to my knowledge provide any form of locking.

This leads to some weird situation where libs are considered so low level you end up writing wrappers on top of it (e.g: [https://github.com/Tygs/ayo](https://github.com/Tygs/ayo)) just to be able to start using it sanely.

Now compare with JS.

I'm really not a fan of the language. However, even when you can't use async/await, using a promise is straightforward. You don't have to bother about creating the loop, starting it, stopping it, cleaning after it has stopped. You don't have to wonder if somebody is going to swap the loop. You don't have to get a reference to a loop to schedule anything. Actually you can mostly ignore the loop and just code the solution to your problem.

Now this makes JS dependent on one loop implementation for each runtime. Also you can't code any new async feature in JS, only use the existing ones. It's probably not what you want for a language like rust.

However, you should learn from the python ecosystem fragmentation and overly exposed low level API to avoid the same mistakes.

Somebody that just wants to use async/await should not have to learn how the implementation works in details, nor take so much precaution to avoid implementation lock in or break somebody else work.

And you really want a federated ecosystem. Having 7 incompatible websocket lib sucks.

<comment><USER36> Concur.

Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.

<comment><USER35> > Although perhaps the situation in Python could have been mitigated somewhat > if a protocol was defined early that implementations could have adopted?

Yes. That's one thing the rust community has to get right.

async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is scheduled, request the result or error on said scheduled thing, or cancel it. And even loop must bridge different implementations of concurrency (e.g: asyncio.run_in_executor). An event loop also has a life cycle, which includes at the very least a setup and a tear down. An event loop must integrates in an environment, like what do you do when you have several loops, or if you run one loop per threads ?

So you need to define a general behavior for all that. Then let anyone write the implementation the way they want.

<comment><USER15> That's all of this: [https://doc.rust- lang.org/nightly/core/task/](https://doc.rust-lang.org/nightly/core/task/)

<comment><USER35> That's an API. Like asyncio in Python is an API. If you make the event loop swapable without making this API mandatory however, it's never going to be a protocol.

<comment><USER15> The api is mandatory; it's how async/await works.

<comment><USER35> So everybody has to implement a task for any alternative event loop and accept tasks from other implementation ?

<comment><USER37> Yep. You build your event loop to take structs implementing the Future trait. The futures don't care about the executor, and it's easy to switch from an event loop running on the current thread to a thread pool, if needed.

<comment><USER35> Great. I wish we have done the same.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Minimum Viable Market - <AUTHOR> http://www.victusspiritus.com/2011/03/06/minimum-viable-market/ <comment><USER2> It's an interesting way to look at it. For most startups, I think the key is coming up a small highly-targetable market segment to start with -- the place you get your 100 first true fans and then can expand by word of mouth (as well as all your other marketing strategies). I've always thought of it more as a niche than an MVM but the analogy to the MVP is an intriguing one...</comment>


jQuery Mobile + Backbone.js, working together - <AUTHOR> http://bennolan.com/2010/11/24/backbone-jquery-demo.html

<comment><AUTHOR> In related news, Backbone 0.3.2 was released this afternoon. If you haven't upgraded your copy in a bit, 3.0+ includes Controllers, and more flexible REST persistence for legacy web servers.

<comment><USER2> Do you have any plans for doing form building capability in backbone? I was trying backbone out and I found that to be a part that I would like to have in there. I was trying to figure out the best way to get it done. I'm thinking something along the lines of what Sammy has:

[http://code.quirkey.com/sammy/docs/api.html#Sammy.FormBuilde...](http://code.quirkey.com/sammy/docs/api.html#Sammy.FormBuilder)

Also, great job on this (and coffee script as well).

<comment><AUTHOR> I'm afraid that there are no plans to add a FormBuilder to Backbone proper -- the idea is to keep it light, and forms are probably best created with your chosen JavaScript templating library in any case.

</comment></comment></comment><comment><USER3> It's amazing how fast web development can change. jQuery Mobile and Backbone didn't even exist a 2 months ago and CoffeeScript is also just getting popular lately.

Who knows if these new libraries/technologies will catch on but it's an exciting time to be a web developer.

<comment><USER2> I blame github.

<comment><USER4> I hate projects with empty README. I still don't know what Backbone is and not going to have to open the source to find out.

<comment><AUTHOR> The readme, such as it is, can be found here:

<http://documentcloud.github.com/backbone/>

You certainly don't have to open the source.</comment></comment></comment></comment>


An Open Letter to Brogrammers - <AUTHOR> http://tacit.livejournal.com/588807.html

<comment><USER2> It's not a very good letter. I don't think most "brogrammers" are ignorant and unaware of Grace Hopper or maintain that girls can't code. Rather, they create and celebrate a workplace culture that no women (and only certain men) should be expected to tolerate.

Klout advertising for programmers to "bro up" isn't saying "yo, us men are better than women", it's saying "let us hang around like it's a fraternity, have some beer, ogle some sexual imagery and make crude jokes". (On the plus side, there's some camaraderie there for those who do fit into the culture, I guess.)

<comment><USER3> I get the feeling that they didn't get many female applicants to the position... That's a bonus for those who fit the 'culture' though, because they had a better shot at getting a job.

</comment></comment><comment><USER4> I don't get the point of this article. There some smart women in technology, ok, and that is being used as a club to hit men with? Please explain.

<comment><USER5> It's not being used as a club to hit _men_ ; it's being used as a club to hit misogynistic idiots who feel big when they make other people who happen to be women feel small.

</comment></comment><comment><USER6> Please kill the term "Brogrammers" with fire.

</comment><comment><USER7> You know, using the arse picture at the top makes it really quite hard to take the article seriously. Especially at work.

<comment><USER3> The author is sharing actual ads for coding services and vacancy announcements from companies, in order to highlight examples of misogynist culture in the tech/startup sector.

<comment><USER8> I don't see how that tells anything about culture of tech/startup sector at all.

<comment><USER3> Klout's ad clearly tells women that they don't want to hire them. There is no part of "bro" that implies gender neutrality. More subtly, it expresses the idea that women are probably not worth hiring. Even more subtle is its message that gender-specific hiring is acceptable. Klout outdoes itself in undermining the clause, common in many hiring documents, that the company "will not discriminate on the basis of race, color, ethnic origin, national origin, creed, religion, political belief, sex, sexual orientation, marital status, or age".

I don't know that this can be expanded to characterize the overall culture of the tech/startup sector – I've never observed it (thought it does have a reputation for misogyny). In any event, the author's intent is to respond to the "bro" discourse that actual employers and companies included in their public-facing materials, by satirizing it with similar language.

<comment> mkr-hn > _There is no part of "bro" that implies gender neutrality._

Some of my best bros are women.

</comment></comment></comment></comment></comment><comment><USER9> Whenever someone flags a post with a respectful title, I urge them to write a comment.</comment>


Repurpose, A Mini Documentary About Hardware Hacking & Hackerspaces - <AUTHOR> http://laughingsquid.com/repurpose-a-mini-documentary-about-hardware-hacking-hackerspaces/ <comment><USER2> Wow, reminds Homebrew club days.

And those guys have a pic of 'The Woz' on the wall <http://www.youtube.com/watch?v=MOTw_PkK_SU#t=7m36s>

</comment><comment><USER3> <http://www.c-base.org/cv50f/>

(in German but still interesting to get an impression I think even for non- German speakers)</comment>


Ask HN: I want to be good at everything - <AUTHOR>

I want to become a good developer so I can create my own things, I want to become a great marketer so I can promote them, I want to be awesome at design because I love creating and I want to become a great business person because that's been the most appealing my whole live.
Specialization is good says some people, you should have T-shaped skills says others, specialization is for insects says another.[1]
Is the above unrealistic, or does everyone have these goals in some way, but you have to choose what you're good at and delegate the rest/leave them for hobbies?
[1]http://en.wikipedia.org/wiki/Competent_man <comment><USER2> I would not call that unrealistic. A few comments:

(1) Only on HN would anyone dream of referring to your list as "everything". You are actually targeting a very narrow, focused skill set: those required for a small(-ish) software or software-intensive business. Like it or not, you're proposing becoming a specialist (albeit with a somewhat broader specialty than a typical job description would call for).

(2) In the real world, "everything" includes many, many other things. To get good at all that stuff on your list, you'll need to leave other skills by the wayside. The comment by taprun mentions chess, running, and cooking. You won't be getting better at any of those.

(3) The I-do-everything approach sets a hard limit on the size of a business. An important reason for hiring & delegating is so that a business can grow.

</comment><comment><USER3> In economics, I learned about something called a "trade-off". Basically, if you spend time learning something, you are spending that time not learning something else.

I remember meeting someone who was fantastic at chess. He destroyed me. Repeatedly. My mental model of him was essentially "me but good at chess". It didn't occur to me until much later that he didn't know how to program a computer, couldn't run a mile without stopping and didn't know how to cook Chinese food.

I think if you stop seeing people as "you but can do X", these feelings will go away. Alternatively, read up on the concept of "comparative advantage" and realize there is a mathematically proven reason not to try to be an expert at everything.

</comment><comment><USER4> This is largely the same goal that I've set for myself. I spend a good amount of time doing each (less marketing lately, more towards coding/design), and find that while I outpace most people in these fields, there's always people who specialize even further and know way more about them than I do. The trick is to spend as much time learning from these people as you can. I talk with my direct superiors at work a lot, because they're both insanely knowledgeable engineers. I also have some buddies that do full-time marketing, copywriting, design, etc, and each of them are constantly teaching me things. Make a point to regularly associate with a wide variety of deeply specialized people, and as a result, while you'll probably never be as effective as any of them in their given fields, you'll certainly be way more effective than most people. From there, pick one or two fields to use as anchors for your T (or W) shape, and then leverage that in your dealings with other fields.

Think of yourself as a pupa. Right now you're just incubating, you don't have to do anything fantastic, just learn and grow. Then, when you're ready, you'll break out of your shell and spread your wings :)

</comment><comment><USER5> Of course, you can learn most of those things. However, it is my belief you will soon tire yourself. Getting to the top of everything is hard enough, staying there even harder.

I used to be up to date in a lot of domains. 3D modelling, app frameworks, web technologies, back end, front end. Those days, I find it's hard enough to focus on being up to date and relevant with front end web development while balancing an healthy life with friends and family.

You can do it, but remember that there is an upkeep to being relevant in a lot of domains. If you can deal with it, sure, go ahead!

However, what I would recommend you is a good team. I'm finding I connect easily with people that have complementary skill sets to mine, and it's a great experience.

<comment><USER6> Where did you find these people?

</comment></comment><comment><USER7> I don't think its unrealistic - the bar is just very high for what you want to do. Perhaps it may make sense to talk to people who would be looking for such an integrated skill set and find out which ones matter more than others and to what degree/level.

That will give you an automatic prioritization of how to go about getting these skills without becoming overwhelmed.</comment>


The best version manager I've found so far - <AUTHOR> https://github.com/asdf-vm/asdf <comment><AUTHOR> I replaced `rvm` (ruby) and `nvm` (node) for `asdf`. It also manages multiple versions of Java!

<comment><USER2> I used to use nvm on my last machine. How are you finding asdf? I seem to remember nvm has a bit of a startup cost. Is asdf quick/instant?</comment></comment>


50% of iPhones Brought to Genius Bar Have Never Been Synced - <AUTHOR> http://www.macrumors.com/2011/06/13/50-of-iphones-brought-to-genius-bar-have-never-been-synced/ <comment><USER2> syncing is a massive PITA, thats why.

I just bought this new album and am halfway out the door ... but oh wait!!! I forgot to sync it to my iphone, and I really want to listen to it on my 30 minute drive to work ... now I have to go back in the house, hope that my iphone shows up in itunes when I connect it (on windows sometimes you have to restart your computer for this to happen) then select the album and hit 'sync' which takes another couple of minutes.

oh joy.

Then have you ever gotten your phone/ipad played with it, installed a few apps, downloaded some books before finally connecting it with itunes, only for Apple to tell you that its about to to wipe out all the apps on your phone since its a new device and you downloaded all those apps before your first sync?

Yeah ... lets just say the number doesn't surprise me.

<comment><USER3> After using Google Music on my Android, and the rest of Android's excellent syncing capabilities, I don't think I could ever use an iPhone in its current state simply because syncing with iTunes is an absolute burden.

To elaborate, I heard a really cool song at my friends house the other day and wanted to listen to it on the road home (long trip). So I start up LogMeIn on my Nexus S, remote into my pc and quickly download the album. Once the album finished downloading, Google Music picked it up and started to upload it to its own service. In less than 5 minutes, and over 250 miles away from my home PC, I had this particular album on my phone ready to be played on my car stereo. That to me is absolutely incredible, and I think it really highlights where Apple is starting to fumble with the iPhone in comparison to some of Android's features.

<comment><USER4> Ease of use? You forgot the part where you had to remote desktop into your home PC to download the music. iPhone users have had a functional music store on their phone since 2007.

<comment><USER5> It was a bad example. Amazon MP3 Store downloads straight to the phone.

<comment><USER6> What's a good example, then? iOS devices can directly download music, apps, videos and books. There are few reasons it ever needs to be tethered, backing up being one of the big ones.

This isn't to knock Android's current OTA syncing, nor to say I'm not looking forward to iCloud. It's merely to point out that today's iOS isn't really that far behind Android as far as the customer experience goes. The only area where I see Android's experience as being superior is the case of a customer buying an app on their computer and sending it directly to their Android device.

The reason why Apple Store Geniuses are so excited for OTA iCloud syncing is mostly for the OTA backups – if every iOS customer is automagically backed up to iCloud, they can do a device swap without taking the time to backup and restore in-store.

</comment></comment></comment></comment></comment><comment><USER7> Original: [http://onefps.net/post/6496478249/50-percent-of-iphone- owner...](http://onefps.net/post/6496478249/50-percent-of-iphone-owners-dont- backup)

That.. doesn't make total sense unless these people aren't using their phones either. According to one analytics company iOS 3 has been virtually eliminated.

[http://insights.chitika.com/2011/just-in-time-for- ios-5-ios-...](http://insights.chitika.com/2011/just-in-time-for- ios-5-ios-3-almost-dead/)

To upgrade you need to plug in your device and sync. Not to mention you generally need to sync to put music on the device.

Something is fishy about this rumor. Are the only people going to the Genius Bar recent purchasers?

<comment><USER8> To clarify ansy's post, the only iPhone that was released with iOS 4.0 installed by default is the iPhone 4.0. The only way to perform an OS upgrade with the iPhone is to do a device sync. If iOS 3.0 has been mostly eliminated, that means that the iPhone 4 must command at least 50% of the iPhone market -- probably much more. Given the amount of iPhone 3GSs that I regularly see, this seems a little far-fetched to me. Thus, someone's information is wrong somewhere.

<comment><USER9> Among my users, the iPhone 4 accounts for 61% of all iPhone devices active in the last 30 days. iPhone 3gs is 31%.

<comment><USER8> That's fair -- my anecdotal evidence isn't very scientific.

</comment></comment></comment></comment><comment><USER10> Luddite here: I hate syncing my phone. It freezes my computer. It freezes my phone. Apple tries to install new stuff that may or may not work etc etc etc. I just find it very unfun to sync my phone.

<comment><USER11> I avoid updating iTunes because every time I do Apple has introduced some new gimmick that's taking another 256mb of ram and making it less useful to run in the background. On my netbook I can barely use iTunes and open a Google Doc because the scrolling causes the music to stutter. I've actually started using WMP when I have a lot of work to do in Docs as it's the only way I'm not hearing stammering music.

Strange how the only thing I've changed on my netbook in literally a year is iTunes and it never used to pull this shit before that Genius and DJ thing appeared.

<comment><USER12> iTunes, even on my macbook pro, is a pig. It ends up eating 99% of my CPU, and requiring a force-quit almost every day for me.

What happened, Apple? I get that iTunes is trying to be a million things, but _why_?

<comment><USER13> The best thing they could do is enhance playback from the Finder a little bit, so you could play not just one track but a whole 'folder'/album. Maybe you can do this on Lion.

iTunes is an abomination at this point. I prefer using Spotify even just for local files.

</comment></comment></comment></comment><comment><USER14> Unfortunately, none of these people will use iCloud until they buy a new phone, since they're even less likely to be updating the OS.

<comment><USER15> Speaking of that, I'm wondering how iOS version updates gain market share so quickly if 50% of them never sync?

[http://www.readwriteweb.com/mobile/2011/01/what- percentage-o...](http://www.readwriteweb.com/mobile/2011/01/what-percentage- of-iphone-owners-are-on-ios4.php)

<comment><USER16> My guess is that the typical iPhone user who frequents a genius bar is a recent purchaser unfamiliar with the equipment, and there haven't been that many major updates out since they bought their phone. Over time, I'd assume that people would be less likely to need to go to the Apple Store for support. There is also the fact that iPhone sales are growing year-to-year and quarter- to-quarter, further increasing the representation of recent purchasers.

</comment></comment></comment><comment><USER17> I've had my phone for over a year and I never knew what it meant to sync the phone until I read the article and discussion today.

I've rarely even turned on my computer at home since I got the phone; consequently, 99% of my browsing is done on a mobile device.

<comment><USER18> someone in our shared office never connected her iPhone 3GS with her computer. She was still running 3.2.1 until I helped her to upgrade to 4.3.3.

<comment><USER19> 3.2.x was never released for iPhone. It was an iPad-only release. That said, I get what you're saying.

<comment><USER20> Probably meant 3.1.2, which is what I'm still running on my 3G, because the jump up to 4.0 was so painfully slow.

</comment></comment></comment></comment><comment><USER21> I backup my parents' iPad on a monthly basis and apply any OS updates. They only sync when they want stuff they can't get directly on the device itself (via say, iTunes, Netflix or Youtube), usually music.

If I'm not around, no sync/backup occurs. Totally believable that some folks have never done it.

</comment><comment><USER16> This figure might be useful if we knew how long the average Genius Bar customer has had their phone. If the average is two weeks, then it's not all that impressive.

</comment><comment><USER22> I am probably like many in that I have one cable for my phone and it is in my bedroom where I charge it, whereas I use my computer in another room. This makes syncing inconvenient. Additionally, everything but new iTunes content arrives wirelessly and iTunes on the phone doesn't announce new content is available on the computer, there is never anything "missing" on the phone.

</comment><comment><USER23> What about accounting for the massive selection bias of people who would actually visit the Genius Bar in the first place and combining that with the total number of people who visit the Genius Bar with their iPhones at all. I am guessing the number represents a tiny fraction of total iPhone users.

</comment><comment><USER24> I remember I synced my iPhone the first day I got it, uploaded all my music, and then never plugged it back into my computer for the next month. One month later, it crashed for some unknown reason, and I had to re-add 110 contacts by hand. Absolutely brutal.

<comment><USER25> Why would you ever add contacts by hand? Just make sure they're in your address book and sync away.

<comment><USER26> Presumably he had added those 110 contacts over the last month.

</comment></comment></comment><comment><USER27> I rarely sync my iPhone because the laptop I'd used to set up my iTunes with is a 6 year old POS(and I don't mean cash register.) It takes several minutes to launch iTunes and up to 2 hours to sync(excluding the time to download any updates.) Now, I only sync when there's a major update to iOS and even then, it's an all night process. I'd transfer my stuff to my new MacBook but I don't have a flash drive big enough to handle everything. More than likely when Lion comes out(and I get it because I want the bugs worked out before I take the plunge) I'll migrate everything, but since Apple no longer does that when you get a new Mac, it hasn't been a priority for me.

<comment><USER28> I am assuming you have ethernet running to both? Share the iTunes folder, copy it over the network, simple.

How do you think the Lion migration is going to work?

</comment></comment><comment><USER29> It does not surprise me, Same with Android, I bet > 50/75% of people who have bought Android does not know its Google/Android and hav'nt downloaded a single app

<comment><USER30> Yup, but they don't _have_ to.

<comment><USER31> Neither do iOS users. What is your point?

</comment></comment></comment><comment><USER32> Wow, personally I couldn't live without the smart playlists.

EDIT: Would whoever downvoted me care to explain why? Not syncing = not using iTunes smart playlists (perhaps better described as rule-based auto playlists). This is a major feature to me. Clearly without syncing a lot of people don't even try this feature out. Seems a shame. I know not everyone would be of the same mind, but that's not the point.

</comment><comment><USER33> If you purchase music from iTunes on your phone, then sync, it'll wipe out your music more often than not.

Hence, people avoid doing this.

<comment><USER4> Not true. The default behavior is to sync purchased apps, music, and books from the device back to the computer.

<comment><USER34> It's opt-in (you have to read and confirm an iTunes dialog box) which disqualifies it from being a default.

</comment></comment></comment><comment><USER35> I know someone who never syncs, and the real missing feature that isn't even in iOS 5 is a way to organize your photo roll on the camera. No way to create folders or add captions. iOS 5 adds basic enhancement stuff, but none of the other features you need to really replace iPhoto.

</comment><comment><USER15> Back when I owned an iPhone, I used to sync it every other day. Since I switched to Android, I sync every few weeks. Software geared towards syncing versus software geared towards cloud services; it's all about how the OS is designed.

<comment><USER15> I guess a better explanation of my point is: This surprises me, because it's iOS. If it were Android, I'd be surprised if 10% of people connected their phones to their computer ever.

</comment></comment><comment><USER36> I've never synced my iPad at least. When I still used an iPhone, going from Bluetooth sync I had used between my Mac and various Nokia phones for many years to wires and iTunes felt like a really big step backwards.

</comment><comment><USER31> Did anyone else assume the HN community was made up of people who aren't incompetent until now?

I'm not defending iTunes' current direction, but honestly. The sheer number of people so intimidated by their phones & iTunes that they just bypass the whole mess is very sad. If you can't spend all of 5 minutes figuring out how to sync the device you bought, then I seriously wonder why you are browsing a site like this.

iTunes & the sync model is a little convoluted for your average user, but c'mon guys. Step it up a little. If you can't figure out how to sync your iPhone without wiping it, please close your HN account ASAP.

<comment><USER37> It's not cause it's hard. It's because it's a pain the ass

<comment><USER31> It's really not, though. That's a good reason to not sync regularly, there is no excuse for being an HN member and not being able to sync at all without wiping the device.

<comment><USER37> Again, you're assuming "can't" instead for many of these people it's "Why would I waste my time syncing".

I have _more apps than fit on many of my devices_ for instance. I have iPad and iPhone versions of the same apps in many cases.

Syncing only turns into pain as it's a pain to get exactly what you want on each device when you have a few hundred apps to go through.

All of my contacts and really anything important is in the cloud. All pictures are copied off from a program that doesn't suck, etc.

It's free and easy to just install the few apps I want on each device through the store.

</comment></comment></comment></comment><comment><USER38> Phones need syncing? Whenever I log into a new Android phone, I get all my apps, calendar entries, contacts, etc. I didn't realize there was any other way.

</comment><comment><USER39> My gut doesn't believe this. I imagine the apple purchasers buying the apple experience. This seems very odd.

</comment><comment><USER40> 50% does not tell us the whole story. We need absolute number to make sense of this data.

</comment><comment><USER41> my mom asked me the other day what the word 'sync' meant. Honestly. To some it may be an alien word in the context of their devices/data.</comment>


One Woman's Drive to Revolutionize Medical Testing - <AUTHOR> http://www.newyorker.com/magazine/2014/12/15/blood-simpler

<comment><USER2> Elizabeth Holmes is a driven, effective leader in laboratory testing using small programmable instruments that test for multiple conditions at the same time.

Since there is no mention in this article about the technology that is used, I wonder if a language like Erlang would be effective in running such an automated instrument?</comment>


Canviz: Graphiz on Canvas - <AUTHOR> http://www.ryandesign.com/canviz/ The source is available here: http://code.google.com/p/canviz/ <comment><AUTHOR> The source is available here: <http://code.google.com/p/canviz/>

</comment><comment><USER2> important to note that this does not do any layout, it uses the intermediate .gv format, which has been pre-processed by graphviz.

<comment><USER3> If the .gv compilation was in javascript, it would be a complete solution. That's a project i'd be willing to commit some time to.

<comment><USER2> noble goal, i think it could be done, however, the layout is the thing that is the most computationally expensive, and really the magic of graphviz. there are other programs that can do this, and there are a lot of js/as layout things out there. a quick google brought up a force-directed graph with javascript [http://www.kylescholz.com/blog/2006/06/force_directed_graphs...](http://www.kylescholz.com/blog/2006/06/force_directed_graphs_in_javas.html)

<comment><USER3> That's a neat graph engine. I'll look into it and see if I can use something like that. Thanks.

</comment></comment></comment></comment><comment><USER4> Nice. I've been wondering how graphviz stuff has been going... I pulled the source a while ago and nearly ran screaming o_O This is a lot smaller & cleaner.

On a side note, anyone know a good source to learn how to port graphviz? Or, what parts are relevant and what aren't? Though I suppose this serves as a starting point.

</comment><comment><USER5> Why use Canvas over SVG for this? Is browser SVG support that bad?

I don't mean the to diss the project, it just seems more appropriate to use vector graphics for this.

<comment><USER6> The canvas API is vector graphics. The distinction is between retained (or "scene graph") and immediate mode APIs, not between vector and raster. And that's sort of an issue of taste. Some things are easier to code one way, some the other.

</comment></comment><comment><USER7> About time! I've just been too lazy to port it myself. Thank you very very much!</comment>