Ask HN: Review my status board startup - <AUTHOR> Geckoboard launched into private beta last week.  It's very much a minimum viable product in that it's a functioning product but there's still lots to do.  It's bootstrapped by me with the design and development outsourced to companies in the UK and Belarus respectively.
Geckoboard is SaaS status board that uses other services' APIs to collect and summarise key business information and display it in a way that's easy to understand and interpret.
Data from web analytics, server monitoring, project management, email marketing, CRM/helpdesk etc shown together on one dashboard to give a near real-time status on the health of all aspects of your business.
At the moment we integrate with about a dozen different API but more are being worked on right now and even more on the backlog.  I'd love to hear your thoughts and/or suggestions.
EDIT.  Signup instructions: We're in private beta but you can bypass the private bit by using the invite code "HN" on the signup page (don't include quotes). Link: http://geckoboard.com <comment><USER2> I'm trying to add a Google Account for my Apps email, and the oAuth connector seems to be broken.

Here's the output:

Fatal error: Uncaught exception 'OAuthException2' with message 'Request failed with code 400: The token is invalid. ' in /home/geckoboa/public_html/system/libraries/oauth/OAuthRequester.php:125 Stack trace: #0 /home/geckoboa/public_html/system/models/gmail.class.php(195): OAuthRequester->doRequest(0, Array, Array, Array) #1 /home/geckoboa/public_html/system/controllers/oauth.class.php(76): GmailModel->getAccessToken(Array, '4%2FUvLUOZSga3M...', 'CVoQvrifDsxjv%2...') #2 /home/geckoboa/public_html/system/base/controller.class.php(82): OauthController->response() #3 /home/geckoboa/public_html/system/base/base.class.php(80): Controller->execute() #4 /home/geckoboa/public_html/system/base/base.class.php(50): Base::routing() #5 /home/geckoboa/public_html/index.php(21): Base::createWebApplication('/home/geckoboa/...') #6 {main} thrown in /home/geckoboa/public_html/system/libraries/oauth/OAuthRequester.php on line 125

This is on Snow Leopard and Firefox 3.6.6

<comment><USER3> Broken for me as well on Chrome. I was going to report this but I thought I saw a ticket on your site for it already. I'm guessing GMail and Google Apps Mail behave differently with OAuth?

<comment><AUTHOR> That's exactly it.

</comment></comment></comment><comment><AUTHOR> We're in private beta but you can bypass the private bit by using the invite code "HN" on the signup page (don't include quotes).

Link: <http://geckoboard.com>

<comment><USER4> Hmm, I'm getting a "Invalid or expired invitation code" error - did you cap the number of new accounts?

</comment></comment><comment><USER5> This is great! I had some penned out drawings of something like this but never really took it anywhere. As a developer what I would really like to see is some GitHub/Google Code integration - I want to know when a commit is pushed etc.

Some other ideas:

\- RSS feed block

\- "Pings" - when a block is updated flash it yellow and fade to the original colour over 5-10 minutes.

\- "Workspaces" - separate dashboards that suit different uses, for example a build indicator, site-status and other monitors on one, support requests and tweets on another.

\- Custom components - having a developer ecosystem would top this off.

I could see myself using this on a spare monitor or TV if some more components were available.

<comment><USER6> Yep this is pretty funny because I seriously considered working on this idea too and had a decent chunk of code written before moving on.

Your implementation looks great though. Do you mind if I ask what you used to built the UI? It looks great, transitioning etc.

Also +1 on the GitHub integration.

</comment></comment><comment><USER7> create a demo site. personally i wouldn't start entering passwords before having seen a demo and being convinced that it'll be useful.

also a votebox (as in dropbox.com/votebox/) to suggest widgets would be nice.

<comment><AUTHOR> Demo site is a good idea - thanks!

We have a feature request forum where users can vote on ideas submitted by other users. <http://geckoboard.zendesk.com/forums/176685-feature-requests>

<comment><USER8> If you were feeling bold you could create a demo site that displayed stats of the app itself!

</comment></comment></comment><comment><USER9> Great work,very slick. Out of interest, can you provide any information about the system architecture?

Things i noticed:

* do you really need my pingdom password? * drop-down in pingdom setup process does not work on the iPad (can see the options, but cannot scroll) * I wasn't really clear on what the fields did on the last stage of the pingdom setup process * The text in the text boxes could do with being lighter, it doesn't really have enough contrast in comparison to the background and is hard to see * I am asked to choose the size of the widget without really knowing what is going to be appearing in it. I do nit have enough information to make the decision. Maybe always make the small type, with the option to enlarge later? Would shorten the process a little * nice work on the 2-step signup (getting my email then asking for the other information once the user has brought into the process)

Anyway, great work! We hope to be in your position soon with our startup, <http://playnice.ly> </shamelessplug> :)

<comment><USER9> Sorry about the formatting there! Those were supposed to be bullet points

</comment></comment><comment><USER10> You need to go a bit deeper on Google Analytics. I can't get trendlines, just numbers, and no ability to see goals. (This probably goes for a lot of analytics packages, but we're using GA.)

Also, Flowtown and Wufoo would be nice - I believe they both have Webhooks, so it shouldn't be that difficult to add.

That said, this is exactly something I've wanted for quite a while; congrats!

<comment><AUTHOR> Thanks for the feedback. We're purposefully shying away from trend lines and analysis at the moment and only showing high level summary information that's useful for right now. We don't want you to have to interpret, just to see what a current snapshot of your business is.

I liken it to the dashboard of your car; if you have access to your key numbers you can see any problems straight away:

      going over the speed limit?
      oil pressure too low?
      how many miles have I done this trip?
      are my servers up?
      do I have a ton of outstanding support requests?
      have visitors to my site this week jumped suddenly?

I'm all for analysis and agree it's an essential function of almost any business but there are lots of products that can help you with that (see <http://metricly.com> for an excellent example), but that's not what Geckoboard is for.

</comment></comment><comment><USER11> Very nice UI. One big improvement could be a small graphic with instruction when you get to the blank dashboard. At the moment it's looking a bit empty at first impression (and that matters!)

Maybe provide a desktop version which is just a shell for the online site? That is, using AIR or Prism or other?

Good luck, it looks like a great product.

<comment><AUTHOR> Agreed - user communication and flow management is lacking at the moment.

Hadn't considered a desktop version until now. What benefits does it bring over and above the web app do you think?

<comment><USER11> Webpage tabs get closed, open, closed.. if this is actually updating all by itself throughout the day, I could see value as running it like a desktop app.

The cost is minimal (to make a prism version for example) and it takes 0 maintenance, and some users which are not uber-geek enough to make their own desktop version might see it as a big plus. "And it run on desktop too? Cool".

Also I could see it running a "public version" on a television hooked on the wall for everyone to see the web app live. Just a thought.

You seem to have all your features coming along, I just wanted to bring my 5c :)

Have some fun.

<comment><AUTHOR> Thanks for clarifying this. I'll certainly give it some consideration.

</comment></comment></comment></comment><comment><USER12> It's beautiful. Great job!

It definitely needs those additional API's. And could you offer a simple full list of all the widgets upon signup, where you could checkbox the ones you want, instead of hunting one-by-one in a dialog? It would make it easier to get started.

