Bancor has lost more than half its value since June ICO - <AUTHOR> https://www.bloomberg.com/news/articles/2017-11-01/shining-star-of-initial-coin-offerings-crashing-back-to-earth <comment><USER5> I'm sure Bancor couldn't care less about their token price collapsing. They've already got all of the "investors'" money.

In fact, they could just walk away right now instead of carrying on developing the system. The brave new world of ICOs offers no protection against companies failing to follow through on their ICO roadmap. Maybe Bancor could use the token collapse as an excuse to quit now?

<comment><USER6> The SEC might say otherwise. There are plenty of civil and criminal options for recourse if they simply "walk away".

<comment><USER7> Ironically, it is the SEC and it's regulation that made Bancor structure their ICO the way they did. To escape being classified as a security, you have two options: either give the tokens away for free, or promise nothing. Most crypto startups do the latter.

<comment><USER8> Not quite. In the USA, classification as a security is usually determined using a four-pronged legal standard called the Howey Test.

A security is:

1\. An investment of money,

2\. In a common enterprise,

3\. With an expectation of profits,

4\. Predominantly from the efforts of others.

Selling something without making any promises doesn't necessarily preclude expectation of profits.

</comment></comment></comment></comment><comment><USER9> ICOs are more akin to angel/VC rounds than IPOs - you often invest in a idea thats still not fully developed and might need 1-2 years to come out on the market. The huge difference to traditional investing is that shares/tokens are immediately tradable and small(ish) crypto investors have 0 patience to wait those 1-2 years so they often sell early and crash the price to go looking for another get-rich scheme.

Thats a curse of the ICOs - but also a benefit. As an investor you get to assign value to something immediately and have the freedom to terminate your investment (something very difficult with traditional angel/VC rounds) and sell the tokens. Its also a fascinating marketing strategy - some of your crypto "investors" are early adopters, promoters and users of your tech - <USER2> more so because they're vested in it.

I'm not defending the ICOs (especially the over the top ones) - but lately there are so many articles that don't really try to understand the concept. And so many people automatically equating temporary loss of value with scams. Internet and cryptos are moving at the speed of thought - but the rules are still the same - startups need time.