But I would definitely use such a service. That'll do pig!

<comment><AUTHOR> Yes, we could certainly use something to make things easier to configure your initial dashboard. Thanks for the feedback.

</comment></comment><comment><USER13> I had the exact same idea. When I saw panic's dashboard, I thought "Man, If I could make a script to do that for everyone, that would be awesome"

Granted I wanted to release mine as open source. Congrats man, It looks awesome :)

See if you cant find a way to get server uptime in there. Maybe with a script we throw on our server.

<comment><AUTHOR> Thanks for the compliments. I loved the Panic status board, just fantastic.

If you have a Pingdom account you can display your server uptime from there right now. Otherwise, we will be implementing a "reverse API" for custom data and external services to push data to your dashboard at some point in the future.

</comment></comment><comment><USER14> Oh, this is fantastic. I can definitely see myself using this, thanks!

One quick note: On the Beta sign up form there's a misspelling: "Acount" instead of "Account."

<comment><AUTHOR> Thanks for the catch!

</comment></comment><comment><USER15> UI suggestion:

I'm in the "add widget" pop-up. Currently, I select a widget, then have to hit the green "select widget" button. I think that step could be eliminated? I actually went through the different service categories on the left, and for the ones that I wanted, I just clicked on the small gray box, and once I got the green dotted highlight, I thought that I had maybe added the widget.

Not a big deal. Just a thought.

<comment><AUTHOR> Thanks for the suggestion and sorry the instructions aren't what they should be. We'll address both.

</comment></comment><comment><USER16> This is really slick & feels especially solid, especially given that it's an MVP.

I'd love to see Clicky integration.

Also, thoughts on pricing? Flat rate, per widget, other?

<comment><USER16> Also, Buffalo didn't happen to design it, did they?

<comment><AUTHOR> That's 2nd vote for Clicky.

Yes, Jason from Buffalo designed it (I've credited him elsewhere in this thread). He totally got it and did an amazing job IMO.

</comment></comment></comment><comment><USER17> 5 second review:

I visited the site, read the headline (good job there), and then clicked the thumbnails to see larger images of the status board. It is very confusing that some of the images are snapshots of panels with an X in the upper right hand corner, but you have to click off the picture for it to close. Maybe make it so any click closes the picture?

<comment><AUTHOR> Yes, that's annoying. I glossed over this in testing but I'll make sure it's seen to.

</comment></comment><comment><USER18> I'd feel a lot more comfortable if I knew what you were doing with my Pingdom password (e.g. securely storing it), and if you used an input type="password" when entering it.

Also, I'd would be cool if I could choose to show only stats from Gmail with a certain label. That way I could show stats about unanswered ticket/support emails.

<comment><AUTHOR> I totally understand and appreciate your concerns and I hope to re-assure you that your authentication details are being stored encrypted as per industry standards.

User privacy and security is of utmost importance to us, without trust we're dead in the water. Where there are options to use OAuth we only use OAuth, and for each API we aim to use the strongest possible storage solution.

We don't allow you to change connection details for an account meaning that if someone gained access to your dashboard they would not be able to see your connection details.

We can certainly change the input box to a password type to reduce the risk from over-lookers. We'll put it in the next drop.

Please let me know if you would like to discuss any of this in more detail.

</comment></comment><comment><USER19> Any reason why I can't sign up with my real name (which contains non-ascii characters)?

Come on! It's XXI century.

<comment><AUTHOR> No reason other than an unacceptable bug. I'll make sure we fix this and please accept my apologies.

</comment></comment><comment><USER20> I really like this idea and the look and feel/usability of the app. I like it so much that it would be homepage if it had the metrics I needed, but it doesn't have them right now.

Here are the stats I want to see: 1) MailChimp - it only has campaigns. Right now I am more interested in seeing the number of people on a certain list 2) FeedBurner for my blog's RSS feed 3) Karma for various sites where I am active (like <http://duckduckgo.com/karma.html>) 4) For twitter, I want to see number of tweets, replies, etc, not rotating tweets 5) Bit.ly (not sure if the API lets you do that though) 6) UserVoice

</comment><comment><USER21> Care to list which APIs you integrate with? Just to decide if I want to check it or not

<comment><AUTHOR> Sure, this ias the list as it stands today. More APIs are being developed as I speak.

      Basecamp	Project Management
      ChartBeat	Web Analytics
      Clock
      Email
      Get Satisfaction	Customer Service
      Google Analytics	Web Analytics
      Highrise	CRM
      MailChimp	Email Marketing
      Pingdom	Server Monitoring
      Prefinery	Beta Management
      Text	Custom Alerts and Messages
      Twitter	Social Media
      Zendesk	Customer Service

Edited for formatting. Edit 2. Removed Calendar from the list, it's not quite ready yet.

<comment><USER19> Any chance for adding own data through REST api?

I'd be nice to see output of my custom monitoring daemon sent as JSON to your service and displayed in the Dashboard.

<comment><AUTHOR> This is a big thing for us and something that will definitely be included. We're working on a design for that at the moment and I hope it won't be too long before we can include it.

</comment></comment></comment></comment><comment><USER22> This is beautiful. I've just played with it for a few minutes. Only comment so far is have defaults wherever you can, instead of asking the user to fill in a value. For example, "label" for the email widget can be "email" as default instead of blank, so that it doesn't fail when i just want to add it quickly. I can always edit to relabel it. In a similar way, you could probably reduce the number of clicks it takes to add a widget.

Fantastic idea and pretty good execution so far. All the best!

</comment><comment><USER23> This would be absolutely huge if you integrated with other affiliate networks(especially Linktrust and DirectTrack API). I know a lot of affiliates who would pay good money to have all of their stats in one place. Your major competitor would be statsjunky.com, which is an expensive desktop based crap tool.

</comment><comment><USER24> Do you install this in the local network and tie into the Apps people use, or do you run this as a cloud service?

<comment><AUTHOR> It's a cloud service at the moment. I have no philosophical objection to it being self-hosted and it could be something we look to in the future but no plans yet.

We're working on a design for a reverse API to allow users to plug in their custom data.

</comment></comment><comment><USER25> This looks fantastic, congratulations!

You might want to remove this weirdness at the bottom of the front page: "Start GOOGLE ANALYTICS<\--> End GOOGLE ANALYTICS<\--> Start CHARTBEAT<\--> End CHARTBEAT<\--> Start ZENDESK<\--> SupportEnd ZENDESK<\-->"

<comment><AUTHOR> Thank you. I figured if it was something that you were going to look at throughout the day or even put it on a large screen in the office (as one of out testers is doing) then it has to look decent.

It was actually designed by Jason Reynolds at a company called Buffalo based in Brighton, UK (<http://builtbybuffalo.com/>). I've used them before and was really happy with the result.

Thanks for spotting the "Start End" weirdness, will fix it.

</comment></comment><comment><USER26> Fantastic app! UI is particularly well done, great job.

Small number of currently present APIs definitely is a let down, but I suppose that will change soon?

I would love to have ability to create multiple "pages", for monitoring different projects - so that their widgets don't overlap.

<comment><AUTHOR> Yes - we're ramping up the number of APIs, this was just the bare minimum required to get it out there and hear what people needed.

And thanks for the multiple pages suggestion. Certainly something we'll look into!

</comment></comment><comment><USER27> I am not sure if it is possible (as my programming experience is very limited) but an API for this so, rather than continually having to provide support for other services, you outsource the development to the community!

</comment><comment><USER28> I wanted to work on something similar so I'm very curious about the pricing of this app. If it's not what I expect I might consider trying to work on it with a different approach so it wouldn't be just a copy. :)

<comment><AUTHOR> Pricing is still to be finalised. It will come from a conversation with our users. I want it to be reasonable and affordable.

</comment></comment><comment><USER29> Wonderful! This is EXACTLY what I requested in a HN post here just a month ago: <http://news.ycombinator.com/item?id=1441770>

<comment><AUTHOR> Glad to hear it. Although I have no idea how I missed your original post, sometimes I feel like I spend all of my time on this board!

<comment><USER29> as a little request, it would be awesome if you could connect to salesforce.com in some way, so we could have a widget with sales numbers

<comment><USER6> Yep - I would anticipate this sort of "leaderboard" to be a big use case.

</comment></comment></comment></comment><comment><USER30> Some weird behavior when I open a new browser and try to go to <my_account_name>.geckoboard.com. It would be nice if that went to a login page and then took me to my account.

<comment><AUTHOR> Spot on. We want you to be able to log in from here as you expected. This functionality is included in the current sprint.

</comment></comment><comment><USER31> That is awesome, both because it looks great and also because I was going to build something similar and now I don't have to!

If you could add Clicky and Recurly support I would be your best friend.

<comment><AUTHOR> Thanks! I'll add Clicky & Recurly to our feature request forum. We don't have any finance APIs integrated yet, this is certainly something we're looking to address.

</comment></comment><comment><USER32> Great Work, we created our own custom Status Board a few weeks ago but this definitely rocks. Will be using this in the near future on other projects for sure! Great work.

</comment><comment><USER27> Well done on launching! find the bootstrap/outsource combo very interesting - surely this is somewhat of a oxymoron What's your background if you don't mind me asking?

<comment><AUTHOR> No problem, I'm more than happy to share :)

It is sort of an oxymoron but it I've managed to get it working for me. My day job is as an ETL developer specialising in building data warehouses (usually Oracle) for the purposes of MI. I run my own company and contract for large multinationals mainly in the financial sector in the City of London and usually on 6 month contracts. I don't get a lot out of the job except the cash so I've always developed other things on the side

I started building apps that scratch my own itches about 6 years ago. Sometimes I'd develop myself and sometimes using external help sometime a combination of both. I don't spend a lot on luxuries and so the income I make in my day job has allowed me to roll the dice with a few larger ideas in the past but nothing really took off.

As soon as the light went on about this idea I wanted to do it right and put aside a certain amount of money to get it where it is today - I know enough to make me dangerous but wanted a proper job done so outside help was essential and I had built up a certain amount of cash since my last project. I don't have limitless resources but by my calculations I have enough to continue the push until it starts making money with some contingency, development continues full speed.

Let me know if you would like to know any more.

<comment><USER27> What was your motivation for getting it done right from the start, rather than bootstrapping it yourself first for proof of concept/profitability? time constraints?

Obviously you have made some assumptions as to how long profitability will take - something I presume only comes with experience.

Not to over step my mark, but what magnitude of savings is needed to fund this sort of development? I ask this as I have recently started work on my own project, and am curious if my savings are even ballpark to consider outsourcing it.

</comment></comment></comment><comment><USER33> Anyone have a metricly.com invite code that was mentioned in some of the posts below? Would like to compare to the dashboards mentioned here.

</comment><comment><USER34> Wow, great work on the MVP. I'd like to see PivotalTracker and Chargify added to the widgets down the line. Overall amazing job.

<comment><AUTHOR> Thanks! I'll add both of those to the feature requests forum. We're actually using PT for Geckoboard development so it would be useful for me too!

</comment></comment><comment><USER35> What did you make the UI in? looks really nice.

I find the text really hard to read when configuring a widget.

Also, uservoice support :)

<comment><USER36> Wanted to complement you on the design as well, looks really nice! Just one issue, the background is flickering on my Laptop's screen (Lenovo T510i). No of to explore your solution some more.

<comment><AUTHOR> Thanks, although full credit for the design has to go to the designer Jason from <http://builtbybuffalo.com/>

We'll look into the flickering, could be to do with the repeating background image.

<comment><USER15> Just wanted to let you know that I'm getting a flickering on my laptop as well, a MacBook Pro, using Firefox 3.6.6.

</comment></comment></comment></comment><comment><USER37> Do you mind sharing who you outsourced development to and how you went about finding a developer?

</comment><comment><USER33> Your los angeles time conversion in your clock widget is incorrect, it is one hour behind.

Fantastic idea and UI

<comment><AUTHOR> We're working on daylight savings support right now, should be there soon.

Thanks!

<comment><USER33> No problem was just trying to help. I really like it and I hope you add on more key google analytics indicators like conversion rate, number of sales, etc.

<comment><AUTHOR> Cool - thanks for the feedback! Feel free to drop me a mail (email in profile) or add something to out feature request forum at <http://geckoboard.zendesk.com/forums/176685-feature-requests> if there's something you would like to see.

</comment></comment></comment></comment><comment><USER38> Great work!

I would probably start using when Aweber, ActiveCollab, Feedburner and HyperTracker are supported.

</comment><comment><USER39> Bug note: The "What is this?" button doesn't work

Mac OS X: 10.6.4 Chrome: 5.0.375.99

No errors in Javascript console, sorry

</comment><comment><USER40> Did you decide to limit signups by making the buttons invisible in Internet Explorer?

</comment><comment><USER41> Really nice. Needs plugins, so my specific business needs can also be aded.

<comment><AUTHOR> Looking forward to hearing what you need so that it works for your business. We have a fairly lively feature request room over at our help and support forum (<http://geckoboard.zendesk.com/forums/176685-feature-requests>) or feel free to shoot me a mail (see profile).

</comment></comment><comment><USER8> This is way too pretty to be a minimum viable product - great work!

</comment><comment><USER42> Reminds me a bit of metricly.com.

Any plans to include Google AdSense stats?

</comment><comment><USER43> Amazing app. Need more plugins/custom APIs.

</comment><comment><USER44> looks cool so far. one little bug: mail adresses with a + are dedected as invalid, they are not.

<comment><AUTHOR> Thanks, I'll make sure this is addressed.

</comment></comment><comment><USER45> I'd like to see GitHub integration.

<comment><AUTHOR> Me too, we're hoping to get this in soon

</comment></comment><comment><USER46> rss support like the twitter-ticker would be nice as a basic need for a system like this...

</comment><comment><USER47> looks great. What was the inspiration?

<comment><AUTHOR> Discussions here about status boards and, of course, Panic's internal status board.

</comment></comment><comment><USER48> I know this isn't going to concern you TOO much, but I thought I'll add my comment anyway.

I'm on a Fedora X86_64 box running Firefox 3.0.11 (with no flash, but I don't think your site needs it anyway), and whenever I click the "Add a Widget" button, I get an error.