In all fairness - Bancor is still a very young project. Also a fairly promising one - many projects already using it: [https://www.reddit.com/r/Bancor/comments/75b7us/list_of_all_...](https://www.reddit.com/r/Bancor/comments/75b7us/list_of_all_known_projects_committed_to_using/)

<comment><USER10> Very few ICOs do right by investors. We're one of the few offering equity positions and dividends. The law conveniently provides an excuse to them, see Tezos even outright calling it a donation! As an EJC the laws don't apply in the same way, so we directly offer shares in our startup.

Few ICOs are willing to do the ethical thing because they're just cash grabs. Hire a small team to try to make your whitepaper vision into code. If it fails and you were not too far fetch in using company funds, nothing bad will happen to you. It's disgusting.

<comment><USER9> You could say the same thing about "traditional" startups though - <USER3> often invest just based on the combination of the idea, founders/team and maybe an early prototype. If the startup fails - nothing "bad" will happen to you either. Shares in a startup thats not publicly tradable don't really offer you that much security.

Unless you've committed fraud - but - I've been following the ICO market closely for the past 6 months and I can't remember any of the larger ICOs that were outright scams. Many people and smaller projects/websites will of course try to scam you online - but you should always do your own research and due diligence still applies.

I'm not sure I'd agree that "very few ICOs do right by their investors". It depends what you mean - there have been many successful projects out there that made people money. But if you mean "flipping" i.e. buying into a ICO just to try and sell it quickly for profit - that seems more difficult these days. But it might also be due to the current BTC rally.

ICOs are of course still in wild west territory as far as regulations go - there is a reason why Tezos calls it a donation. They don't want the regulatory hurdle. In fact almost all ICOs these days force you to accept that tokens are not shares in the company and don't "officially" entitle you to anything.

<comment><USER11> There's an ICO scam tracker here - [https://etherscamdb.info/scams/](https://etherscamdb.info/scams/)

There seems to have been quite a few.

<comment><USER9> Note that this is a database of fake phishing websites that impersonate legit projects (and try to steal your money) - its not a database of scamy ICOs. As mentioned - there are certainly those too - but I don't remember any with bigger/reputable projects lately.

</comment></comment></comment></comment></comment><comment><USER12> Bancor plummeted right after the ICO. It's still above it's all time low, so it's not exactly a new thing. [https://coinmarketcap.com/currencies/bancor/](https://coinmarketcap.com/currencies/bancor/)

There were plenty of warnings and research about how flawed their product is, including here. The lesson, as always, is caveat emptor.

<comment> chroem- Most alts are traded in terms of BTC. Bancor's dollar value has only ever gone up because increases in the price of bitcoin have occasionally offset Bancor's losses relative to BTC. Bancor's value relative to BTC has been monotonically decreasing since its ICO, which is a feat unto itself.

</comment></comment><comment><USER13> Why do so many cryptocurrency projects seem so meta?

Platforms for creating platforms, coins for creating coins.

<comment><USER14> Easier to sell to people trying to make a quick buck than doing something concrete that is directly useful. Why sell even shovels directly at the goldrush when you can manufacture the shovels...

<comment><USER15> Or write a whitepaper about how you will build a factory that will build factories to manufacture shovels.

I'm, ah, seeking investors.

<comment><USER16> Or building GPU chips that accelerate deep learning algorithms that write white papers about how you will build a factory that will build factories to manufacture shovels.

Investors: I'll accept check, btc, or pepecoin.

</comment></comment></comment></comment><comment><USER17> The spot price has fallen by more than half; the value has held very steady at zero.

</comment><comment><USER18> Bancor's been plagued with some technical problems that have been exploited by miners and hackers to front-run their algorithm.

The explanation for the losses are related to the price stabilisation / automated market making algorithm being exploited while in its early infancy.

I'm really sad at the reactions people on HN have to Blockchain businesses and topics, but I am confident this is a case of horse-traders dissing on Ford Model T. It's like the SV crowd is finding it hard to believe no one wants another social media uber for X whatever now that the money and the spotlight are shining on communities very far from your own.

</comment><comment><USER19> Volatility in cryptocurrency-based securities? I am shocked, shocked.

<comment><USER20> Compared to volatility in fiat currencies? I (perhaps incorrectly) assume you live in a relatively stable and developed nation that hasn't seen hyperinflation?

Should I base my views of fiat currency from things like the 79.6 billion percent hyperinflation in Zimbabwe?

Neither is inherently volatile. Both can be, but it isn't a built-in trait of fiat or cryptocurrency.

<comment><USER21> Perhaps cryptocurrencies _are_ inherently volatile. We don't know either way.

In any case, there is zero empirical evidence that they aren't, given that there has not once existed a stable cryptocurrency.

<comment><USER22> Yeah this is incorrect. USDT, although incredibly shady, is pegged to the United States Dollar, and therefore a "stable" currency.

</comment></comment></comment></comment><comment><USER23> What? This is like every shit coin. Tons of them tank to near zero and deflate. Anyone who thinks these coins are legitimate are fooling themselves. They are built with one core requirement, do just enough to differentiate from other coins, pump it, get out.

The average person can't understand 99% of the specs of these coins, it's all speculation. The whole thing is a ponzi scheme.

<comment><USER24> Just because some ICOs can be scams is no reason to write off the entire concept as a scam.

<comment><USER25> The entire concept is a multi level marketing scheme.

<comment><USER26> No, not all of it. It only appears that way before looking into it more.

<comment><USER27> Would love to hear more on legitimate use cases for blockchain (not being sarcastic) that cannot already be solved by centralized database, merkle trees and/or public key encryption.

<comment><USER23> I think they meant that concept behind an ICO are a scam not that blockchain is.

<comment><USER27> That's the problem. The investors for ICOs are backing on blockchain as if it's some amazing new innovation that's "going to change the world".

<comment><USER28> It's just an incentive and control plane for other stuff. You still need the other stuff.

<comment><USER27> Yes, and I'm asking for legitimate "other stuff" that applicable for an ICO and/or blockchain. Been waiting for a while on this one.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I did quite a lot of research into Bancor from a non-cryptocurrency-developer perspective a few months ago (when looking at possible ways to launch a token for Matrix - c.f. [https://matrix.org/blog/2017/08/22/thoughts-on- cryptocurrenc...](https://matrix.org/blog/2017/08/22/thoughts-on- cryptocurrencies/)) - and concluded that it's actually quite an interesting idea (once it finally 'clicked').

From the normal dev perspective: the idea is that it removes the concept of using a marketplace to exchange between currencies entirely; instead it replaces the exchanges with an algorithm which gives a consistent global way to calculate the FX rate at any given point. The formula used is mathematically very simple: you allocate a 'reserve' of your currency to be backed by a 'base' currency (by default, their BNT); and as folks buy and sell your currency it algorithmically defines the exchange rate relative to the base currency based on the total supply of your currency in circulation. So rather than the exchange rate being determined by the human interactions of traders, instead it's determined by a function of the current market cap - <USER4> everyone is held true to using the same function because it's part of the codebase that defines how the currency operates, running as a smart contract on the Ethereum VM. From memory, the function itself defines the FX as being proportional to the amount of token supply relative to the reserve, after applying a selectable exponential damping factor.

The code is kinda interesting, as it ends up implementing some fairly scary fixed-point exponentiation in such a way that it can run on the EVM with the reversibility and predictable rounding errors which are required for small transactions to cause tiny but 'correct' changes in the FX rate for that currency. [https://github.com/bancorprotocol/contracts/blob/master/soli...](https://github.com/bancorprotocol/contracts/blob/master/solidity/contracts/BancorFormula.sol) has the gory details.

Now, the idea certainly does have some controversies, including:

* It requires some kind of common currency to be able to work, and Bancor positioned themselves as the common currency for that purpose (hence their ICO). That said, you could also chain together separate 'common' currencies though, or just access a Bancorified network of currencies via an old-style exchange.

* Whilst the formula used to calculate the FX seems sensible enough, it's not obvious it's the only (or optimal) solution, but it's very baked into the system. (Although the contract does have a backdoor to let it be upgraded in case of bugs or problems, which is a bit controversial in and of itself).

* It's an interesting question whether it's a feature or a bug that markets have a human function which can act emotionally/irrationally - rather than behaving 'perfectly' through the magic of a shared smart contract.

On balance, it feels like a very interesting system for managing small-scale tokens - especially ones which need liquidity and stability beyond their natural market cap. However, this is a slightly niche market which is still evolving (relative to everyone who's running around trying to do as large an ICO as possible), so it's perhaps not surprising that it's yet to take off.

(Disclaimer: I'm not working with/for Bancor, although have chatted to them a few times.)

<comment><USER30> It is rare to find someone actually contributing to a crypto currency discussion, rather than just sharing their opinion. Insightful comment thanks!

</comment></comment><comment><USER31> > Bancor Chief Executive Officer Guy Benartzi said Sirer is making his claims > because he is advising another company.

That really says it all. The CEO prefers to attack ad hominem instead of responding to his very well substantiated arguments. Bancor is BS and a perfect example of the whole ICO scam thing.

</comment><comment><USER32> Cryptocurrencies were created to allow people to opt out of society's current power structures.

That might explain why Bancor, a cryptocurrency backed by traditional power brokers doesn't work as a cryptocurrency.

</comment><comment><USER33> Why not name the coin in the title? Bancor.

<comment><USER34> In this case the more general title is superior. I, for example, had never heard of bancor so wouldn't have clicked on the article.

<comment><USER35> I mean, you could write "Bancor, One of the Most High-Profile Initial Coin Offerings, Has Crashed 50%"

Then it's informative to readers who know what Bancor is and those who don't.

</comment></comment></comment><comment><USER36> Most people in the scene were warning people away from Bancor due to the large amount of money being raised. Generally large raises will result in a massive fall regardless of the teams performance short term.

Also it was never clear how their token fit into the future of the CryptoCurrency ecosystem.

It always seemed like an ICO-token without a purpose, looking to invent one.

Thing is most of these dapp ideas would gain a larger network effect and be more efficient just by using ETH.

</comment><comment><USER26> Ehh, my 3d printing stock fell to about 10% of its value. It happens in every market - just make sure you are diversified... especially if you are investing in high risk markets.

Edit: I'm probably getting downvoted because I'm comparing IPOs to ICOs. They are significantly different and everyone should beware of scams.

<comment><USER37> More like the model you seem to explain is too naive and exploitative by people just snake-oiling thousands of things, since by diversification you sell all of them.

</comment></comment><comment><USER38> So what, GRPN fell to 1/5 of its IPO price in its first year.</comment>


Self-Control Saps Memory, Study Says - <AUTHOR> https://today.duke.edu/2015/08/meminhibit <comment><USER2> I wonder if you could use this principle to treat people who've just suffered a traumatic experience? Give them a task that requires inhibitory control, and perhaps they won't commit as much of the traumatic experience to memory?

On the other hand, if the mechanism worked this way you'd expect the study participants to have worse recall on _all_ faces, not just the ones with the inhibited responses.

<comment><USER3> Your comment made me think of a related but different study I read related to trauma reduction soon after a traumatic experience by using a game (like Tetris). If you are interested: [http://pss.sagepub.com/content/26/8/1201](http://pss.sagepub.com/content/26/8/1201)

</comment></comment><comment><USER4> This could be another evolutionary survival mechanism, a "short circuit" of sorts for life-saving responses.

("No, I didn't get a good look at the tiger, I was too busy busting my ass running back to the cave.")

</comment><comment><USER5> Url changed from [http://www.sciencealert.com/researchers-show-how-self- contro...](http://www.sciencealert.com/researchers-show-how-self-control-can- drain-your-memory-banks), which points to this.</comment>


We really do love Mozilla Persona. And that's why we're sticking with it. - <AUTHOR> http://blog.zonino.co.uk/we-really-do-love-mozilla-persona-and-thats-why-were-sticking-with-it/

<comment><USER2> So they are going to still provide the servers but not support the development? That's an odd choice..</comment>


Urban Farming in the 1600s - <AUTHOR> http://www.lowtechmagazine.com/2015/12/fruit-walls-urban-farming.html <comment><USER2> Interesting! I just started reading about possibilities for growing vegetables in my apartment and one of the first concepts was the heat gain of planting against the wall and extending the plant season.</comment>


An Introduction to HTTPS, by 18F and DigitalGov University - <AUTHOR> https://18f.gsa.gov/2015/07/16/introduction-to-https-webinar/ <comment><USER3> This is the first time I've heard about 18f and I really think the model will work. It's a familiar system to agencies, using the consulting model, yet you guys work directly for the GSA.

I worked as a government contractor for quite a while (SAIC) and I applaud this effort. I imagine the hurdles will be immense, so I wish you the best. We need more of this.

</comment><comment><AUTHOR> Full disclosure: I'm the submitter and the creator of these videos. Happy to answer questions or take feedback for future educational work we could be doing.

<comment><USER4> Really curious if you can speak to any internal politics around advocating for encrypting more communications while much of the executive branch is advocating against that.

Is 18F sufficiently independent, or this project sufficiently below the radar that it just isn't an issue?

<comment><USER5> Entirely different worlds.

People think "The Federal Government" is a monolith, and they could not be more mistaken. It is a collection of individual entities, operating largely independently and often at odds with one another. 18F is a different entity with a different set of goals from the law enforcement (FBI/DEA/etc.) and intelligence (NSA/CIA/GeoInt) agencies.

In any case, it's also different parts of the tech stack - <USER2> everything over the wire with HTTPS is fine so long as the underlying encryption is weak and/or the NSA have a set of keys. The FBI can always just issue a national security letter to the party with whom you are communicating.

<comment><AUTHOR> > People think "The Federal Government" is a monolith, and they could not be > more mistaken. It is a collection of individual entities, operating largely > independently and often at odds with one another.

That's definitely an accurate description of the US federal government.

</comment></comment></comment></comment><comment><USER6> Haven't had a chance to look at the content itself yet, but do you cover FIPS at all? Our company is wanting to sell product to the U.S. Federal govt and it turns out we need to improve our TLS (data-in-transport) implementation to use FIPS-validated crypto providers. It'd be nice to understand why simply using strong TLS v1.2 cipher suites is not enough and we need to also plugin a special crypto provider.

<comment><USER7> The reason for requiring a FIPS-validated crypto provider is that means the crypto provider been audited by a vetted auditor. In order to carry sensitive information, the crypto needs to be audited by a vetted auditor. "The CIO's nephew totally coded up the crypto last Summer, just trust us that it's good" doesn't cut it when handling sensitive government data. In particular, it means that random values are generated by a FIPS-certified generator, not just srandom(time()^getpid()); int x = random(); int y = random(); int z = random(); The government needs some kind of auditing standard and practice for systems that handle sensitive information. FIPS is far from perfect, but it gives a good lower bound on what the government is buying.

<comment><USER8> FIPS is bureaucratic government red tape, and nothing else. It gives the "US Department of Whatever" and their contractors someone to blame when there's a fuck up.

No one respected in cryptography that I've met, or read papers from, would stand behind it as a seal that'd mean anything in actual security (please, _someone_ , prove me wrong: I want to see SOME light in this tunnel). There are private entities with much more sensitive information than the U.S. Government, and the ones that take it seriously easily surpass FIPS (in purpose, not paper) with good engineering, because they can't hide behind a rubber stamp.

Not too long ago, I was on a team that was required to keep a FIPS-certified (FIPS 140-2) binary blob in production for months while there were known exploits against it. If you _actually_ care about keeping amateur algorithms and implementations out of sensitive situations (vs. "Proving You Care via Paperwork"), you'd do better to follow Google or Facebook's security blogs than FIPS, because they react faster.</comment></comment></comment>


Harman debunks youthful music myths - <AUTHOR> http://www.cepro.com/article/harman_debunks_youthful_music_myths/K536

<comment><USER2> I don't see any debunking (just some 'well, it's not -completely- that way') and I see a lot of pointless 'I want to get the name of my company in the media.'</comment>


Three Player Chess Game Invented - <AUTHOR> http://therawfeed.com/three-player-chess-game-invented

<comment><USER2> There are many three-player chess variants. The Wikpedia article on the subject lists some of them:

<http://en.wikipedia.org/wiki/Three-player_chess></comment>


Chec(kout) - Sell anything, anywhere. A platform for longtail ecommerce. - <AUTHOR> http://trychec.com

<comment><USER3> Not really related to the product idea (there've been a raft of gumroad-type services launching lately), but has anyone else noticed the absolute explosion in blurred background images in designs these days? I swear the vast majority of new startup landing pages involve a highly blurred background of some kind.

<comment><USER4> It makes the landing page similar to a photo captured with an expensive lens on a high quality camera, where the foreground (text and logos, in this case) is in crisp focus, whereas the background is said to be in [bokeh](<http://en.wikipedia.org/wiki/Bokeh>).

<comment><USER3> Yeah, I just realized that myself as I was looking through a bunch of sites that use the effect. I think it's a great trend, for sure, but it's just been popping up everywhere.

</comment></comment></comment><comment><USER5> Seems like we get a site like this every few days. Are they making crazy money or is there some other reason everyones is making one? Are they just really easy to make? Maybe because payment process disruption has occurred? What's up?

<comment><AUTHOR> Most of these sites will go down due to one big hurdle. Payments.

Underwriting merchants and get verified by Visa/MasterCard as a payment service provider is a bitch. Aggregating credit cards is a heavily regulated area - but most of these sites are unaware of this issue.

We initially started on Stripe, and got told what we were doing was unregulated/not allowed on stripe, so we then grabbed a coffee with them and learnt about this process.

In fact I was grabbing coffee with Sahil (Gumroad) a few months ago and they've just run into this issue themselves - which they are starting to solve. so you'll probably notice them asking you for more information to underwrite you, unless they find a way around this.

That's also why we ask users to go through an activate process.

<comment><USER6> Interesting. Does using Stripe Connect bypass this restriction since you are not actually handling any money? Or am I misunderstanding things? Questionable site name, but well done! :) Cheers

<comment><AUTHOR> yup they do, thats why sites like spacebox.io & shoplocket are fine, but others are (probably) just illegally aggregating.

</comment></comment></comment></comment><comment><USER7> My 0.02c: you should change the name. If you already have to append "(kout)" to explain it to hackers, it will be 10x more difficult marketing it to a larger crowd. Or you can start printing stickers that read "you know, without the 'k'" ;-)

Apart from this, great design!

<comment><USER8> $0.02 or 2¢ =P

<comment><USER9> It is possible he values his thoughts less than the traditional two cents.

</comment></comment></comment><comment><USER10> In what ways is this different to Gumroad [1]?

[1] <http://gumroad.com>

<comment><AUTHOR> Gumroad's a platform for people who want to sell digital things they create and has a 5% fee.

We're a platform for long tail merchants. So for example - you'd sell the psd your not going to use in your app on gumroad, but you'd sell the final app through chec. - if that helps. - we also only charge 3.5% and can do a lot more with downloads + handle physical products.

We position ourselves between Gumroad & Shopify (if they did payments).

on a side note - me and sahil know each other well. Back in april 2011 when Chec was called Kout I actually reached out to him to join Kout after he launch groad on hackernews. He said "you've already built the software why do you need me" but we've kept in touch and occasionally get coffee and discuss the space.

Link based selling has been around for years. 2checkout, 1shoppingcart, paypal, ejunkie, quixly etc have been at it for a while. I came up with the idea for Chec after i ended up throwing a PayPal checkout in an iframe for a info product i was selling.

P.S - if anybody is wondering about the 2 year gap between launching - <USER2> story will come to light shortly.

<comment><USER11> The example you gave with PSD and app is not clear to me. Can't I sell my app through Gumroad ?

<comment><AUTHOR> You can, I was just trying to get across the usage cases/types of products.

We've had one user crowd fund for a childs trustfund through us. Dudes in europe selling rare coffee beans. Contracts invoicing for their time through the platform. The generic digital sales cds/ebooks/etc

We cover a wide spectrum of products.

We're trying to create a framework/platform for longtail ecommerce. Not just a platform for people who want to sell digital things they create.

There is definitely overlap between us and groad, but its not our primary focus, for certain things you want to sell its just quicker to sell via them, and thats cool.

<comment><USER12> You seem to be throwing the word "long tail" into the answer, but I still don't understand what makes Chec different/better than Gumroad for selling "long tail" items. I can sell both my app and my PSDs through both Gumroad and Chec. I really don't see a difference other than the fact that you can set fixed shipping prices. Maybe Gumroad doesn't support Paypal?

Can you compare and contrast the two in a meaningful way?

What can I do with Chec that I can't do with Gumroad? And for that matter, what does Gumroad do that Chec doesn't (yet) do?

<comment><AUTHOR> In terms of features

3.5% fee compared to 5%

PayPal Integration (for your customers who feel safer using them)

Physical Product Handling

Access Windows for digital sales (<https://trychec.com/assets/img/anything- digital.png>)

Inline Social Payments on Facebook (checkouts in customers newsfeeds)

Social Deals - Based on influence or demographics

And a powerful merchant backend.

as well as a few smaller features around.

Groad is primarily built to deal with digital files, we can handle any type of good.

and that's just in v1. we've got a lot to do, and you'll see us differentiate more in the future.

It might be easier to give the stories behind the idea to help.

So, i created this initially for myself. As a teenager i had resale rights to a DVD info product, and made a couple thousand a month selling it.

I hated the checkout process of 2checkout, 1shoppingcart, ejunkie, and others. So I ended up throwing a paypal checkout in an iframe and creating a post hook script to manage the order.

I wanted a simple, clean, yet powerful app to manage everything, so i made one. The first version of this was built in 2010.

I had one professional/full product to sell and i sold it in fairly high volume, and I didnt need a fully fledged store, i just had a single product to sell. Over time i created more and more minisites to sell different types of info products so i could have some passive income whilst i was at school.

Gumroads story

Sahil created an icon on photoshop that he wasnt going to use, but thought other people would find value in it so he wanted a service that let him sell his "value" to his followers (if that makes sense).

Gumroad allows people to sell their small snippets of value. (primarily digital).

Chec allows smaller merchants to start selling online who have no need for a front end store. Merchants like mmfixed.com etc..

Is that a little clearer? :)

</comment></comment></comment></comment></comment></comment><comment><USER13> TL;DR Use UTF for Seller's name.

Looks like a bit better Gumroad. Design is nice, blah blah blah. Why I'm writing is this: when activating account what the hell is supposed to be Seller's Name?

This annoying popup keeps telling me "Must contain only letters, numbers, or - ( ) , . ' &". I must say I haven't seen many names with numbers or ampersands in it. If it's meant to be a username, than ok but say it specifically. If it's really meant to be a name - it's 2013 for Ozzie's sake, use the damn UTF.

<comment><USER12> [http://www.kalzumeus.com/2010/06/17/falsehoods- programmers-b...](http://www.kalzumeus.com/2010/06/17/falsehoods-programmers- believe-about-names/)

Also, ampersands are common in company names. (Procter & Gamble, etc)

<comment><AUTHOR> We thought we fixed that bug. might just be some left over JS validation. we'll get into it.

<comment><USER13> Thank you :)

</comment></comment></comment></comment><comment><USER14> Who is your competitor? PayPal, Gumroad, Shopify, Stripe, Square?

How would Chec work for the following cases:

* A non-profit selling shirts to raise funds.

* A freelancer charging for his work. Essentially, a money transfer.

* A SaaS style service charging $5 a month.

* Charging for a PSD.

<comment><USER15> Like Devan stated below - "We position ourselves between Gumroad & Shopify (if they did payments)".

In the future, we plan on adding widgets that will work within our application that will cater to some of the cases you pointed out. Some of these widgets will include date/time charging (tutor offering hours/days of work) and subscription based charging (SaaS service you mentioned). Of course, we're not limited to just that.

As for the PSD, we host the file for you so all you need to do is upload the PSD and after the checkout process, the buyer can immediately download it.

</comment></comment><comment><USER16> Congrats on the launch - looks cool.

Do you support withdrawal of funds to non-US bank accounts?

Can't see this in the FAQ.

Likewise there don't seem to be any limitations on seller location. Are there any?

</comment><comment><USER17> It'd be cool if there was some option to post stuff to Craigslist or auto- format copy/markup for Craigslist, but that's just me asking for my own Pony. I like the look and ease of listing stuff.

<comment><AUTHOR> We looked into posting directly to Craigslist for you, but its against their T&C. :(

<comment><USER18> Checkout how airbnb does this. It's technically not posting directly, but directing user to the right page and populating the post information in a nice looking format. T&C compliant :)

<comment><USER19> Yardsale (app) does an awesome job of posting to Craigslist as well.

</comment></comment></comment></comment><comment><USER20> Love your site design - great use of whitespace and big, bold images! It would be nice to see a sample of a cart/page before signing up so you know what your "shop" will look like..

<comment><USER21> The site is impossible to use on mobile.

<comment><AUTHOR> yeah, we're working on that! we rushed the marketing site.

</comment></comment></comment><comment><USER22> Just an FYI, your layout has about 10% white space on the right hand side when viewed on iPad mini. Caused by the card fan lower down the page.

<comment><AUTHOR> Yeah just noticed that one, same in IOS. Working on fixing it up.

</comment></comment><comment><USER23> Just an FYI, the A/B testing link here is broken: <https://trychec.com/ab- testing>

<comment><USER24> as is the blog link: <https://trychec.com/blog>

<comment><USER25> as is the company blog link: <http://madebyswipe.com/blog>

</comment></comment></comment><comment><USER12> It says that you handle physical products and delivery. How do you do this? Or do you just offer delivery for digital item sales?

<comment><AUTHOR> We provide region specific shipping options for physical products, and will be doing tight integrations with UPS, Fedex, RoyalMail apis to help you with fulfilling physical items.

<comment><USER26> Do you have an eta on that integration? That sounds very interesting and the type of service we are already researching.

<comment><AUTHOR> I'd say within 6 weeks? We're a tiny team (2 devs). I'd love to speak to you about it and see what you'd like to see implemented.

drop me an email at devan [at] madebyswipe.com

</comment></comment></comment></comment><comment><USER27> This is really great. Perfect for things like Craigslist. Think you video could be a lot better. Keep up the awesome work, though.

</comment><comment><USER28> It doesn't seem to work. I created product, but when I click "Secure Checkout" button on product page nothing happens.

<comment><AUTHOR> can you link me to the product checkout?

</comment></comment><comment><USER29> What is longtail ecommerce?

</comment><comment><USER30> Is there a way to order more than one product at a time?

<comment><AUTHOR> We're working on that.

</comment></comment><comment><USER31> How do you handle charge backs and fraud?

<comment><AUTHOR> heuristics & 3 strikes with chargebacks and we lock your account.

But we've got a lot to do here.

<comment><USER32> It seems a bit harsh. The seller has no control over the chargebacks and you actually 'punish' the seller for them and not the buyer. Digital files chargebacks are more common than you think. How do you decide if the chargeback should receive a strike in the even that the buyer simple doesn't answer any contact requests(happened to me more then once). I've also had buyers lie about the purchase when in fact I had IP and email proof that they wore actually the ones buying but the chargeback was submitted(and approved) because they said they wore not the ones who made the transaction. Is anyone else using this 3 strike rule?

</comment></comment></comment><comment><USER33> This is awesome! Good job!</comment>


Leading sleep scientist explains why 8 hours a night isn't enough sleep - <AUTHOR> https://qz.com/1301123/why-eight-hours-a-night-isnt-enough-according-to-a-leading-sleep-scientist/ <comment><USER2> So, where is the research paper or something. We can't just trust 'leading sleep scientist'.

</comment><comment><USER3> I am kind of skeptical of the ever-increasing amount of recommended sleep. Apparently pre-industrial humans only slept an average of 6.5 hours a night. Sure, many pre-industrial humans also arguably live in worse material conditions than some of us today. But sleep science studies still do not seem very rigorous or convincing (many are based on absolutely tiny populations) and it all seems rather consistent with a cultural reaction against workaholism.

<comment><USER4> You're forgetting napping! A mid-afternoon nap makes up for the shortfall, but 'workaholism' effectively ended that practice.

<comment><USER5> My wife is very self-righteous about her lack of "need to sleep" \- she stays up all night, sleeps four or five hours, and goes on and on about how she's just "wired differently" than the rest of us and doesn't need as much sleep as us "lesser mortals". Then as soon as I turn on the car or start a movie, she's out like a light.</comment></comment></comment>


World of Warcraft Players Need Not Apply - <AUTHOR> http://bits.blogs.nytimes.com/2008/12/23/world-of-warcraft-players-need-not-apply/

<comment><USER2> "You can stand out here playing basketball, or you come come inside [to play World of Warcraft] and do something that matters."

\- Cartman</comment>


TclSqueak – IDE for Tcl - <AUTHOR> http://www.xdobry.de/tclsqueak/ <comment><USER2> I looked at the screenshot and thought "that's a nice, warm, fuzzy reminder of the late 90s state of the art."

Then I scrolled down and saw the first bullet: "modern UI"

I don't do much with tcl, but if I wanted an IDE for it that felt modern, I'd probably look at Komodo first:

[https://www.activestate.com/products/komodo- ide/](https://www.activestate.com/products/komodo-ide/)

<comment><USER3> This is not cheap.

<comment><USER2> I thought they'd made it available free-of-charge now. (That's the only reason I mentioned it here.)

That said, the only times anyone has ever asked me to work on large enough projects involving Tcl that I care if I have an IDE, I've been integrating very expensive, very proprietary software. I don't enjoy that work, my fees for that are high, and no one's ever flinched at the cost of the IDE in that context.

</comment></comment></comment><comment><USER4> I'm of the opinion no one should be writing new IDEs anymore for languages and should instead be writing good language servers for the language server protocol (and it's debugging friends). The duplication of effort for each IDE + language pair is just too large.

<comment><USER5> This creates an issue where the LSP is the bottleneck between what the language can express and what functionality the IDE can provide.

For example there is absolutely no way anything based on LSP can provide the same level of integration as what Lazarus has for Free Pascal and its LCL framework.

(also LSP essentially working by running a server locally that has to parse and emit JSON messages and an editor that also has to connect to a local server and parse and emit JSON messages is not exactly ideal when you care about keeping things simple and performant)

<comment><USER6> As far as I can tell, LSP can't even distinguish between a read and a write — it's not as useful as cscope 30 years ago.

</comment></comment></comment><comment><USER7> This looks like a delightful environment. I'm going to put it on my list of things to try out.

</comment><comment><USER8> What's the use case of TCL nowadays? I thought the language was fading out due to emergence of alternatives like Lua and Python, despite how much I love it.

<comment><USER9> It's still lighter and easier to embed than Python. Lua has sort of displaced it for "script" files but not so much for "config" files, as artificial as that distinction is; also I'm not sure how much Lua has caught on as an interactive embedded prompt. And in any case a lot of existing systems feel no need to migrate.

And honestly it's still a pretty nice language, as much as I've mostly lost interest in untyped languages. I've been thinking about trying to implement it (or a cut-down version) on GraalVM.

<comment><USER10> So actually this is one thing I found when embedding Lua recently in a project was that it doesn't really have a REPL. There's projects to add one, but it is not as eval-loop friendly as a scheme or a Tcl.

</comment></comment></comment><comment><USER11> Last commit was 5 years ago...

<comment><USER12> It must have reached perfection.

</comment></comment><comment><USER13> In what way the "inspired by Smalltalk programming environments" makes it different than other development environments?

<comment><AUTHOR> Nearly everything in Tcl can be inspected at runtime: the source code for procedures (and their arguments), classes that have been defined, methods, etc. Tcl can be made to appear as if it was "image" based rather than file based. This project taps into that.

</comment></comment><comment><USER14> I suggest writing extensions for vscode to provide tcl language server and debug server.

<comment><USER15> VScode seems like the MVP of IDEs to add support to. I'd go for community IDEA</comment></comment>


Moto 360 vs. ZenWatch 2 - <AUTHOR> https://feedcheck.co/blog/motorola-moto-360-vs-asus-zenwatch-2/ <comment><AUTHOR> Suggestions are welcome

<comment><USER2> I'd prefer to see a blog post about the development of the software or the story behind the project because the page looks about the same as the other pages from Feedcheck I have seen on Hacker News recently.

Good luck.</comment></comment>


Hiring Family & Friends - <AUTHOR>

What is everyone's opinion on hiring family and/or friends and why? I've heard both negative and positive reasoning from both ends and wanted to throw it out there for you all to weigh in. <comment><USER2> Friends, maybe. Family, NO! Why? Because family always expects you to forgive them, family expects you to always be there for them no matter how much they screw up and family will freeload on this for as long as possible.

<comment><USER3> It depends on your relationship with your family. What you describe is not always the case.</comment></comment>


Getaround, The AirBnb For Cars, Launches - <AUTHOR> http://techcrunch.com/2011/05/24/getaround-the-airbnb-for-cars-finally-launches/ <comment><USER2> I cannot imagine that they are going to be able to carry insurance that will actually cover "anything [that] were to happen to the car".

Sounds like a great concept but, as always, the devil is in the details.</comment>


British schools are falling for the pseudoscience of Brain Gym. - <AUTHOR> http://www.guardian.co.uk/commentisfree/2008/apr/07/education

<comment><USER2> Ben Goldacre's 'bad science' column in the guardian has been going after this for years. It's good, old fashioned campaigning journalism, and after five years might actually be having some effect. As he puts it: 'The very same person who tells your child that blood is pumped around the lungs and then the body by the heart, is also telling them that when they do The Energizer exercise then "this back and forward movement of the head increases the circulation to the frontal lobe for greater comprehension and rational thinking"'.[<http://www.badscience.net/?p=613>]

On the other hand, a glance at google shows how deep the problem goes: <http://www.google.com/search?q=%22brain+gym%22+site%3Agov.uk></comment>


Bitcask: because you needed another local key/value store - <AUTHOR> http://blog.basho.com/2010/04/27/hello,-bitcask/

<comment><USER2> Some perf numbers:

Bitcask vs. InnoDB (by Dave Smith): <http://twitter.com/dizzyco/status/13014285189>

Bitcask vs. Tokyo Cabinet (by Jeff Darcy): <http://pl.atyp.us/wordpress/?p=2868></comment>


Electricity Transmitted to Auto Tire Through 10cm-thick Concrete - <AUTHOR> http://techon.nikkeibp.co.jp/english/NEWS_EN/20120706/227082/ <comment><USER2> I just can't help but think that Nikola Tesla was right - he had the same idea (and possibly the means to do it) a full century ago...

We'd also be driving electric cars today if not for the oil and auto industries (read up on how they buried the electric transportation in its infancy)...

<comment><USER3> citation needed

<comment><USER2> <http://en.wikipedia.org/wiki/Who_Killed_the_Electric_Car%3F>

[http://books.google.be/books?id=MyZo7EhN8-MC&pg=PA58&...](http://books.google.be/books?id=MyZo7EhN8-MC&pg=PA58&dq=Sloan+1922+general+motors+streetcar&hl=en&ei=ZG1DTuvXFMPrmAX0_cmvCQ&sa=X&oi=book_result&ct=result&redir_esc=y#v=onepage&q=Sloan%201922%20general%20motors%20streetcar&f=false)

<http://earlyelectric.com/carcompanies.html>

[http://www.wired.com/autopia/2010/06/henry-ford-thomas- ediso...](http://www.wired.com/autopia/2010/06/henry-ford-thomas-edison-ev/)

Granted, it was cheaper to go with oil-powered cars because of the incentives, but in the long run, we would've been better off with electric.

Oh well, more opportunities for innovative business today :-)

<comment><USER4> I think you missed the part where battery technology one century ago wasn't as advanced as it is today.

<comment><USER5> Copper was much cheaper, though!

<comment><USER6> Not to mention demand and continued production drives research and improvement, so it would have been self reinforcing.

</comment></comment></comment></comment></comment></comment><comment><USER7> "To put the technology into practical use, the electric power needs to be increased by 100 times. But the group said that the parts needed for it are relatively cheap and that there is no major problem."

I have to admit some skepticism about this claim. 2-3 orders of magnitude increase in output power delivered may very well expose non-trivial problems. I.e. making the effort of scaling this technology up more than just linear.

<comment><USER8> Not to mention the need to rip up and replace all the road surfaces. At least partially.

<comment><USER9> They seem to do that every other year in bad weather areas :-)

</comment></comment></comment><comment><USER10> Article says they need 50W * 100 = 5KW. That's reasonable as that's roughly the amount of energy you need to keep a car moving at road speed.

And with a quoted ffficiency of 80-90% this is equivalent to 10-20% being lost probably as HEAT into the roadway. So that means we are turning our roads into long low power electric hotplates.

Okay perhaps it's not that extreme and possibly less waste heat than an IC engine. Maybe the idea isn't so crazy in a densely populated city.

<comment><USER11> But combustion engines operate somewhere around 50% efficiency? (i dont remember exactly, but I remember it being pretty bad). So the 10-20% lost through the road and the (presumably) small amount lost through electric, battery-less cars may actually be less overall than from combustion engines.

I am assuming that electric engines dont generate much heat if they dont have batteries and assuming that roads dont have the power on unless theres a car nearby.

</comment></comment><comment><USER12> Wireless power transmission seems like a great idea, but it can't be billed by usage, and kills everyone who has a pacemaker.

<comment><USER13> Is there a reason why you can't legislate that every electric car that can use ubiquitous wireless charging be fitted with a meter that reports usage, just like house have?

</comment></comment><comment><USER14> It seems to me that the obvious application here would be wireless charging parking spaces, not electric roads.</comment>


Why We're Switching to gRPC - <AUTHOR> https://eng.fromatob.com/post/2019/05/why-were-switching-to-grpc/ <comment><USER3> Yeah. Easy things are easy with most technologies... It's only after a while that you start to see the 'problems'.

With grpc... It's designed by Google for Google's use case. How they do things and the design trade-offs they made are quite specific, and may not make sense for you.

There are no generated language interfaces, so you cannot mock the methods. (Except by mocking abstract classes, and nobody sane does that, right)

That's because grpc allows you to implement whatever methods you like of a service interface, and require any fields you like - all are optional, but not really, right.

Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.

Load balancing is done by maintaining multiple connections to all upstreams.

The messages dont work very well with ALB/ELB.

The tooling for web clients was terrible ( I understand this may have changed )

The grpc generated classes are a load of slowly compiling not very nice code.

Like I say, if your tech and business is like Google's ( it probably isn't) then it's a shoe-in, else it's definitely worth asking if there is a match for your needs.

<comment><USER4> > With grpc... It's designed by Google for Google's use case. How they do > things and the design trade-offs they made are quite specific, and may not > make sense for you.

Agreed. It's always important to try to pick technologies that 'align' with your use-cases as well as possible. This is easier said than done and gets easier the more often you fail to do it well! I do think people will read "for Google's use case" and hear "only for Google's scale". I actually think the gRPC Java stack is pretty efficient so it "scales down" pretty well.

I want to skip over some of what you're saying to address this:

> Things that you might expect to be invalid, are valid. A zero byte array > deserialised as a protobuf message is a perfectly valid message. All the > strings are "" (not null), the bools false, and the ints 0.

Using a protobuf schema layer is wayyyy nicer than JSON blobs but I agree that it is misconstrued as type safety and validation. It's fantastic for efficient data marshaling and decent for code generation but it dosn't solve the "semantic correctness" side of things. You should still be writing validation. Its a solid step up from JSON not a panacea.

<comment><USER5> JSON has a bunch of schema systems, including Open API which is a repackaging of Swagger with some extra stuff and is also endorsed by Google.

Do you consider protobuf superior to those alternatives for web-based (rather than server to server) projects?

<comment><USER4> I spend all my time server to server so I don't feel qualified to give real advice.

My impression is that if you're going to talk to a browser, that edge stands to gain much more from conforming to HTTP standards. If your edge is more "applicationy" and less "webpagy" then maybe a browser facing gRPC (or GraphQL?) might be more appealing again.

As to the other JSON schema systems, I kinda wish one of them won? It feels like a lot of competing standards still. Not really my area of expertise.

<comment><USER6> There are a couple gRPC implementations for the browser[0](officially supported), but it seems to require quite a bit of adaptation, and looked pretty complicated to set up.

[0] [https://grpc.io/blog/state-of-grpc-web/](https://grpc.io/blog/state-of- grpc-web/)

</comment></comment></comment></comment></comment><comment><USER4> This article comes at a good time because I've been exploring the OpaenAPI vs. gRPC for a codebase that presently uses neither. Evaluating technology feels like a lot of navel gazing, so it's nice to hear other's experiences even if their uses don't line all the way up with ours.

Disclaimer: Java fanboy bias. For services internal to a company, I think gRPC is an all around win. If you need to talk to browsers integrations, I don't have as many opinions.

Personally, I really prefer working at the RPC layer rather than at the HTTP layer. It's OOP! It's SOA! Pick your favorite acronym! HTTP's use as a server protocol (as opposed to a browser) is mostly incidental. It works great but most of the HTTP spec entirely inapplicable to services. I like named exceptions to 200 vs 5xx 4xx error codes. Do I _really_ care about GET, PATCH, PUT, HEAD, POST for most of my services when all of my KV/NewSQL/API-over-DB services have narrower semantics anyway.

Out of band headers are nice though.

Between protobufs, http2, and a fresh, active server implementation we see pretty solid latency and throughput improvements. It's hard to generalize but I suspect many users will. Performance isn't the only driving factor but it's nice to start from a solid base.

I'm sure missing all the tools like curl and friends is an annoyance, but I like debugging from within my language, and in JVM land at least it's been easy enough.

<comment><USER7> Have you considered GraphQL? Lots of overlap with gRPC, but much more web- friendly. Much better support for optional vs. requires data, too. And comes with server push, replacing the need for WebSockets/SSE.

Only downside I can think of is that there's no analogous mechanism to gRPC streams; you have to implement your own pagination.

<comment><USER4> I havn't looked into GraphQL much at all, so correct me if I'm mistaken.

From what I understand of it, the big idea is that instead of passing parameters from the client to the server and fully implementing the query logic, stitching, and reformatting etc. on the server side, you now have a way to pass some of that flexibility out to the client. Instead of updating both the server and the client as uses change, more can be done from the client alone.

I spend most of my time on the infra side of things and rarely if ever make my way out to the browser so I can't speak to WebSockets/SSE or web friendliness. Being the "backend-for-backend" I just prefer being more tight-fisted about what my clients can and can't do. I mostly deal with internal customers with tighter SLAs so I like to capacity plan new uses.

Maybe I'm just old fashioned.

</comment></comment></comment><comment><USER8> I recently chose gRPC as a communication protocol between two devices (sort of IoT).

Until now it works perfectly as expected. The C++ code generator provides a clean abstraction plus it saved a lot of time (both in programming and debugging). The gRPC proto file syntax also nudge you in the right direction wrt protocol design.

When trying to "sell" gRPC it helps that there are generators for plenty of languages and it's backed by a major company.

<comment><USER9> I wish that tooling around generating protoc into stubs and client libraries was simpler. I wish there was a single command I could run and turn large collection of proto files into libraries for "all" languages (python, java, C++, Node package, etc). Unfortunately there's no universal approach to this.

<comment><USER10> This seems like an odd requirement. Are you trying to generate stubs for your API users ahead of time? This will likely not work as generated stubs evolve in lockstep with protoc and runtime support libraries, and thus are not guaranteed to work across discrepant versions. Thus, stub code should be generated alongside the consumer/client. It also likely shouldn't be committed into a VCS.

<comment><USER9> It would be done in CI. Generate stubs -> package/compile -> push to internal package repo.

This way your protocol for your infrastructure is just another library.

<comment><USER10> Having an explicit 'create client library by generating/compiling proto stubs' is generally also bad mojo from my experience, unless you're also abstracting API stability and service discovery. If not, it will be unnecessarily painful to make a change to either the service discovery method or a non-backwards- compatible proto change, as you will have to lockstep both the service rollout, the library build and the client bump.

</comment></comment></comment></comment></comment><comment><USER11> The truth is gRPC, like kubernetes, was built with decades of lessons of RPC framework inside a container oriented distributed environment; and more importantly, gRPC is the blessed framework inside Google as well, meaning it's qualified to power the largest and most complex distributed systems in the world (I think it'd safe to omit 'one of' here), which in comparison is not the case for kubernetes.

Addition: Borg and kubernetes are designed with similar goals but different emphasis. They are like complementing twins had different personalities. For this I recommend Min Cai's Kubecon'18 presentation about peleton [1], the slide is titled "comparison of cluster manager architecture".

[1] [https://kccna18.sched.com/event/GrTx/peloton-a-unified- sched...](https://kccna18.sched.com/event/GrTx/peloton-a-unified-scheduler- for-web-scale-workloads-on-mesos-kubernetes-min-cai-nitin-bahadur-uber)

<comment><USER12> Wait, I don't get it. Kubernetes:Borg::gRPC:Stubby. Google uses gRPC internally to the same extent that they use Kubernetes internally, i.e. hardly at all.

<comment><USER13> This analogy is very misleading. Kubernetes is probably never going to run any real workload internally at Google, but gRPC powers all external APIs of Google Cloud, and increasing other Google properties (e.g. ads, assistant), used by mobile apps like Duo and Allo, and have some big internal service use cases. The reason Stubby still dominates internally is simply taking lots of time to migrate to gRPC that might be hard to justify, but I do see gRPC being used very widely internally at Google; it's simply a matter of time. I don't see that happening to Kubernetes; it's a joke when compared to Borg.

Google aside, many other companies like Dropbox rely on gRPC extensively to successfully run infrastructure: [https://static.sched.com/hosted_files/grpconf19/f7/Courier%2...](https://static.sched.com/hosted_files/grpconf19/f7/Courier%20—%20gRPC%20Conf%202019.pdf)

<comment><USER14> I work at Google and my team has real workloads running on Kubernetes.

There's plenty of internal teams that use GCP. Increasingly this might be the direction things are heading.

<comment><USER13> GCP itself is a job on Borg. ;)

<comment><USER11> That's not true. GCE uses Borg very differently than normal Google internal systems, which you can imagine is quite natural as they are reserving different customers. GCS and other system, in turn, also differ wildly than GCE. when you talk about GCP as a whole, it becomes impossible to summarize in a few statement, and I doubt there is anyone on earth who is capable to describe it coherently even without time constraint.

<comment><USER13> What I said (GCP runs on Borg) is absolutely and technically correct, affirmed by your own comment, which highlights the power and flexibility of Borg. The point being no one[1] at Google relies on Kubernetes for raw cluster management capabilities at scale. They might use it for other things that can make deployment more friendly in some scenarios. (This doesn't make Kubernetes a bad system by any means, just quite different and not a substitute for Borg whereas gRPC is a direct substitute for Stubby). This debate is better argued in your own eng-misc@ and not on a public forum.

[1]: no-one that we care. At Google this is obviously always incorrect. There's always that someone who uses weird things like mongoDB and AWS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I'd needed RPC framework for few of my projects but every time I'd considered gRPC, I ended up walked away from it. The big issue is that gRPC has a huge amount of dependencies and it tries to a lot of things, many of them might be irrelevant for you but would cause extra headache anyway. When all need is just serializing your stuff and send over the wire, there are much better lightweight frameworks. For C++, I think RpcLib is one of the best. It doesn't even require maintaining .proto file, do "compile" of schems every time you change something, etc. The moral of the story is that always look around instead of just going for the most popular solution first.

</comment><comment><USER12> A couple of subtly wrong points in the article. Firstly gRPC payload can be anything, needs not be an encoded protocol buffer. Secondly there's not a whole lot of "validation" going on in the protobuf codec. Basically any fundamentally correct buffer encoded as message A will decode successfully as message B for any B. If there are unknown fields they are silently consumed. If there are missing fields they are given the default values and there is no "required" in proto3. So there is significantly less safety, and significantly more flexibility, in gRPC than people generally realize.

<comment><USER16> "Basically any fundamentally correct buffer encoded as message A will decode successfully as message B for any B."

This is incorrect. I suspect you're overextending proto3's treatment of unknown fields to include discarding incorrectly typed fields too. If A has field 1 types as an int, and B has field 1 typed as a string, an A message with field 1 set will not parse as a B message. However, if the A message has no fields set, or sets a field number unknown to B, that could parse successfully with "leftover" unknown fields.

<comment><USER12> Ok but these messages are isomorphic on the wire:

      message enc {
        int foo = 1;
        SomeMessage bar = 2;
      }

      message dec {
        bool should_explode = 1;
        string why = 2;
      }

You can successfully decode the latter from an encoding of the former.

<comment><USER17> Minor nit, but not necessarily. For basically all values of SomeMessage, dec should fail to parse due to improperly encoded UTF8 data for field 2 (modulo some proto2 vs. proto3 and language binding implementation differences).

Change field 2 to a bytes field instead of a string field and then yes.

<comment><USER12> I should mention that I consider this a feature not a bug. The isomorphism permits an endpoint to use 'bytes submessage_i_dont_need_to_decode' to cheaply handle nested message structures that need to be preserved but not inspected, such as in a proxy application.

</comment></comment></comment></comment></comment><comment><USER18> Rich Hickey, the creator of Clojure, gave a talk with some very relevant points in this space (The Language of the System): [https://www.youtube.com/watch?v=ROor6_NGIWU](https://www.youtube.com/watch?v=ROor6_NGIWU)

<comment><USER19> "gRPC is great because most systems just glue one side effect to another side effect, so what's the point of packaging that into REST" – I think a HN comment from a googler

The great thing about Clojure is that you can make holistic systems that are end-to-end immutable and value-centric, which means the side effects can go away, which means gRPC stops making sense and we can start building abstractions instead of procedures!

</comment></comment><comment> nevi-me I'm yet to see enough services expose a gRPC endpoint, at least other than Google. That'll keep the perception of adoption s/low.

I'm writing this as I take a break from working on a polyglot project made up of Kotlin, Rust, Node, where we use gRPC and gRPC-web. We're slowly stealing endpoints from the other services/languages to Rust.

Without focusing on the war of languages, the codegen benefits of protobufs have made what used to be a lot of JSON serde much easier.

<comment><USER20> Can you point to a single public Google-run gRPC service? I was under the impression that all connections into Google are proxied by GFE (Google Front- End) servers to internal servers running the Stubby RPC server code. GFE is definitely not running gRPC server code. I don't believe a gRPC endpoint could pass Google's own Production Readiness Review process.

<comment><USER21> I've seen Google endpoints available over gRPC over the last few years. Many, if not most, of the Cloud endpoints are directly documented as being available over gRPC[0]. For others, like Google Ads, a peak at the client libraries show it's using gRPC[1] as well.

[0]: [https://cloud.google.com/pubsub/docs/reference/service_apis_...](https://cloud.google.com/pubsub/docs/reference/service_apis_overview#grpc_api)

[1]: [https://github.com/googleads/google-ads- java/blob/master/goo...](https://github.com/googleads/google-ads- java/blob/master/google- ads/src/main/java/com/google/ads/googleads/lib/GoogleAdsClient.java#L20)

<comment> nevi-me Yes, this. A lot (based on my last interaction 2 yrs ago) of Google's SDKs are convenience methods that hide gRPC behind. If you use a language that doesn't have an SDK, you can mostly connect directly to their rpc endpoints.

</comment></comment></comment></comment><comment><USER22> hey, hey! have you known about this new "webservices" stuff? with SOAP you can call remote code as it is here! and with WSDL you can create automatically the client!

<comment><USER23> Short summary of web services:

Phase 1: Ad hoc, free-for-all chaos.

Phase 2: SOAP tries to bring order. It fails mainly because the "S" ("Simple") is a lie.

Phase 3: Pendulum swings hard toward simplicity with HTTP plus JSON plus nothing else, thanks.

Phase 4: Things shift possibly more toward the middle (a little structure), but none of the competing systems have become obvious winners.

<comment><USER24> Most things in life seem to change like a pendulum learning from previous swings, slowly converging to a healthy middle. Extremes are useful since they give perspective and attractive since they're easy to grasp.

</comment></comment></comment><comment><USER25> Apart from "well google (created|uses) it" I don't really get the benefit of gRPC compared to any other rpc, eg jsonrpc or even xmlrpc, both of which are fairly static, open specifications for a way to communicate, rather than actual releases of a library that apparently has a new release every 10 days or so.

<comment><USER26> Binary. Streaming. Strongly typed (with caveats). There's a whole article about the advantages/differences linked from the top of this page.

<comment><USER27> > My API just returned a single JSON array, so the server couldn't send > anything until it had collected all results.

Why can't you stream a JSON array?

Edit: Here's a (hastily created and untested) node.js example, even:

        class JSONArrayStream extends Transform {
            constructor() {
                super({readableObjectMode: false, writableObjectMode: true});
                this.dataWritten = false;
            }

            _transform(data, encoding, callback) {
                if (!this.dataWritten) {
                    this.dataWritten = true;
                    this.push('[\n');
                    this.push(JSON.stringify(data) + '\n');
                } else {
                    this.push(',' + JSON.stringify(data) + '\n');
                }
                callback();
            }

            _flush(callback) {
                this.push('\n]');
            }
        }

<comment><USER25> you'd probably need to do some tricks to get it to parse in a browser.

Editing, because I can't reply: I _was_ specifically going to mention SSE/EventSource but expected an immediate "not everything is a browser" response.

Editing the 2nd: yep, that's kinda what I meant by "tricks" - <USER2> splitting out chunks to pass to the json parser.

<comment><USER27> See my edited example above; you can stream data to this, it'll stream nicely to the browser. This uses "\n"s at the end of every line, which means you can write a very simple streaming parser client side, because you can just split the input at "\n," to get nice JSON bits, but there's certainly JSON streaming libraries on NPM that will parse this for you more "properly". And, it parses with a normal JSON parser too.

</comment></comment></comment></comment></comment><comment><USER28> The article says that one of the advantages of gRPC is streaming and that JSON wouldn't support streaming.

That's however just an implementation detail. JSON can easily be written and read as a stream.

Switching your whole architecture, dealing with a binary protocol and the accompanying tooling issues just because of your choice of JSON parser feels like total overkill.

JSON over HTTP is ubiquitous, has amazing tooling and his highly debuggable. Parsers have become so fast that I feel they might even have the opportunity to be faster than a protobuf based solution.

Finally I don't buy the argument about validation. You have to validate input and output on the boundaries no matter what.

Even when your interface says "this is a double", it says nothing about ranges (as seen in the article where valid ranges were specified in the comment) for example.

<comment><USER29> > Parsers have become so fast that I feel they might even have the opportunity > to be faster than a protobuf based solution.

Not even close. Event new JSON serializers/deserializers aren't magic. Protobuf is a LOT easier to parse, so it's naturally a LOT faster.

First two duck results for "json vs protobuf benchmark":

[https://auth0.com/blog/beating-json-performance-with- protobu...](https://auth0.com/blog/beating-json-performance-with-protobuf/)

[https://codeburst.io/json-vs-protocol-buffers-vs- flatbuffers...](https://codeburst.io/json-vs-protocol-buffers-vs- flatbuffers-a4247f8bda6f)

<comment><USER30> The first link shows a mere 4% margin when talking to a JavaScript VM.

Even at a 5x improvement, most projects will never reach a point where the transport encoding is a bottleneck. Protobuf has a lot going for it (currently using in a project) but can't be sold on speed alone.

<comment><USER31> Is the JSON parser implemented natively, or in JS? It may not be apples-to- apples.

<comment><USER32> > Is the JSON parser implemented natively, or in JS? It may not be apples-to- > apples.

True, but if you're wanting an implementation you can use in Javascript running in the browser, it may accurately reflect reality. You have a high- quality browser-supplied (presumably native) implementation of JSON available. For a protobuf parser, you've just got Javascript. (You can call into webassembly, but given that afaik it can't produce Javascript objects on its own, it's not clear to me there's any advantage in doing so unless you're moving the calling code into webassembly also.)

I don't think browser-based parsing speed is important though. It's probably not a major contributor to display/interaction latency, energy use, or any other metric you care about. If it is, maybe you're wasting bandwidth by sending a bunch of data that's discarded immediately after parsing.

</comment></comment></comment></comment></comment><comment><USER33> There's also [https://github.com/uw- labs/bloomrpc/blob/master/README.md](https://github.com/uw- labs/bloomrpc/blob/master/README.md) which is kinda like Postman but for gRPC. I didn't see it mentioned in the Caveats section of the post so maybe useful to someone else too.

</comment><comment><USER34> gRPC is great, but my issues with it are debugging and supporting the browser as a first class citizen.

We've been working hard on OpenRPC [0]. An Interface Description for JSON-RPC akin to swagger. It's a good middle ground between the two.

[0] [https://open-rpc.org](https://open-rpc.org)

<comment><USER31> Have you looked at gRPC-Web?

<comment><USER35> I have mixed feelings about gRPC-Web, and welcome alternatives. Setting up a proxy with any sort of non-standard config can be a pain, gRPC-Web doesn't translate outbound request data for you which can get ugly[0], and your service bindings may or may not try to cast strings to JS number types which silently fail if over MAX_SAFE_INTEGER.

[0] Instead of passing in a plain object, you build it as such:

      const userLookup = new UserLookupRequest();
      const idField = new UserID();
      idField.setValue(29);
      userLookup.setId(idField);
      UserService.findUser(userLookup);

The metadata field doesn't seem to mind though...

</comment></comment></comment><comment><USER36> I'd just like to say I appreciate the writing at the beginning of the article.

"While more speed is always welcome, there are two aspects that were more important for us: clear interface specifications and support for streaming."

This offers a quick exit for anybody who already knows about these advantages.

</comment><comment><USER37> one fundamental issue with grpc seems to be that every request for a given service ends up either creating a thread or use an existing one from a pool- of-threads. ofcourse, you cannot limit the number of threads because that will lead to deadlocks.

i _suspect_ for google-scale it should all be fine, where available cpu's are essentially limitless, and consistency of data gets handled f.e. due to multiple updates etc. at a different layer.

writing safe, performant, multi-threaded code in presence of signals/exceptions etc. is non-trivial regardless of how your 'frontend' looks like. async-grpc is quite unwieldy imho.

i have heard folks trying grpc out on cpu-horsepower-starved devices f.e. wireless-base-stations etc. and running into aforementioned issues.

</comment><comment><USER38> gRPC isn't a requirement for response streaming (as is quoted as one of the main reasons for doing the migration). That can all be achieved with http/json using chunked encoding. In fact, that's what the gRPC-gateway (http/json gateway to a gRPC service) does [https://github.com/grpc-ecosystem/grpc- gateway](https://github.com/grpc-ecosystem/grpc-gateway).

gRPC adds bi-directional streaming which is not possible in http, but the use cases for that are more specialized.

<comment><USER6> Sure, the actual transfer will be streamed, but most JSON clients wait for the entire response before firing your callback. As far as I know there isn't even a commonly used spec for partially reading a JSON document.

</comment></comment><comment><USER39> Great to see people using GRPC, but this article doesn't state anything that the actual grpc.io website doesn't, except for the OpenAPI comparison.

</comment><comment><USER40> I don't see the article answering the "why" question. It was just "We don't like what we where using, so we tried gRPC"

</comment><comment><USER41> Another alternative is Thrift. It got lots of language bindings and the servers superb.

</comment><comment><USER42> IMHO the only reason to use HTTP for services today is caching.

</comment><comment><USER43> Parsing speed shouldn't be a factor in deciding. Parsing protobufs on the browser is going to be way slower than using a native json parser and even on the server, there are java libraries that are much faster than protobufs, e.g. [https://jsoniter.com/](https://jsoniter.com/)

That's why formats like FlatBuffer where written; however parsing is likely not going to dominate your application, so other factors should influence your decision instead.

<comment><USER44> > on the server, there are java libraries that are much faster than protobufs

Be careful not to back broad arguments with outlier benchmarks.

In general, it is plainly true that JSON is much more computationally difficult to encode and decode than Protobuf. Sure, if you compare a carefully micro-optimized JSON implementation against a less-optimized Protobuf implementation, it might win in some cases. That doesn't mean that Protobuf and JSON perform equivalently in general.

<comment><USER43> What is the reason not to use the micro optimized JSON implementation if parsing becomes your bottleneck?

<comment><USER44> I don't think I said that?

<comment><USER43> My point is that json is always "fast enough". Either you don't care about parsing speed and can use what is most ergonomic or you do care and you'll use an optimized library.

You'll never need to move to protobufs due to parsing speed.

</comment></comment></comment></comment></comment><comment><USER45> > When you use a microservice-style architecture, one pretty fundamental > decision you need to make is: how do your services talk to each other?

Problems I don't have when using Erlang/Elixir umbrella apps + OTP.

</comment><comment><USER46> answer: for trivial reasons. too bad he didn't dig deeper.

</comment><comment><USER47> Does anybody remember reading an article along the line "we use X because it's cool and trending and we are cool people?" Not saying it's the case here, but did anybody honestly admitted in an article that they used a technology because it makes them look cool?

I do remember reading quite a lot of articles about the inverse of this: "we don't hire people using Windows/IDEs/ because it says a lot about them, a craftsman should chose his tools wisely, ...", but never the positive.

<comment><USER25> I got a very strong "kool aid" vibe from this.

I don't remember any "we don't hire people on Windows/using an IDE" (the last part would be particularly weird IMO), but I wouldn't be surprised if somewhere said "if you want to use Windows you're on your own (support wise) and if it becomes a time sink you switch or find work elsewhere".

I've supported (in terms of dev environment/tooling) people on Macs, Windows and Linux. Windows by far had the weirdest issues to solve/avoid.

<comment><USER47> > _I don't remember any "we don't hire people on Windows /using an IDE"_

Two famous examples:

[http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...](http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html)

> _If you are a startup looking to hire really excellent people, take notice > of .NET on a resume, and ask why it's there._

[https://blog.expensify.com/2011/03/25/ceo-friday-why-we- dont...](https://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire- net-programmers/)</comment></comment></comment>