I provided the browser/OS details to help narrow the problem.

The screenshots make it look like it'll be a great app. Congrats on getting it out there.

<comment><AUTHOR> I'm pretty concerned about this and would love to dig into it a bit more. Could you mail me paul at geckoboard.com with the error message and/or any other details and I'll look into it straight away? You're right - you don't need Flash.

<comment><USER48> Email sent.

Cryptic Subject: Error details.

(So check your spam)

</comment></comment></comment><comment><USER49> This is awesome! I will definitely be using this.</comment>


Federating Internet search - <AUTHOR> http://oei.yungchin.nl/2009/06/14/federating-search/

<comment><USER2> What about Dogpile? (<http://dogpile.com>)

<comment><AUTHOR> I guess that solves half of the problem - allowing you to compare results between engines should keep them "honest".

But the barrier to entry for a new engine would remain as high, or?

</comment></comment><comment><USER3> So, do we get around the server costs by daisy chaining? Your search front end queries a few search providers, which mix their own content with the cached results from a few others, and so on.

</comment><comment><AUTHOR> (This is my own, in case that wasn't already very clear... I hope for forgiveness on the basis that it's not totally rubbish)</comment>


My Heroic and Lazy Stand Against IFTTT - <AUTHOR> https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_against_ifttt/ <comment><USER2> > 11\. Compatibility. Each Licensee Channel must maintain 100% compatibility > with the Developer Tool and the Service including changes provided to you by > IFTTT, which shall be implemented in each Channel promptly thereafter.

> 17.This Agreement is personal to Licensee and may not be assigned or > transferred for any reason [...]. IFTTT expressly reserves the right to > assign this Agreement and to delegate any of its obligations hereunder.

Any developer signing this agreement is nuts.

<comment><USER3> I'm surprised that a majority must have signed already, for them to actually make the switch.

Hopefully this costs them a lot of buisiness and they have to revert.

<comment><USER4> The author noted in the comments that nobody signs it, it's a passive "By using our developer site you agree.." agreement.

<comment><USER5> Are those even enforceable?

<comment><USER6> Do you have the funds to defend yourself in such a lawsuit?

</comment></comment></comment></comment></comment><comment><USER7> _If you 've never heard of it, If-This-Then-That is a service that lets you connect websites together, so that things that happen in one place automatically trigger some regrettable action someplace else. For example, you might write an IFTTT 'recipe' that tweets anything you post on Facebook, because you are a monster._

I'd heard of it (I may have even signed up with it at some point), but this has to be the best explanation of IFTTT I've come across.

<comment><USER8> Maciej is a fabulous writer with a deft mix of wry, self-deprecating wit and precise expressions.

If you aren't familiar with his writing, you'd likely enjoy "Dabblers and Blowhards" [http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm](http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm)

<comment><USER9> Or my favourite: [http://idlewords.com/2007/04/the_alameda_weehawken_burrito_t...](http://idlewords.com/2007/04/the_alameda_weehawken_burrito_tunnel.htm)

<comment><USER10> WTF did I just read? I think it was genius but I'm not entirely sure.

<comment><USER11> You are correct. It is genius. On the other hand...

</comment></comment></comment></comment></comment><comment><USER12> I am the CEO over at IFTTT. I apologize for any misunderstanding our communications today have caused. I built the Pinboard Channel on IFTTT and have maintained it for years. I am also a paying customer of Pinboard! I've built for hundreds of platforms and any changes to those platforms by default suck. At IFTTT, we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better. Pinboard is a beloved service. Every service is, on IFTTT or not. We care about the people who use them and build them. The changes we are asking for are indeed more work, but we know they will lead to a better Pinboard Channel on IFTTT in the long term. I'd love to see Pinboard stay on IFTTT and am willing to give them the time they need and even come over to help myself!

<comment><USER13> My hobby: role-playing how I would respond as the CEO if my company was getting skewered on HN. Here is my version!

\---

I am [not] the CEO over at IFTTT. We messed up. Big time.

Pinboard -- and other services developers love -- played an important role in our success thus far and we dropped the ball with the roll-out of our new platform. We have a shared incentive: to make channels work reliably for our end-users. To both stabilize existing channels and to allow new services to connect to IFTTT, we are publishing documention for a standard API that any new channels will need to conform to.

Going forward, we will be allowing existing channels to run on the legacy platform. Additionally, we will be reviewing our ToS to clarify out intent. We're not keen on legalese, but it is part of the game when doing integrations between third parties.

To maciej, I've reached out personally via email to apologize for the unclear messaging to our users. If you would like to give us a chance to make things right, we would be grateful and happy to help resolve any other outstanding issues.

<comment><USER14> I think your hobby could be a MVP for the first CAaaS -- CEO Apologies As A Service.

(If you act fast, Theranos could be your first Enterprise customer.)

<comment><USER15> Funny! Now for a business name... "Palms Up, Inc."? Or maybe just "Public Relations LLC."

<comment><USER16> Sorry.co....

</comment></comment></comment></comment></comment><comment><USER17> I agree that this is dumb of IFTTT.

But I am all in favor of a 'recipe' that consists of "startup does dumb stuff=>Maciej writes a hilarious takedown=>I LOL so hard people ask me what's going on from two rooms away". Can someone implement the API for that, please?

<comment><USER18> Comedy is one of the great things in life that just wasn't meant to scale.

<comment><USER19> Deep man, deep...

</comment></comment></comment><comment><USER20> I hadn't seen Botize before. In structure and capabilities, it looks a lot more promising to me than either IFTTT or Zapier (for instance, it supports maintaining lists and adding/selecting data from them), except that half the site seems to be localized to Spanish and doesn't seem to have an option anywhere to change the site language.

<comment><USER21> I think it's just some fellow in Spain who's about to have a really busy week.

<comment><USER22> If memory serves that's pretty much how pinboard.in got launched into the air a few years back, so it'd certainly be poetic. Nice of you to pass it on :)

</comment></comment></comment><comment><USER23> It would be easier to support IFTTT on this if the proposed APIs to be implemented were public. But making the APIs private and then being a dick about it with all the legal threats isn't something that I can reasonably support.

I doubt I'm alone in thinking this way.

<comment><USER12> We fully intend to make the APIs public, but are working with existing partners to implement. We are trying to be flexible and understanding, also are not throwing legal threats :)

<comment><USER24> So you "intent" to eventually make the APIs public but hold your partners to the gun and shut them off if they don't meet all your demands (ToS, new API dev).

What I'm hearing is you want partners to trust your intents but you don't trust any of theirs—as evidenced by the terms of service that is _required_ and binding. The "not throwing legal threats" part comes off very hollow in that context.

If you did trust your partners, you'd make a new API _alongside_ the current setup, and it would be so awesome that people would switch on their own. But as others already pointed out, it seems the value in the new API is self- serving and is inexistent for your partners.

I'm all for collaboration but I suspect you are trying to build a moat around your business and make a ubiquitous platform. I sincerely hope this backfires.

</comment></comment></comment><comment><USER25> I love to support this guy. As great as the product is, his communication is even better.

[https://blog.pinboard.in/2014/11/new_pricing_policy/](https://blog.pinboard.in/2014/11/new_pricing_policy/) \- "Should I be worried? -> Only in the broadest, existential sense."

</comment><comment><USER26> I was going to integrate my app with IFTTT, but after reading this post, as well as the responses from the CEO in this thread, there is no way I will ever in a million years integrate with IFTTT.

I think its an interesting train-wreck to take note of. And it is clearly a reflection of the CEO, who has consistently misunderstood or ignored the true complaints people have about this new direction, while half-apologizing for terms and blaming "communication" on terms that place absurd expectations on companies that IFTTT chose to integrate with, and now wants to reverse the roles of.

Meanwhile, maciej is doing everything right. Communicating with his users about what is actually going on (instead of lying to them as IFTTT has done), and doing so in a thoughtful and playful piece of writing.

Time will tell how this plays out. But I think if IFTTT's moral compass is willing to let this go public, if they think this is/was an actual good idea, their days are numbered. The PR around this change alone was horribly executed, in addition to the change itself being a big middle finger. Neither speaks to an understanding of their users or sites they depend on to integrate with.

IFTTT would be NOTHING without any other services to integrate with, and they chose to throw them under the bus.

You had a chance, IFTTT. But you revealed your colors, and now you don't.

<comment><USER12> Really sorry to hear it, but appreciate the feedback. We are working to address concerns across the board regarding ToS and communication. I'd be more than happy to hop on a call to address if you want shoot me an email, my first name at ifttt.com

</comment></comment><comment><USER27> > 4\. Confidentiality You agree not to disclose (or allow access to) the > Developer Tool (or any information derived therefrom) to any third party and > will limit access to the Developer Tool (and any derived information) to > your employees who are developing your IFTTT channel. In support of this > obligation, you will apply at least the same security that you use to > protect your own most confidential information.

Did anyone seriously think this through? What about companies that have among their "most confidential information" data, like passwords, crypto keys, confidential memos, etc., that they'd never store on an Internet-connected machine?

</comment><comment><USER28> Thank you for the recommendations for replacement services. I emailed you about this - and I'm glad you publicly responded, because I smelled something weird in the way the IFTTT email was worded. Very disappointed to hear it was what appears to be pretty shady on their part.

</comment><comment><USER29> Depending on when the channel was introduced, the backend implementation of a channel can vary wildly. Some were written in Node, others in Ruby, some where written internally, others were written by the service owners.

When IFTTT released the developer platform, they were solving two needs: 1) creating a consistent channel infrastructure, and 2) providing a tool for developers to write channels so they don't have to.

It seems like they are shutting down some of their legacy services, which is probably a good plan for a company with no revenue stream. Not a good plan, however, to make it look like it is the developers' fault.

<comment><USER30> Shutting down legacy APIs may be a good idea, however the way they want to make the new API happen is completely bonkers.

</comment></comment><comment><USER31> I went through the IFTTT integration process a while back. I created a platform for indexing street art and made a service that can return nearby street art, when given a lat/lon point.

When I first got contacted about the IFTTT channel, I was excited. After realizing how much of my application endpoint I was going to need to rewrite, it became a task I kept putting on the back burner.

In my mind, the process of integration is being done well. It just requires a lot of lift for individuals who are the only developer on a project that already feels like it has a never ending list of tasks.

</comment><comment><USER32> Isn't this similar to the shit Twitter pulled on developers?

It's funny - nowadays people don't go along with stupidity like this. They just call the bluff of the business doing the strong arming and drop their support for their platform.

Seriously, if IFTTT want to force people do craploads of work for no real payoff, best of luck to them. I do hope most folks won't play along though. And those license terms? Yeah, best of luck with that. I wouldn't use them either!

</comment><comment><USER33> I applied to IFTTT about a year ago (didn't get the job), part of the interview process was to develop a channel on their developer platform. I don't consider my self a fast developer but it wasn't difficult and it took me about a weekend of casual work. Maciej is well within his rights to flip IFTTT the bird, but I just wanted to provide some context about how much work is involved.

<comment><USER21> I agree that implementing a simple API endpoint is easy.

Running that endpoint is not easy. Once it's live, you're dealing with an entangled system of API, user, network, database, server, full moon, voodoo curse, and God knows what else. It's a giant flaming tumbleweed of pain.

Clearly IFTTT agrees, and that's why they're trying to make us do it for them.

<comment><USER33> You're absolutely right. I will not try to compare what I did to pinboard. I still have the channel running on a DigitalOcean box and even though the service is simple and stable, I still have to fiddle with it once in a while. I only keep it running because it's valuable... to me.

</comment></comment></comment><comment><USER34> > The developer terms of service don't seem to be available by a public URL, > so I will quote the bits that stung me. I invite IFTTT lawyers to send me a > takedown notice, because that will be the funniest part of this fracas so > far.

Fun fact: legal language is not protected by copyright and can be copied, modified, republished, or reused.

<comment><USER35> > Fun fact: legal language is not protected by copyright

With respect: are you a lawyer?

I'm not, but all the sources I can find written by actual lawyers put this claim somewhere between 'wildly oversimplified' and 'false', depending on jurisdiction and the kind of legal language (contracts vs legislation, etc.).

Eg for US law, [0] quotes Nimmer on Copyrights § 2.18[E] as stating that 'There appear to be no valid grounds why legal forms such as contracts, insurance policies, pleadings and other legal documents should not be protected under the law of copyright.'

[0] [http://www.adamsdrafting.com/downloads/Copyright- NYLJ-8.23.0...](http://www.adamsdrafting.com/downloads/Copyright- NYLJ-8.23.06.pdf)

<comment><USER34> I am not, but I have been previously advised on this topic by lawyers who specialize in IP.

Of course, your mileage may vary and my comments on the Internet should not be construed as legal advice for your specific situation.

Edit to add: The advice I received was in the context of contracts, privacy policies, and terms of service. I don't know about, and didn't mean to include, legal language in legislation or court filings. Important clarification--thanks.

</comment></comment></comment><comment><USER36> I'd spend money on a Yahoo Pipes + IFTTT solution with some kind of guarantee they're not going to vanish overnight. You know, like a Pinboard.in style company. I think we need to clone Maciej.

<comment><USER37> What we need is a common interchange protocol, not a specific service.

<comment><USER36> I don't think you're going to get it. It's the same issue with instant messaging now. There's a business incentive _not_ to allow interoperability.

Common interchange of what, though? IFTTT's utility came through connecting disparate services - Reddit to Pinboard, Twitter to Facebook and so on.

<comment><USER38> > Common interchange of what, though?

Common interchange of schemeless data. Take data from here, put there.

Pushing JSON blobs around, essentially.

<comment><USER36> Isn't that what HTTP POST/PUT is for? GET for pull?

<comment><USER38> HTTP POST/PUT/GET are underlying primitives for these automation systems, which are essentially polished messaging buses.

</comment></comment></comment></comment></comment></comment><comment><USER39> I have to admit I use IFTTT to take an RSS feed from our kid's elementary school and post the entries to a Facebook Fan Page. The idea being to avoid having to teach my wife to use an RSS reader, now she (and another hundred or so people) get the school news without leaving Facebook.

I feel conflicted in some ways but pragmatism wins. Anyone know a non-IFTTT way to set this up?

<comment><USER40> Zapier has a published _zap_ (I hate that name...) that supposedly does just that:

[https://zapier.com/zapbook/zaps/39/share-new-blog-posts- to-y...](https://zapier.com/zapbook/zaps/39/share-new-blog-posts-to-your- facebook-page/)

I offer no personal endorsement, and have no idea whether it would work for you.

</comment></comment><comment><USER41> IFTTT has acted throughout as if they were doing Maciej a favor by letting him implement their API, which makes no sense at all. But! According to zacwest[1], the access they're offering him to their "platform" costs $3000 if you walk in off the street.

So not only are they trying to get people to do IFTTT's work for them, they're trying to get people to pay for the privilege of doing IFTTT's work for them. I'm, er, impressed.

[1] [https://twitter.com/zacwest/status/714861944465809408](https://twitter.com/zacwest/status/714861944465809408)

</comment><comment><USER42> Couldn't IFTTT just use the public APIs already offered by the sites?

<comment><USER43> That's what they're doing at the moment. I'm guessing IFTTT believe that they have become important enough to get the sites to integrate with IFTTT.

</comment></comment><comment><USER44> I want to make a correction about the patent bit. Maciej says:

> And they assert the right to patent any clever ideas I have while doing that > free work for them, even though I hate software patents:

The relevant bit of the IFTTT TOS:

> 12\. Patent License. Licensee hereby grants IFTTT a nonexclusive, > sublicensable, perpetual, fully-paid, worldwide license to fully exercise > and exploit all patent rights with respect to improvements or extensions > created by or for Licensee to the API

They're not trying to _patent_ your work, they're saying that you grant them a _license_ to any patents you might get that relate to your IFTTT integration. In other words, a developer cannot create an integration for IFTTT, patent something in there, then turn around and sue IFTTT for patent infringement. This is pretty standard language in software licenses/contracts/terms of service.

</comment><comment><USER45> Can someone elaborate more on the "Working for Free" section? I'm not well versed in IFTTT, but shouldn't I as the owner of a website that wants to offer a recipe be responsible for the details that recipe? This is all very unclear without specific examples.

<comment><USER2> The site doesn't provide recipes, it provides endpoints (API calls) that users can write recipes to use.

How it worked until now:

1) IFTTT wrote glue code to interface with a site's published API, and IFTTT could then write recipes to use the site. IFTTT thus stitched together other sites published APIs as a service.

How IFTTT has decided it will work from now on:

1) IFTTT comes to you and orders you to write private endpoint(s) that do X, Y, and Z. They reserve the right to ask for additional endpoints, different call results, or anything else they dream up down the road. You sign a legal agreement promising to ask "how high?" any time they say "jump". You will not be compensated for this privilege.

<comment><USER46> Wouldn't you be performing this work because you believe it will facilitate the transfer of traffic to your site? Aren't you comitting to make changes as and when ifttt change their API so that you can continue to receive their calls? Sites/services can just walk away if they don't want the traffic. No one's obliged to pay or do anything they don't want to.

<comment><USER47> I think the subtlety that's not evident from these comments is that Maciej didn't solicit IFTTT integration to begin with. In fact, as I recall it, IFTTT did a hacky integration that misused Pinboard's authentication, and Maciej had to help them correct that.

Later, after putting a bizarre legal agreement in front of him to sign, IFTTT announced that Pinboard would stop working on their service in a manner that made it sound an awful lot like Maciej had just decided to stop supporting IFTTT. In reality, all the agency in this relationship belonged to IFTTT.

<comment><USER48> If they actually succeed at that, it's gonna be a laughing season. Every time a company does something and becomes widely successful, their methods are then recommended on business trainings, startup conferences, etc. So if IFTTT actually manages to subdue many services this way, you can expect other startups to think they can build business out of a) hooking up to your service without your knowledge, and b) telling you you're supposed to become their customer now.

<comment><USER49> Isn't that the Yelp business model? They're notorious for calling up businesses (mainly restaurants) and then offering the business a way to pay to remove negative comments on Yelp (there was a case where some were entered by a Yelp employee!)

It's essentially the "protection/promotion" model.

<comment><USER50> That's a nice restaurant you have there... it'd be a shame if something happened to it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Thanks Maciej.

</comment><comment><USER51> > I am all for glue services, big and small. But it's better for the web that > they connect to stable, documented, public APIs, rather than custom private > ones.

This is the clincher for me. I spent about 15 minutes looking around IFTTT before figuring out that there _were_ no developer docs because this is a service for enterprise customers, not for us.

</comment><comment><USER52> It seems like more and more companies' business model simply involves setting up a "toll booth" on the internet.

<comment><USER53> Big companies might get away with toll booths - how about small ones like IFTTT? There are alternatives, these services are not _absolutely necessary_ (like payment processing or hosting) etc etc. It is in their own interest not to screw people over. There will always be someone else to take their place.

</comment></comment><comment><USER54> How many times, dear colleagues, do we have to be reminded of this truth?

If you don't pay for the product, you are the product.

<comment><USER55> How much did you pay to post your message?

</comment></comment><comment><USER56> Is there an open API standard for exposing a web service to IFTTT, Zapier, or other app connectors?

</comment><comment><USER57> Something is wrong with your cert

<comment><USER21> Some other people are saying they've seen Chrome complain, but I can't reproduce it. Please send email (email@example.com) if you can figure out what's up.

<comment><USER58> Incorrect certificate chain. When you moved to SHA2 certs, you failed to change the intermediates to the "Gandi Standard SSL CA 2" ones.

<comment><USER59> 1 s:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2 i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

Nope...?

<comment><USER58> Yes, this is the correct intermediate.

<comment><USER59> Ah, his blog.pinboard.in and pinboard.in configs are different.

@idlewords: [http://charlieharvey.org.uk/page/gandi_sha2_intermediate_cer...](http://charlieharvey.org.uk/page/gandi_sha2_intermediate_cert_ssl_tls)

Are you putting the chain certs in the SSLCertificateChainFile file, and not concating them to the SSLCertificateFile?

</comment></comment></comment></comment></comment></comment><comment><USER60> HN meta: I'm sort of disappointed that this has been getting downvoted.

Obviously, what Linden is saying in this case is probably not helping his business case. It's clear to me that he either does not understand why Maciej doesn't want to implement a private API, or does not wish to understand it.

On the other hand, neither of those things are grounds for a downvote, I think. A downvote says "this content shouldn't be on HN" \-- that there's something about a comment that detracts from how the community operates. Linden has been completely respectful in what he says and how he says it. Maybe that's not the case in what he's asking his users to do, but we may as well let him ask.

<comment><USER55> _A downvote says "this content shouldn't be on HN"_

Ehh, I'm not sure that's generally accepted. A few years back pg himself did say downvotes could be used for showing simple disagreement, and many people seem to agree even today.

<comment><USER61> If people use downvotes to show disagreement, than HN is sunk. No-one likes downvotes, and it will create a community where people only post those comments that they think everyone will agree with. Instead, downvotes should only be sed to highlight comments that should never have been made.

<comment><USER62> Dude, that ship sailed some time ago. And I say this as someone who agrees with the HN "mob" on most things. The hardcore libertarian-randist opinions you'd see relatively often around here have all but disappeared.

</comment></comment></comment></comment><comment><USER63> Well, that's stupid of them.

</comment><comment><USER64> Ridiculous!

</comment><comment><USER65> We really do need some standard unicode glyphs for 'mic drop' and 'awed silence'.

</comment><comment><USER66> A startup becomes uncool when it starts driving code churn as a _value reducer_ ostensibly as "new value," but instead alienates their vendors and customers alike. IFTTT reminds me of the audicity of Hillary Clinton assuming she's already the next president while avoiding releasing those damaging Goldman Sachs transcripts (where her boilerplate contracts require a stenographer, and an attendee describes the tone of one speeches as that of her acting like a managing director cheerleading the troops). Or maybe the Drumpf's endless list of bankrupt companies and bringing meat from the grocery store to prove nothing. Oops. Edit: Anyhow, I'll move my weather warning texts over to a service that doesn't molest its developer partners without their consent. Thanks IFTTT, here's your mixtapes back.

</comment><comment><USER67> Isn't much of the legal stuff just a way to cover their tails?

For example, the bit about owning content. Do they really want your content? Is content on the internet worth anything these days? If your content is worth something, it's likely the Google ranking which gives it value rather than the content itself.

I imagine that's just an attempt to keep people from suing over reproducing content to go over the pipes.

PEDRAGOSA V. GOOGLE SPAIN, S.L. - Google got sued for reproducing content in various ways in search results. The case went in Google's favor but the legal costs for this sort of thing is probably a killer for services which don't have that GOOG ticker symbol.

The "no competition" bit seems like it's meant to keep people from using IFTTT developer tools as part of their own competing service.

Why bother reading the legal stuff? It likely won't ever come up to affect you. There is some risk, but the opportunity cost of taking the time to go through it is probably greater. I imagine most of the world population doesn't have the comprehension ability to understand what they are reading anyways. You might as well just stop using the internet rather than trying to make sense of the legal stuff.

<comment><USER40> > _Isn 't much of the legal stuff just a way to cover their tails?_

Sure, but most of it puts your tail on the line instead. They've decided that they somehow have enough power to make you do their job, and make sure you do it in a way that protects their legal interests over yours. You'd be a fool to agree to it.

> _Do they really want your content?_

Yes. Their lawyer told them that it was a good idea to make sure their license agreement gave them (and I quote) _all right, title, and interest_ (section 3) to _any materials displayed or performed on the Service_ (definition of "Content" in section 1). They thought it was a good idea to follow said lawyers advice, because it was easier for them if they could just do whatever they wanted with your content. So, yes, they want it. That's probably not because they want to run off with it, but because it's easier (for them) that way and they don't care about you. It's much easier for a business to evolve and grow when they know that they can just do whatever they feel like and don't have to stick within the narrow terms of an existing agreement. Open "give me all your stuff" agreements are much simpler to use.

> _Why bother reading the legal stuff?_

Because they could be bothered _writing_ it, so they obviously think it's important. And it gives them all the rights that they could possibly want for nothing in return.

If it's not important, then it didn't need to exist in the first place. If it needs to exist, then it's worth reading.

We're not talking about a simple end-user here, this is Maciej's company and full time job, and IFTTT seems to want to use this license for B2B integrations. _Crazy!_

<comment><USER67> I feel like there are two sides you can take on this. There is the "ideal" side where we read all the fine print and stay away from services which violate X elements which we individually consider as going over the line. Then there is the boots on the ground reality which is what really happens vs. what could happen.

I don't think either side is right or wrong. I see people like RMS as being on the extreme end of the ideal side. He may be right. His tech usage habits from his beliefs may work for him. But I'm not willing to go that far.

I think leverage may be a silent force in this case. If X service has terms I hate but I feel like I really need the traffic I can generate from that service (so that I can eat) then I'm probably going to jump on it. If I feel like I don't need the service, then I may not bother. I may complain about the terms, but being unwilling to put in the effort for something I feel I don't need might be the greatest force.

In the Philippines, all businesses are on Facebook because Facebook is the internet. Facebook plays similar games with their terms (as does a long list of services). But if you want to advertise to locals, you don't have much choice but to give in.

I would like to see someone who is expert in this area weigh in on why these services come up with these terms. IFTTT isn't going to be selling or using user generated content. I don't see that Pinboard has any content to lose of their own (all of their content is user generated?)

I'm sure I'm wrong, but the only reason I can come up with is to cover your ass if someone sues you for content which goes through your wires and potentially gets displayed on your site. Covering your ass isn't evil. Attempting to remove the right for one side to sue in the normal operation of the service is attempting to create a lopsided relationship (one side gains powers while the other side loses powers.) But they may be necessary for a service which has received funding and could be a target for court battles.

I don't agree with much of your logic.

> If it's not important, then it didn't need to exist in the first place. If > it needs to exist, then it's worth reading.

I have a spam folder in my email which I would submit as evidence to refute this point. I could also submit my Facebook feed, Twitter feed and a whole bunch of other sources.

<comment><USER68> > I would like to see someone who is expert in this area weigh in on why these > services come up with these terms

Obligatory IANAL. But I don't need to be.

IFTTT came up with these terms because they believe the terms to be beneficial to them. It's that simple.

They _could_ have put terms in which said "integration with IFTTT means you're giving us permission to connect to your service, and to copy and redistribute the data without limit". After all, that's what they do, technically.

Instead, they're claiming _ownership_ over the data. Your data.

That's something very different.</comment></comment></comment></comment>


Why You Can't Dismiss Nokia's 41-Megapixel Phone - <AUTHOR> http://techcrunch.com/2012/02/27/why-you-cant-dismiss-nokias-41-megapixel-phone/ <comment><USER2> "It's just the slightly awkward first steps of a serious move by Nokia to differentiate itself."

This seems like the same old cell phone industry for me. Several years ago, camera megapixels were one of the most standout features on cell phones for consumers. It was simple enough to boost the number ever year and have a buyer go "Well 4 > 2, so this phone must be better" I'm not so sure if thats a valid strategy in this current market.

</comment><comment><USER3> Seems more a PR ploy by a waning innovator...</comment>


Rust for JavaScript Developers – Pattern Matching and Enums - <AUTHOR> http://www.sheshbabu.com/posts/rust-for-javascript-developers-pattern-matching-and-enums <comment><USER2> Enums are my favorite type in Rust. You can do so much with them, and even more using 3rd party crates such as strum [1], allowing you to do things such as iterate over variants and decorate each variant with custom properties. How is this useful? Here's one example: an enum's variants can map to the values of a reference table in your relational database. When you seed your db, iterate over the enum variants and load into the ref table the properties associated with each variant (the properties you associated using strum). When you query values from the reference table, resolve the value to the enum type. You'll never have values in your table/model that are out of sync with your enum in rust.

[1] [https://github.com/Peternator7/strum](https://github.com/Peternator7/strum)

<comment><USER3> Having used enums with large teams across many distributed systems over the years, enums are my least favorite type in that setting, because it's very easy to write an enum that does not tolerate unknown/new values (they usually don't by default, which seems to be the case for Rust as well). This often makes the system brittle to new changes because subsystems have very strict expectations of data schema, even when they don't really need to care about it (e.g. when they're just passing data around).

I've seen a lot of attempts on these teams to ensure these mistakes aren't made (special parsing libraries, using default fallback values, etc.), but someone always manages to sneak in an enum somewhere where they shouldn't and then something blows up 6 months later when a new value is introduced. Enthusiastic engineers will spend a _lot_ of time trying to figure out how to add an over-strict enum, because hey, who doesn't want type safety?

<comment><USER4> Rust prevents the program from compiling if a new enum variant was not handled, unless one uses a catch all in the match expression. Did the codebase have an over-usage of catch alls? Or were you using a different language that doesn't catch enum errors during compilation?

<comment><USER5> I think the key words here are "distributed system". Just because HEAD has the new enum used everywhere doesn't mean all the deployed code everywhere can handle the new enum value.

Imagine you have two servers communicating with

enum Packet { Ping, Pong, }

Where the semantics are that if you receive a ping, you say pong, and if you see pong, you say ping.

Suppose we deploy this out to several servers, with code built on 2020-7-12. Now on 2020-07-13 you commit to head a new enum value `Stats`, which returns a new kind of reply.

If you send outgoing requests in the same 2020-07-13 build, you're going to have a bad time, as your fleet is going to start at 100% 2020-07-12 and switch over to 100% 2020-07-13, but during that switch you'll have some 50% 50% split. If a new server sends a request to an old one, you'll have a crash.

Instead you have to add receivers in 2020-07-13, but not use it yet. Roll it out, make sure it's past how far you might roll back, then you can deploy a 2020-07-20 build which makes calls using the new enum.

If you skip that step, you're going to have a bad time. Maybe you want to instead have a default case handler instead of crashing, but that means each of your enums has to know about "UNKNOWN" and you're deserialization error has to be future proof.

<comment><USER6> Any time you break an API that accepts serialized data it's going to crash if you try to use it with something that is on a different version of the API. How is this any different with enums than it would be with changing a string to a float, or anything else?

</comment></comment></comment></comment></comment><comment><USER7> Question for the author:

Why does Rust destructuring require the struct name? The example uses:

      let Person { name, city } = person;

This seems a little verbose since I would expect the type system to know that person is of type Person already.

Is this because destructuring syntax is trying to be compatible with the pattern matching syntax?

<comment><USER8> You will find pre-RFCs[1][2] in [https://internals.rust- lang.org/](https://internals.rust-lang.org/) about this, as well as for anonymous structs[3].

It isn't in the language yet due to a combination of subtle issues that need to be considered before a final design can be reached, trying to keep the grammar clean, accepting that explicitness and verboseness now is better than hastily moving towards something that _seems_ better but that can introduce technical, documentation or understandability issues.

> Is this because destructuring syntax is trying to be compatible with the > pattern matching syntax?

It's not trying to be _compatible_ , it _is_ pattern matching syntax. If the language changed to, for example, allow the following

        let _ { name, city } = person;

Would also allow

        match opt_person {
            Some(_ { name, city }) => {}
            None => {}
        }

[1]: [https://internals.rust-lang.org/t/pre-rfc-struct- constructor...](https://internals.rust-lang.org/t/pre-rfc-struct-constructor- name-inference/10960)

[2]: [https://internals.rust-lang.org/t/pre-rfc-implied-type- for-p...](https://internals.rust-lang.org/t/pre-rfc-implied-type-for-patterns- in-argument-position/12391)

[3]: [https://internals.rust-lang.org/t/pre-rfc-anonymous- struct-a...](https://internals.rust-lang.org/t/pre-rfc-anonymous-struct-and- union-types/3894)

</comment></comment><comment><USER9> I appreciate the author's use of code style to make it easier to read the examples. While JS is usually camelCase they choose to use snake_case for functions like operate_drone.

I also appreciate the lesson of converting discriminated unions in JS and to rust - that's my favorite pattern from the TypeScript community.

</comment><comment><USER10> Another great crib sheet for JS folks to think about Rust. What I like about this, rather than say the Rust book, is you've given examples that map closely to other language paradigms without ignoring the fact that rust handles them differently.

</comment><comment><USER11> What is the reason for using different syntax for Move and TakePhoto from the Operation enum in the penultimate example? Is there a name for each of those enum member types?

<comment><USER8> Enums have 3 different variant types:

        enum Foo {
            StructVariant { named: i32, fields: String, with: (), types: usize },
            TupleVariant(i32, String, usize), // only types and position information
            UnitVariant, // just a tag, no other days being carried
        }

The struct variant is useful when you are carrying enough different fields that you want to name them.

</comment></comment><comment><USER12> Great stuff. Thank you :)

</comment><comment><USER13> JavaScript and Rust are so opposite in their goals and design that I wonder why something like this is written...

<comment><USER14> I have professionally come across many website backends that were developed in Javascript. Over time we are seeing projects that add more robustness, performance, and ability to support in the form of Typescript and now Deno.

With WASM becoming mainstream and the growing maturity of the Rust ecosystem, it appears to be a solid choice for backend systems and potentially emerging frontend use cases.

<comment><USER13> If they wanted something better for the backend (for robustness of performance reasons) there are other alternatives much better suited for the vast majority of backends. For instance, C#.

WASM is not needed for the backend, so that is not the reason either. For frontend, I can see it for some pages (I used it myself), yes, but there are also other languages that can target WASM.

You also mention maturity of Rust, but other languages in its domain are more mature, so that cannot be it either.

<comment><USER15> WASM is not _required_ , but having a sandbox around native (e.g. Rust) code seems like a good idea, and it allows you to mix languages and opens other ecosystems.

<comment><USER13> No, it is not a good idea for backend where your processes and code are trusted because it does not come for free (it comes with a big performance penalty).

Mixing languages does not require WASM in native code either. It has always been done through the C ABI.

<comment><USER15> No process nor code is trusted in my company. The performance penalty is negligible compared to the multi-million risks, and WASM execution can be optimized a lot as it goes past MVP.

I don't know how to import a ES6 module using C ABI.

<comment><USER13> > No process nor code is trusted in my company.

Then you cannot use any modern computer in your company. Much less hypercomplex systems like Node, v8 and JITs in general.

> compared to the multi-million risks

What "risks"? What standards are you following? Insurance?

> WASM execution can be optimized a lot as it goes past MVP.

Citation needed. There is no magic.

> I don't know how to import a ES6 module using C ABI.

So that is why you want WASM?

<comment><USER15> V8, JVM, CLR and others are well proven runtimes providing a well functioning sandbox, but of course we test a lot. I am sure you know what the risks are with native code - you're a native code proponent after all; any code running in a medium and bigger company that could misplace money is a huge liability.

I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus).

I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through _safe and typed_ interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust _any_ library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there.

[0] [https://github.com/WebAssembly/proposals](https://github.com/WebAssembly/proposals)

[1] [https://v8.dev/blog/10-years#performance-ups-and- downs](https://v8.dev/blog/10-years#performance-ups-and-downs)</comment></comment></comment></comment></comment></comment></comment></comment>