Are cryptocurrencies about to go mainstream? - <AUTHOR> https://www.theguardian.com/technology/2017/jul/01/cryptocurrencies-mainstream-finance-bitcoin-ethereum <comment><USER2> Not until they can really explain to the average Joe why cryptocurrencies are such a good thing.

Because at the end of the day, privacy is nowhere near as important to many people are it arguably should be, and trying to market cryptocurrencies as 'independent from government control' is likely a losing proposition.

Same with most of the reasons involved I've seen invoked for why to use Bitcoin or the likes online. They're logical, but they're also likely to fly straight over the heads of most of the population.

Add the deliberate way that governments and the media try and portray cryptocurrencies as being used for 'criminal' purposes (which has given these currencies a bit of an image problem), and you've got something that seems very unlikely to ever truly go mainstream.

<comment><USER3> Cash is still more anonymous than cryptocurrencies.

<comment><USER4> The anonymity is overrated anyway. At some point you want to turn your currency into tangible benefit like food or a car or drugs or whatever. At that point it isn't hard to connect the anonymous wallet with the guy who bought the new Ferrari out of thin air.

<comment><USER5> If you spent it all on drugs it would be anonymous.

</comment></comment></comment></comment><comment><USER6> Yes, and 2017 is the year of the Linux Desktop. We can barely get stores to use EMV/chip card readers, so I'd have to say no.

<comment><USER7> A little aside, I've been using Linux as primary workstation for seven years now. It works great, so I've never understood this "year of the desktop" meme.

Now, OpenBSD is another matter entirely...

<comment><USER8> On the slashdot back in the late 90s there were breathless articles all the time about how this was going to be the year that the Linux Desktop was going to sweep across the world and surely M$ was doomed.

Two decades later Microsoft is doing quite well and Linux still accounts for a small percent of personal computers.

<comment><USER9> >small percent of personal computers.

I certainly consider my phone to be a personal computer nowadays.

It has a few orders or magnitude more powerful hardware and can do things my first few PCs could not do.

Linux is certainly doing very well there. ;) GNU/Linux might not be, but that's a different story.

<comment><USER10> A phone OS marketed by Google that happens to be derived from Linux code is to "GNU/Linux is going to kill Microsoft and big corporations flexing their power in the software industry" what a hypothetical cardless payment technology run by Paypal that uses a blockchain somewhere on the backend is to "Bitcoin is going to kill fiat currency and the banking oligarchy"

</comment></comment></comment></comment></comment><comment><USER11> This article can be summed up by the bottom page quote "Prices right now aren't being driven by network usage, they're being driven by speculation that tokens are going to appreciate. It's a gold-rush mentality."

Also everytime I see yet another Ethereum story I think of [http://www.paulgraham.com/submarine.html](http://www.paulgraham.com/submarine.html)

<comment><USER12> Apparently GPU prices are being distorted by this gold rush. Gamer forums are learning what Etherium is these days.

<comment><USER13> And then Ethereum is going to go POS and there won't be mining anymore. They'll move on to other GPU-mineable coins and the ecosystem will continue to grow :).

BTW: Asus is making mining specific graphic cards to try and relieve the pressure on gaming cards - 10k minimum order.

<comment><USER14> Believe it when I see it. PoW is the only consensus mechanism with a track record right now.

</comment></comment></comment></comment><comment><USER15> The bitcoin community is now arguing to the point of death threats whether it's better to scale by adding data outside of the blocks and then making slightly larger blocks, or by adding data outside of the blocks and then adding more data outside of the blocks.

And both sides are accusing the other side of being authoritarian, for centralization, and basically being even a worst enemy than The State, which is like the worst thing ever. In the meantime, no scaling solution is being implemented, because they are too busy blocking the other side from implementing their solutions.

<comment><USER16> If you only look at Bitcoin now then you are missing out on a lot of what is going on with cryptocurrencies.

But I agree, Bitcoin had a standstill for 3 years because of nitpicking over a simple factor two scaling solution. This could end badly for Bitcoin if they don't get their act together.

</comment></comment><comment><USER17> This is the exact article that starts appearing about 6 to 12 months before a huge bust within a particular market. I'd be hugely surprised if there isn't a huge rise over the next 4 months followed by a collapse. You should be looking for where you think the bottom of the market is because it's too useful not to go up again (it'll be around $800, I'm a time traveller). The top could be as high at $6000 though before everyone realises how absurd and manipulative this all is...

<comment><USER18> > I'd be hugely surprised if there isn't a huge rise over the next 4 months > followed by a collapse.

It's because bitcoin is a pyramid scheme.

<comment><USER19> > Bitcoin is a pyramid scheme

Why do you say this? I am certainly not a cryptocurrency expert, but it seems to me that BTC provides real value, in that it is an accepted currency and also in that it distributes the means of control over a far greater area than traditional government-backed currency.

Pyramid scheme reward members for recruiting new members without providing any value. Like all commodities and currencies, BTC increases in value the more people think it is valuable, but if that is how you define a pyramid scheme then gold futures, stocks, and the US dollar are pyramid scheme as well.

</comment></comment></comment><comment><USER20> I was very sceptical when I first heard about Bitcoin but now I do believe that cryptocurrencies have some intrinsic value as a payment system.

The Bitcoin brand itself has intrinsic value which is related to its popularity. Consumers have always been willing to pay a premium to deal with specific brands which they know and trust.

When people buy Coca-Cola, they're not paying for brown sugar-water.

I do think that a lot of Bitcoin's current value is driven by the black market for money laundering but its distributed nature puts the government in a difficult position when it comes to regulation.

If the government tried to delegitimize Bitcoin and shut down all big miners and exchanges, it would just fragment the Bitcoin network further and shift its control into the hands of smaller, shadier players who would be much harder to regulate.

There has always been a market for virtual currencies but because they used to be centralized, the government was always able to step in and shut them down (e.g. Flooz, e-gold...) Cryptocurrencies might actually solve that problem.

</comment><comment><USER21> The extremely simple answer is: No.

Cryptocurrencies require significantly more power to verify a single transaction[1]. The ability to scale to a meaningful size does not exist now. They need to improve efficiency by 3-4 orders of magnitude to be competitive.

[1] [http://digiconomist.net/bitcoin-energy- consumption](http://digiconomist.net/bitcoin-energy-consumption)

<comment><USER22> The article is misleading, as it compares Bitcoin power consumption to VISA, which is a payment processor.

Bitcoin is a sound money system, so the proper comparison is all the people, buildings, vehicles, weapons, etc used in the creation and protection of the global fiat currency system.

I don't know for sure, but I bet fiat costs dwarf the $640M or so that Bitcoin costs.

<comment><USER23> Also worth mentioning that other crypto-currencies do not require mining (proof-of-work). They instead use "proof of stake" or "Proof of burn" systems which would use less power. Things are still evolving very fast in this space, so you never know what's around the corner!

</comment></comment></comment><comment><USER24> If a headline is a question, the answer is always no. Otherwise, the headline would not be stated as a question, but as an assertion of fact.

<comment><USER25> This is known as Betteridge's Law: [https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

</comment></comment><comment><USER26> We will see some major drama in this space.

Take EOS for example... it's a company that's basically a Bitshares fork and it's raising possibly a half to one billion dollars on the promise to deliver something different in one year.

Their purchase agreement promises nothing and is highly concerning: [https://eos.io/purchaseagreement/EOS%20Token%20Purchase%20Ag...](https://eos.io/purchaseagreement/EOS%20Token%20Purchase%20Agreement%20-%20June%2022,%202017.pdf)

What investor would give a startup half billion dollars in seed money without even an MVP?

In the end it all comes down to: will the team deliver or not? The startups fail at 95% + money corrupt teams.

If the team members done 0% work so far and are rich already, what's their motivation like? Why push through the hard times and drama that will inevitably happen if you can just bail out right now and take the money

<comment><USER27> As someone who believes in cryptocurrencies, let me just say, wow, this ICO is just absurd. From that purchase agreement,

"EOS TOKENS HAVE NO RIGHTS, USES OR ATTRIBUTES. The EOS Tokens do not have any rights, uses, purpose, attributes, functionalities or features, express or implied, including, without limitation, any uses, purpose, attributes, functionalities or features on the EOS Platform. The company does not guarantee and is not representing in any way to Buyer that the EOS Tokens have any rights, uses, purpose, attributes, functionalities or features."

</comment></comment><comment><USER28> No. My dad still calls them "bitcorns." He heard about them on NPR.

It's anecdotal, but cryptocurrencies practically don't exist in my non tech- related social circles.

<comment><USER29> Can confirm. Regular people who are not interested in technology has no idea what they are, or even that they exist.

<comment><USER30> Email. 1990. Conversation in some college.

<comment><USER31> Email is a drastic improvement on the way people communicate. It is orders of magnitude faster, for example, cheaper for the user and more convenient.

Bitcoin is slower, more expensive and harder to use than the existing financial instruments. It is censorship resistant though so you can use it to pay people online when the government does not want you to pay these people.

<comment><USER30> > It is censorship resistant though so you can use it to pay people online > when the government does not want you to pay these people.

Only cash is "censorship resistant". As a technologist, this is either an embarassing statement, or, a hopeful data point on the durability of 'hits-it- on-the-nail' technology, such as cash, or paper and ink. (Yes, I'm getting bullish on paper pamphlets ..)

<comment><USER31> > Only cash is "censorship resistant"

Still not perfect, though. Look at how India swiftly and broadly decommissioned some of the bank notes. It is not too crazy to imagine some nations going a step further and decommissioning all bank notes.

Similarly, the blockchain is not perfectly censorship resistant. You need:

1- decentralized transaction validators

2- privacy

For #1, the jury is still out on if mining will remain decentralized. I tend to believe that there are guardians of this property in Bitcoin-land, and if it ever gets too bad, the blockchain can fork to retain this property.

For #2, Bitcoin does poorly here, and hopefully advances in the tech like ring signatures, confidential transactions, MimbleWimble, TumbleBit, zk-SNARKs, etc. will prove to be practical enough for use.

</comment></comment></comment></comment></comment></comment><comment><USER32> If The Guardian is writing about it — no. The hype is over.

<comment><USER33> The Guardian is a very small corner of the internet, the hype is over when it's all over Facebook walls.

<comment><USER34> Isn't the point of 'about to go mainstream' that they are passed hype and all over Facebook? Mainstream = normalized in this instance.

</comment></comment></comment><comment><USER35> Yes - just like California gold mining went mainstream. I overheard one of my non-tech friends recommended investing in Etherium to another non-tech friend - it made me worry.

At least the recommender actually called it a crypto currency and the other, the recommendee, asked what made it useful.

</comment><comment><USER36> If it was easier to buy and sell them they might. I know people who are interested but due to the difficulty and complexity of buying/storing/selling they havnt yet.

<comment><USER37> To me, obtaining bitcoin (or whatever crypto-currency) has been one of the most challenging aspects of using the currency. It's too hard to obtain. Mining these days isn't that feasible, but even if I could mine bitcoin, I probably wouldn't be able to do it at a rate to fund whatever venture I wanted to pursue. The only alternative is to purchase a crypto-currency with another real world currency, which to me seems to defeat the purpose of not having to depend on central banks or real world currency.

If there was a way for crypto-currencies to handle credit, I think that would greatly increase it's likelihood of replacing real world currencies and central banks--going mainstream. The money we use nowadays is transferable credit and central banks can produce enough to meet the demands of the economy. Crypto-currencies on the other hand are more like gold: there's a limited supply that doesn't meet the needs or demands of the economy.

<comment><USER14> Seems like something that could be at least partially resolved by the lightning network [https://lightning.network](https://lightning.network)

</comment></comment></comment><comment><USER38> Is 2017 the year of widespread PGP adoption?

<comment><USER29> No, you dummy - it's the year of Linux Desktop!

</comment></comment><comment><USER13> I'd say that cryptocurrencies are going mainstream... Bit by bit. /s

</comment><comment><USER39> Call me back when Bitcoin can process as many transactions per second as Visa. Or, heck, even 10% as many transactions.

<comment><USER13> It could be soon!

<comment><USER39> It couldn't, because it's theoretically impossible. That's the joke.</comment></comment></comment>


Ask HN: Did you exploit the twitter follow bug? - <AUTHOR>

I tried it for a bit and since it was working made some of the celebs like @aplusk & @oprah follow me. Did you do something like that as well? <comment><USER2> It appears that Taylor Swift and Mariah Carey have un-followed me. The others that I forced into my followers list are still there though. Kinda disappointed about Taylor, I really thought that she and I would get a lot of value from each-others tweets.

<comment><AUTHOR> It seems Taylor has un-followed me as well. I was also thinking that she could get some value from my cooking tweets.

</comment></comment><comment><USER3> better yet, who did it and then messaged one of the people they made follow them. if i had known earlier i sincerely would have made bill gates follow me and just sent a dm with a quick+ sincere "thank you".

<comment><USER4> How does one tell a quick + sincere "thank you" from a slow and insincere "thank you"?

<comment><USER5> Simply compare the speed and sincerity.

<comment><USER4> Kinda hard in a tweet...

Reminds me of a silly joke:

Mother writing to her son: Dear John, I know you don't read very fast so I'll write this slowly.

</comment></comment></comment></comment><comment><USER6> i used it, yes, but only to test it out. i was too curious not to.

</comment><comment><USER7> Yes.</comment>


Less is exponentially more (2012) - <AUTHOR> http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. <comment><USER2> I find it amusing that there isn't a single word about runtime performance in the whole essay.

In the end, when I code in C++, it's because I believe my code will run faster and generally use less resources, and I'm ready to accept the sacrifices it takes (in terms of my own time) to get there. Does it make me someone for whom software is about "doing it in a certain way" ? Probably. If that certain way is "performance" for problems where it matters, I'm even proud of it.

C++ programmers don't come to Go because it turns out Go doesn't shine on problems where C++ was the answer. Simple as that, and _there 's nothing wrong with that_, as long as Go found its niche and solves some problems relevant to him. I'm not sure I see why Rob Pike needs to be so dismissive.

<comment><USER3> What gets me about MOST of the stuff I read on criticising c++ is the complete disregard for runtime performance. I write software that has to consume billions of messages a day per instance. I've done it in several languages for different purposes. At the end of the day if you implement the same algorithm in c++ it will be faster. I don't care what you think you can do in node.js, but you are wrong. When you have limited resources there is no option save for c and c++. It isn't a big deal, that is currently how we get things done.

People fucking around with distributed web applications are so immune from the specific cost of adding a line of code because rarely is what they are writing executed repeatedly in a tight loop and thus they lose the ability to quickly measure performance impact

<comment><USER4> One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing)

If your code consumes more than 300 cores, you should care about performance. If your code consumes less, you should care about productivity.

Adding cores is easy while adding programmers is hard. Cores scale linearly while programmers don't. So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that.

<comment><USER5> What on earth makes you think that all problems can be scaled out to as many cores as you like? This is exactly the web developer mindset that people are referring to elsewhere in this thread.

<comment><USER6> Well you're trading one kind of B.S. for another kind of B.S.

There's a lot of B.S. that comes with C++, and there's an entirely different kind of B.S. involved with writing things in Java + Hadoop.

Personally I stay out of the C/C++ ecosystem as much as I can because threads are never really going to work in the GNU world because you can't trust the standard libraries never mind all the other libraries.

The LMAX Disruptor shows that if you write code carefully in Java it can scream. They estimate that they could maybe get 10% better throughput in C++ at great cost, but the average C++ programmer would probably screw up the threading and make something buggy, and a C++ programmer that's 2 SD better than the mean would still struggle with cache line and other detailed CPU issues.

The difference between the LMAX Disruptor and the "genius grade" C++ I've seen is that the code for the Disruptor is simple and beautiful, whereas you might spend a week and a half just figuring out how to build a "genius grade" C++ program, taking half an hour each pop.

<comment><USER7> Really, you're trading execution speed for productivity, not "BS for BS" when you use these so-called "web languages". In some cases, there are other concerns such as memory usage or software environment (e.g. trying installing a Java program on a system than doesn't allow JIT compilations).

Some problems can scale out, but only if latency between nodes is low enough and bandwidth is high enough. For example, an MMO server would not function as well if there was a 50 msec ping between nodes. You may or may not have control over that depending on what cloud service you use.

These are real concerns and should not be trivialized as "BS for BS" or "throw more virtualized CPU cores at it". Every problem is different; it should be studied and the best solution for the problem applied.

<comment><USER6> I'm talking about parallel programming, in general, as a competitor to high- speed serial programming.

In that case it is a matter of one kind of BS (wondering why you don't get the same answer with the GPU that you do with the CPU, waiting 1.5 hours for your C++ program to build, etc.) vs another kind of BS (figuring out problems in parallel systems.)

Not all problems scale out like that, but you can pick the problems you work on.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> "C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way.

The issue, then, is that Go's success would contradict their world view."

This, "they can't handle how awesome it is" is kind of a fun rationale and strikes me as plausible, but it would be more interesting to me to hear from some of the stellar c++ programmers at google as to why they aren't interested in switching.

C++ was the first language I really invested in mastering during and after college - it was like, "all I need to do is read these 5 books about how to avoid the pitfalls and use all the powerful tools, and it's amazing!" What really changed my mind was trying other languages (first python) and seeing how immediately productive I could be without so much as skimming through the "dive into python" website. So specifically, I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea.

<comment><USER9> I don't think it takes a C++ expert to point out that the more plausible explanation is simply that Rob Pike is a narcissist.

This is the same guy who said you don't need to know what _I_ know (re: endianness) because _you_ will never write a compiler. Consummate narcissism.

<comment><USER10> Someone I know at google said he was once talking to Rob Pike about go and asking questions about some of the design decisions. After answering a few questions, Pike looked at him and said "Do you know who I am?". (supposedly)

<comment><USER11> I once questioned the design decisions for a particular project of the guy who made them, and his response was "who the ____do you think you are? "

</comment></comment></comment></comment><comment><USER12> If C++ programmers were attracted to making their language more elegant and safe yet more powerful at the same time they would have switched to any of the statically compiled, typesafe, managed languages years ago.

If Rob Pike was doing things in C++ that Go could also solve, that means he could've done them in C# or in Haskell too, which means he shouldn't have been doing them in C++ in the first place. (Strousup explains why in his recent GN keynote if you doubt that)

Of course solving that problem by inventing a new interesting language without any of the (psychologic) baggage those other languages is awesome. It seems to be rather succeful, but it's naieve to think that it would attract C++ programmers, there's just nothing in there for them. The C++ programmers who are looking for change have more to hope for in for example Rust.

<comment><USER13> Its also completely subjective to call other languages more powerful or elegant. For example, I think Haskell's lambda is less elegant than C++'s.

<comment><USER14> Haskell's lambdas are extremely elegant (\args... -> code, and treated no differently to any other function), but C++ has a pile of other considerations that Haskell doesn't have to worry about, due to Haskell's uniform representation and garbage collection.

<comment><USER13> I think that functions and closures are fundamentally different types. Haskell does implicit type erasure whereas C++ does not. Most of the time in C++ when you use lambda you don't need uniformity and you are better off using templates to pass them around. For the rare circumstances you do need this, you just stick it in a std::function. Haskell also has mechanisms that could handle this: type classes/parametric polymorphism/existential types and I would find this a much cleaner approach, but it would wreak havoc with other design decisions in the language such as currying. My main point of this is that Haskell proponents often think of C++ programmers to be unenlightened or wilfully ignorant, when its actually very possible they have thought things out and simply reached different conclusions.

</comment></comment></comment></comment><comment><USER15> "C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. ... The issue, then, is that Go's success would contradict their world view."

No it won't! I'm excited about Go. What I've read about it makes it look like a language I would love to work in, some day. However, I don't think the problems I'm solving now are the problems Go is good at solving. The programs I'm writing run on one machine with restricted memory, and they need to be highly, highly performant. The execution time is measured in tens of milliseconds, and during that time we do a lot mathematics and processing. SIMD is our close, beloved friend. In that context, I don't think Go is an appropriate language, due to its garbage collector, its lack of precise control over where objects go in memory, and the overhead of method calls. But if I ever write code similar to that written by Google, C++ would be a terrible choice.

I was all on board with what he was saying until that last little jab. I'm not migrating to Go because I have problems that Go doesn't set out to solve, but I'm not threatened by Go, because it's just another tool. Having more high- quality, carefully-designed tools is never a bad thing, and I can't imagine ever being threatened by a new tool's success.

Honestly, this smacks of more divisive bullshit. Pythonistas vs Rubyists, VIM vs Emacs, and now, Go vs C++. Blurgh.

<comment><AUTHOR> So if your point is a technical one, whats the main issue for you - that you can't emit hand-tuned SIMD code (I have no idea if thats possible) or that you can't do realtime because of garbage collection? I acknowledge that the go compiler has some catching up to do to become as fast as c++.

<comment><USER16> I can't speak for him, but the issues that make Go not interesting at all to me (and I believe, to a lot of other C++ coders) are automatic GC, lack of generics and lack of template metaprogramming.

The thing with Go is that it is (was?) marketed as a system's programming language. Go might work as a replacement for Java, but Java _is not_ for system programming.

Whoever decided to say Go was capable of it either has no idea what systems programming means or was being deceitful. Go can not replace C++; these languages don't solve the same problems.

<comment><USER17> As best I can determine, what you've just said is exactly how the article characterises the criticism of Go from C++ programmers.

The article's argument, however, is that C++ programmers are wrong to presume that those things are required for systems programming.

Interesting.

<comment><USER16> Although we can wonder about how system's programming would work when you use managed languages, the reality is that as of today (2013), system's programming means low-level memory management, an almost transparent translation from code to its lower-level counterpart (which, in 2013's system's programming jargon, means the target architecture's machine code) and most importantly _having as much control as possible_ over what your code actually does. Having garbage collection as a language feature takes away control, and system programmers won't be able to do their job with it.

It's fine to think of GC as "fast enough" in 2013, but that's when you're working on things were speed/space isn't scarce. Go _might_ work out for Google, since their "systems" comprise of tens of thousands of computers, where reliability and maintainability are more important than latency. For the rest of us C++ coders, we'll probably won't be able to replace C++ with Go for the tasks where we need to do _systems programming_ , simply because we on things that _require_ us to be control freaks.

Quite frankly, this post by Rob Pike saddened me, because it seemed like he was desperately trying to counter the Go criticism with a not very well thought out rant.

</comment></comment></comment></comment></comment><comment><USER18> Well, he admits he was never very at ease with C++, so I guess he can be forgiven for not understanding very few C++ programmers are going to jump into a garbage collected language. If they were, they would have moved long ago. Most of the times you need C++ nowadays are because a GC language simply won't do.

Kind of silly he drew up his language based on one Google need and thinks everyone using C++ should just jump aboard, though. He acts like he studied why people were writing in C++ and took their use cases into account instead of just his own. Kind of a stereotypical engineer who writes an app for themselves that utterly fails in the consumer market because it is written by coders for coders with weird controls.

<comment><USER19> People use C++ in all sorts of places where having true garbage collection would be better. For example, it's likely used to write the browser you are reading this message on, and possibly the entire OS.

Since far better languages than Go have existed for many years, and those have failed so far to attract many C++ programmers, I just think this is never going to happen until C++ programmers themselves die out.

<comment><USER20> Using GC in C++ is rather simple, just use a GC-powered allocator and you don't need to call `delete` anymore. But GC just doesn't matter so much. Many forget-to-delete or delete-too-early problems can be solved by memory analyzers. There are actually very few bugs that adding a GC can solve.

<comment><USER19> This is why I said "true" garbage collection. Conservative GC ain't real GC. GC isn't about eliminating bugs -- use valgrind for that -- it's about increasing programmer productivity, along with all the other features missing from C++ but present in modern strict strong-typed functional languages.

<comment><USER20> Conservative GC is real GC, it's just the tracing set happens to be the stack. And I don't see why you can't use non-conservative GC for C++ allocators. It only requires some work for read/write barriers.

GC is all about using `malloc/new` without thinking `free/delete`. With modern C and C++ there are a lot of mechanisms for that (passing values, auto_ptr and shared_ptr for example). In many cases a C++ programmer doesn't need to think about `free/delete` either, and in some cases the non-determinism of GC decreases the productivity too.

</comment></comment></comment></comment></comment><comment><USER21> For those who don't know who Rob Pike is, he's pretty awesome, helped create UTF-8 among other things, and now works on Go.

[http://en.wikipedia.org/wiki/Rob_Pike](http://en.wikipedia.org/wiki/Rob_Pike)

He has given some really great Go talks which are available on youtube, about an hour each:

Origins of Go Concurrency Style - [http://www.youtube.com/watch?v=3DtUzH3zoFo](http://www.youtube.com/watch?v=3DtUzH3zoFo)

Lexical Scanning in Go - [http://www.youtube.com/watch?v=HxaD_trXwRE](http://www.youtube.com/watch?v=HxaD_trXwRE)

Go Concurrency Patterns (One of my favorites) - [http://www.youtube.com/watch?v=f6kdp27TYZs](http://www.youtube.com/watch?v=f6kdp27TYZs)

<comment><USER22> He also may have invented Not Invented Here Syndrome. - [http://en.wikipedia.org/wiki/Not_invented_here](http://en.wikipedia.org/wiki/Not_invented_here)

(NIHS was certainly invented at Bell Labs' CSRG, I'm just not sure of the exact timeline.)

</comment></comment><comment><USER23> Actually I've looked at Go and it seems like a really shoddy step forward (as opposed to say D), but thanks for being so condescending about it.

<comment><USER24> It always amazes me when people try to somehow empirically prove that one programming language is better than another. Sure, it's an interesting question to consider as a thought-exercise, but is there really anything valuable to be gained from expanding on this any further than that?

I've always though that, other than objective measurements of binary code performance, whether or not you think a programming language is good is almost entirely determined by its syntax and feature set. I feel no need to go around the internet all day proclaiming my programming language of choice to be the best and/or others to be inferior.

This reminds me of that link I saw on here a while ago titled "Why Go? Use Racket!". Personally, my answer would be: because I find 9000 brackets in a simple program to be poorly readable. However, I respect anyone who disagrees and thinks the opposite. If it allows them to make great software and have fun doing it: by all means go for it!

You apparently thought the write-up was somehow overly condescending to C++ programmers (I assume), while I personally thought it was the complete opposite.

<comment><USER25> The tone of article implied that it is somehow expected that C++/Java developers would come to Go. Well, no - there are choices.

<comment><USER26> That tone is implied because that's what they thought when they designed the language. He specifically says that exact thing... They were trying to make development of the kind of projects C++ was used for easier and as such it was a reasonable assumption that they would draw users of C++ to Go. He also says it didn't really end up that way and explains why.

</comment></comment></comment></comment><comment><USER27> We are all waiting for Mozilla's rust to mature. Rust seems more in-line with C++'s "you only pay for features you use" and more general purpose.

I wouldn't use go for numerical simulations but it certainly shines for writing network servers.

</comment><comment><USER28> There is one feature of go that prevents me for considering it when I want to write "low level" code: garbage collection.

It's probably very silly but in my mind that puts it next to Java, above C and C++ in the "grand scale of programming languages".

Oh, and also I don't like garbage collection, so there's that. I'm sure some day someone will explain to me what's the point of it because I still don't get it.

<comment><USER25> I think you should be given a choice whether to use GC. Now that's a killer feature.

<comment><USER29> That's nearly impossible to do well. The second you decide you want to use a library that relies on GC, you need to turn on GC for your whole app.

There's no way to make that a local decision that I know of.

<comment><USER25> I don't know much about Rust, but they do promise "optional task-local GC, safe pointer types with region analysis".

<comment><USER29> So, while I'm far from an expert on Rust, that seems to me like they have separate heaps for separate tasks, and heap values are not shared. So, effectively, the tasks are roughly as isolated -- memorywise, at least -- as different OS level processes.

This means that you can have different tasks that have GC turned on or off at the task level, because a GC'ed object will never "leak" across a process boundary. However, if you decide you want to parse JSON with your fancy new GC-using JSON library, you either need to put that into a separate task, or you need to enable GC in the task that calls into that library.

That means that if you want GC-free code, you're going to have to be very careful about which libraries you can call into directly.

<comment><USER30> That's a good point, and I bet that once Rust's ecosystem picks up it'll be a major differentiator to be able to claim that a given library uses no GC whatsoever (while also avoiding unsafe code, naturally).

FWIW, Rust's stdlib tries to eliminate the use of GC whereever feasible. Cyclic data structures and persistent data structures are probably the only places where GC will end up being necessary.

</comment></comment></comment></comment></comment></comment><comment><USER31> C++ programmers don't go to Go because Go occupies the space otherwise taken by Java.

The only real, modern alternative to C++ is Rust, but it's not at 1.0 yet, meanwhile C++ is still getting new features, all the while preserving compatibility.

<comment><USER32> Ada, D

<comment><USER33> Vala and Python code compiled to generated C code (gobject) seems like interesting option.

Plus all these generated systems are standard and thus you can have different languages linking each other.

</comment></comment></comment><comment><USER34> What really gets me about go is that it's lame, manual error handling sucks, causing it to be smack dab in a middle area between my current languages of c++ and python. If you don't believe me, note that golang.org's home page example lacks error handling (huge fail).

In c++, I like the predictable destructor model of memory cleanup, and am willing to pay the manual error checking price (too scared to write exception safe code in c++). But I like to put as much complex logic in python code, due to its nice exception handling and GC.

If GO had a more flexible exception model, which by the way does not require forward jumping try/catch constructs, making it easier for people to write 'crash only' error handling without boiler plate, I might consider it. But for me, it's currently typecast as a firmly middle of the road feature set.

<comment><USER35> That optional error handling still boggles me, particularly since [http://golang.org/doc/faq#exceptions](http://golang.org/doc/faq#exceptions) makes it clear that they undervalued the the other major family of problems affecting C programs: programmers not checking return codes in often- exploitable ways.

I can understand not going the full Java/C++-level overhead (although Python is a great example of how that doesn't need to be so tedious in practice) but it still amazes me that simply importing something you don't use is a fatal compiler error but the classic "res, _ = something()" responsibility shirk you see all over the Go world doesn't even get a warning.

Maybe Go 2.0 could make the compiler simply do the equivalent of inserting an `if err != nil { panic("Unhandled error at FILE:LINE") }` block after any statement which can return an error and doesn't already have a check. That'd satisfy the low-overhead, predictable flow-control crowd while making the language much safer for large systems in practice.

(n.b.: lest that seem like too harsh a condemnation, I actually rather like Go as a highly appealing alternative to C: the fact that they got so many things right — gofmt alone deserves a medal — makes the minimal error handling feel like a surprising oversight.)

<comment><USER36> With a parser for Go in the standard library, it would be easy enough to write a source scanner that looked for unhandled error returns.

<comment><USER35> This is true but that's a non-trivial task even before you get to the question of running it on all third-party code and getting the upstream to patch it. This would solve the problem only in the same way that static analysis tools mean C code no longer has buffer overflows or type conversion errors.

</comment></comment></comment></comment><comment><USER37> Once again, Rob Pike speaks about generics and types in terms of C++ and Java, without acknowledging any other languages with static type systems, some of which are more expressive, less verbose, or both.

Surely Rob Pike is not ignorant of ML (1973), Ada (1980), Eiffel (1986), Oberon (1986), Haskell (1990), OCaml (1996), C# (2000), and F# (2005)?

See also the comments on [http://research.swtch.com/generic](http://research.swtch.com/generic)

<comment><USER22> I just _have_ to quote Pike's comments:

"Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.

"To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value.

"What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.

"But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types."

1\. STL != generic types.

2\. Lists of ints and maps of strings are hardly an unbearable burden; everyone and their dogs have been doing those in C for decades. But "string" is a poor universal data type. "int" is even worse. On the other hand, if "lists of ints and maps of strings" is your benchmark, you'll likely never understand that.

3\. If you _can_ confuse polymorphic functions, language primitives, or "helpers of other kinds" with types, you're probably doing something wrong. (Polymorphic functions, disjoint from types? I think I get what he's saying, but I need to ponder it some more.)

<comment><USER38> Pike comes out of a tradition, and his work is in some way the apotheosis of that tradition. The issue is that people confuse the dogma they were raised in with truth, and say stupid things like " ... To be fair he was probably saying in his own way that he really liked what the STL does for him in C++."

</comment></comment></comment><comment><USER39> Most programmers aren't in the latest-language bubble. Hell, my main earning language right now is PL/SQL, which limped out of the shadow of Ada, minus all the interesting bits, clutching hideous licence fees.

The reason Ruby and Python programmers have embraced Go is because they tend to be in the latest-language bubble.

The actual properties of the language are probably nearly totally inconsequential, except as bright lights that attract a certain sort of mind to it.

<comment><USER25> They probably work in start-ups or are free-lancers on small projects. Or they work at Google.

</comment></comment><comment><USER40> Less is more, but my ideal 'less' probably isn't your ideal 'less'. That's why we need more... so we can all have less.

C++ covers many domains and programming styles really well. Just because it doesn't cover some as well as some other language, it doesn't mean C++ as a whole is a lost cause. This is true no matter how many domain experts and language advocates attack it. It's C++s huge scope that opens it up to attacks from every corner in the first place.

Frankly I'm getting tired of reading articles from people who think they can proclaim "what C++ is about" any more than I can proclaim "what Go is about" or "what Python is about". Even Bjarne himself admits he doesn't know all the ways in which people use C++, and that's how he likes it.

</comment><comment><USER41> I think a lot of programmers don't come to Go for the same reason that I don't see myself ever using the language - it's far enough from a C-like language in syntax and ideology that it's not easy to move from the C family to it, and it has some "features" that I do not consider features. Those features make it taste like an academic language, what isn't what I'm looking for in a programming language.

Rust seems very different in that regard, and I look forward to being able to use it in production when the time is right.

</comment><comment><USER42> I'm a serious C++ programmer, and I'm also in the Rust boat, rather than the Go boat. I've tried Go. More than once. And each time, I feel really restricted. I feel like I have to solve problems a certain way, rather than the way that fits the problem. With C++, I have multiple approaches to solve a problem, and can choose the one that offers the best trade off of performance and maintainability.

For now, if I'm really wanting concurrency, and don't feel like C++ is doing what I need, I'll grab Java/Scala with Akka. They allow me to create a solution tailored to a problem, rather than tailoring a problem to a solution.

</comment><comment><USER20> A language which had aimed for system programing but not fast compared with C++, now aims for web programing but still harder to use than script languages, static typing but no generic types, forces boilerplate in several aspects (exception, assertion) but no meta programing ability to help fix it, weird design decisions dictated by personal experience, has Google helped marketing but still not widely accepted.

</comment><comment><USER43> Imho the main thing C++ offers are cheap abstractions. In C++ you can easily build abstractions that do not have any runtime overhead at all. You can write beautiful and general code and still not sacrifice a single cycle for it. Go doesn't offer that, not in the least. As such I think that Go and C++ simple have a very small intersection when it comes to use-cases.

</comment><comment><USER44> "Less is More" works when you have fewer components but you can assemble them together in various combinations to do everything you could otherwise do with more components.

However, when you have fewer components which can't be combined to achieve certain things that you could do earlier, it is hard to see how you can then say "Less is More".

Coming from game development RAII is a blessing. Not having control of memory deallocation is will not sell. This is definitely not a case of "Less is More", it's a case of "Less is Less".

<comment><USER42> No RAII is one of the things that really bugs me about go. I can't just construct an object and have it be ready, I have to remember to call some other method. Rust's memory model is also better, since it's akin to shared pointers (which you know the lifetime of) rather than garbage collection.

<comment><USER44> What I meant was that the way RAII works in C++ is a blessing and it can't work the same way in Golang since it doesn't give us control of when the object is destroyed. So, we are actually in agreement here.

</comment></comment></comment><comment><USER45> So it seems that C++ programmers are a bunch of silly self-centered people who cannot think as good engineers because somehow they have all been brainwashed (probably by Stroustrup). That is how I read it.

Ah, by the way, did anyone mention garbage collection?

</comment><comment><USER46> "It seems almost paradoxical that other C++ programmers don't seem to care."

It probably doesn't scratch their itch.

<comment><USER47> And it doesn't help that where it does scratch their itch it leaves a massive bleeding wound the size of a plate.

</comment></comment><comment><USER48> I've tried Go for some small stuff and read through "Programming in Go". I want to like it, but it just doesn't work for me. It's at an awkward position half way between C++ and Python. Knowing both C++ and Python, I don't see a convincing reason to use Go.

IMO, part of the reason C++ programmers aren't interested in Go is that C++ is, arguably, the most difficult language to learn. If you're really good with C++ you'll figure out most other languages fairly easy, and probably already know a few languages before going to C++. So I would expect most C++ programmers already have a "go to" scripting/interpreted, high level language that they know and like. And in that case Go just doesn't offer anything they don't already have.

<comment><USER49> I don't think learning C++ would help you at all when trying lisp-like, functional or logic programming languages. With its single oop model it doesn't even help you with languages that have different or multiple object models.

You also have a static type system so dynamic types are another thing to learn about, as are lexical scope and closures.

After all the effort of learning C++ you've only really learned C++.

<comment><USER48> I wasn't really talking about the transferability of C++ knowledge to other languages. The amount of effort to learn C++ is greater than the amount of effort to learn most other languages. Whether that knowledge transfers to other languages is another matter altogether.

The amount of time to become a C++ expert is far greater than to become a Python expert or a Go expert. After spending a few years learning C++ spending a year learning Go doesn't seem like a big deal, so why not learn it?

<comment><USER49> I just don't agree with your statement "If you're really good with C++ you'll figure out most other languages fairly easily".

As I was trying to illustrate there are a wide range of language features available in other languages that C++ does not have anything remotely like.

It takes a long time to learn C++ not because the concepts are particularly hard, but because the implementation of the language is rather messy and the code you produce can easily do crazy things not apparent on the surface.

</comment></comment></comment></comment><comment><USER50> I'm not a C++ guy, but I will say the most interesting thing about Go to me is that it's a smallish, clean, staticly-typed language that gives a great day- to-day development experience. It also comes with a lot of nice tools for formatting code, documentation, dependency management, etc.

Switching from Ruby or PHP is pretty easy because you get the same (or better) developer experience with excellent performance and nice built-in libs. For writing web services, Go is pretty much ready to roll out of the box.

I think writing Go is fun. I'm not sure that it matters why other programmers do or don't like Go. I think it's great.

</comment><comment><USER51> Previous discussion: [http://news.ycombinator.com/item?id=4158865](http://news.ycombinator.com/item?id=4158865)

<comment><AUTHOR> Interesting how different the discussion went - minimalism as a design aesthetic back then vs. c++ programmer outrage this time, all because of a different title and abstract.

</comment></comment><comment><USER52> TL;DR - Rob finally realized Go is a flop, and nobody wants to use it for serious programming work. So, he whines about it, and blames C++.

</comment><comment><USER53> For me it's not about the language. It's about pragmatics.

With C++ I can write code that builds natively using standard tool chains and libraries on Linux, Mac, Windows, iOS, Android, and dozens of other less common platforms.

With C++ I can write something once and then _ship it_ on all those things without worrying (much) about the availability of tooling. If I write it using portable programming techniques (mostly acquired through hard experience) I will not have to do very much porting, and the #ifdef mechanism provides an acceptable way to accomplish alternate code paths on different platforms without compromising cleanliness of the build or performance.

C++ has its uglies, but it's not too bad if one knows it well and avoids various also-learned-through-experience antipatterns.

Go is in fact better than C++, but it's not better _enough_ to justify the hassle or the impact in my ability to ship across umpteen platforms.

This is why everyone still does systems programming in C/C++. Write (a bit painfully) once, ship everywhere.

Other languages like Go, Ruby, Python, Rust, server-side JavaScript, various functional dialects, D, whatever, always achieve success in two areas: _specific_ ecosystems/platforms (e.g. ObjC on Apple, Haskell in the world of high-speed algorithmic trading), and server-side coding. With server-side coding who cares if you can ship, cause you don't. But all the world is not a server, and sometimes you want to hit multiple user bases. For that, only C will do.

I actually think a Go (or any other language) compiler that builds to cross- platform C code with a _configure_ script _and_ a Windows build script would be a worthy development. I know many people hate language-to-language compilers, but this would enable one to write in nifty new language X, build intermediate code, then build that intermediate code with the native tooling of every other damn thing.

The other alternative would be for Google -- if it really wants to push Go -- to put a lot of effort behind porting it to offer good high-quality native tooling for everything and everyone's toaster oven. But Google thinks all the world's a server or a browser (and it is for Google for the most part) so that doesn't seem to be a priority for them.

<comment><USER32> One way they could push it, would be to give first class support for Android development, but I doubt it will ever happen.

</comment></comment><comment><USER54> Rob Pike did not aim to replace "C++", but "C++ as he used it at Google". Looks like he succeeded at that. For those problems garbage collection is a good idea (did the C++ guys try Boehm?) and compilation time is critical. From the article: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

I agree with most of what Pike says until the end, where he derides C++ programmers:

"C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. The issue, then, is that Go's success would contradict their world view."

This is just wrong. They do not come, because Go simply does not fit the requirements. Go is more opinionated and targets a smaller niche than C++. Nothing wrong with that. If Go and C++ both fit your requirements, Go is probably the better choice.

The only language I know, which explicitly targets C++ is D, but it is not there yet completely. Though, depending on your needs it might enough and it is an improvement over C++.

<comment><USER55> > The only language I know, which explicitly targets C++ is D, but it is not > there yet completely. Though, depending on your needs it might enough and it > is an improvement over C++.

And Rust. Although it has its own issues as well.

<comment><USER54> When typing the comment, I actually had written a sentence about Rust and later deleted it. The concurrency model of Rust is restricted compared to C++ and D: "lightweight tasks with message passing, no shared memory". However, Rust has potential. Maybe. Interesting times. :)

</comment></comment></comment><comment><USER56> Sometimes I feel like I'm the only guy that likes and works in C. Then I see TIOBE index and alike and see C on top always. Are we, C programmers, not vocal or are those metrics skewed in favor of 'legacy' and existing code?

<comment><USER7> I like C quite a bit, but if I said, "I like C more than C++ or JavaScript or Haskell", I'd be locked away forever. In a padded room. With nothing but a BASIC interpreter.

i.e. nobody, but nobody says their favorite language is C anymore, they've all found languages that have trade-offs, and most people don't need the trade- offs C can provide. Parsing XML? Un-fun. Regular expressions? Un-fun. GUIs? Un-fun. Hierarchical subclasses of actors? Un-fun.

</comment></comment><comment><USER57> In a corporate environment (particularly _that_ corporate environment), the option of enforcing "we don't have to use the whole buffalo" exists. That is, you can say "these parts of C++ are off-limits for this code base", and be reasonably sure it will stick. See also: exceptions.

You could do that. Or you could go write a new language and further scatter the masses.

</comment><comment><USER58> I'm currently a C++ programmer that does not intend to change to go because I want to have exquisit control.

However, this is not because of my views or something like that but because I'm only a C++ programmer at the moment, because I need that kind of control for my current work. If I want to publish a paper or argue on specifics of algorithms and data structues, e.g., like cache efficiency, it is highly convenient to know as much as possible about what your code does in detail and to have the opportunity to force a particular behavior.

The next time I'll be asked to get a complex problem solved somewhat efficiently (I did write a lot of java code before starting to dive into C++ 3 years ago), I might look into go. But as long as the specifics of my solution are "the job", I can still focus on getting the job done but choose C++ over Go.

New C++ features are always nice, because I don't have to use them all and can cherry-pick whatever is more convenient to achieve what I want

</comment><comment><USER59> Somehow I miss the biggest advantage of C++ here: you can still maintain a 20 year old code-base without a complete rewrite.

</comment><comment><USER60> I don't see this as an 'anti' C or C++ article. I see it as an effort to explain (initially to himself) why the phenomena exists. Not sure I agree with all of it but being a C/C++ programmer on micro-computers from the very beginning, much of what is said resonates. I've pretty much be multi-lingual from my start with IBM360 BAL (the programmers version of 'been down so long everything looks like up :) ) That said when I was able to use C (actually a C subset called BDS C [yes BDS does stand for Brain Dead Software]) I immediately set aside PL1, Fortran, Pascal etc. Because I had found a HLA (High Level Assembler) and was as happy as a pig in mud (how happy is that?). That was in the beginning days of the S100 bus and therefore long ago. Since then I accumulated many languages, somethimes for the hell of it (it looked interested), sometimes because the client wished it and sometimes because it was clearly the right choice. The one pattern I've maintained over all of this time is to learn and test the language by writing a parser in it. Not a random one, but a particular problem I was deeply familiar with. The parsing of chess games. It usually winds up a middling tiny sized work of about a 1000 lines and when done I've a reasonable idea of the workings of the language and more importantly how hard it is to write parsers in. Why parsers? Because to paraphrase the wisdom of turtles, 'It's parsers all of the way down...'

This winds up being a windy version of 'I suppose I'll have to try go to see what's what'

</comment><comment><USER61> Less is more. No data mutation. No ordered execution. Go Haskell.

</comment><comment><USER62> I have similar minimalist sympathies, taking as an ideal Antoine de St Exupery's remark on aeronautical engineering, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

The problem with Pike's work, as I see it, is that what it calls 'simple' I see as unnecessary burdens layered on top. A text editor that makes you take your hands off the keyboard? No thanks. I want to edit text, not pictures of text.

</comment><comment><USER63> Hopping on my soap box here.. I'd think that the word "exponentially" is used incorrectly in the title. The trend to use cool math terms in everyday language is a something that has been going on over the last few years. It can be very expressive, but it's annoying when it's done in the wrong way.

Something cannot be "exponentially more" than something else. Something can be a factor more than something else (if you have a measure). In this case, if you want to use a cool math term, then you could say something is an order of magnitude more than something else.

The correct way to use the adverb exponentially would be to apply it to a development or a progression. For example, "Moore's law predicts that we'll have exponentially more CPU power in the future", or "This problem gets exponentially harder if the input size increases linearly". It applies to something that changes with an ever increasing rate, not to any specific values in time.

</comment><comment><USER64> I still use C++ since there still doesn't seem to be a better option for creating cross platform GUI apps than C++ with Qt. Desktop Apps are no longer 'cool' and other than Qt there doesn't seem to be much happening in the Desktop space. For scripting I use lua since it's a lot easier to embed than Python.

<comment><USER65> Isn't Python with PyQt any good?

(That would be my first choice if writing a web app is infeasible, but it's been a while since I've followed the project.)

<comment><USER64> I use it somewhat. The core program is C++ / Qt. The data is all serialized using Qt data structures. Then I have python helper programs that read the Qt data structures and generate reports. It's not the most elegant solution but it was the easiest way.

</comment></comment></comment><comment><USER66> C++ (and Java in a sense) are kind of a "local optimum" in terms of languages. Go breaks from that, an it's good. It's not necessarily faster (or slower), it's a different way of seeing things.

So C++ programmers think they need "all the speed" of C++ (ignoring all the cases where it's being slower because of the added complexity that C++ programs end up having) and convincing themselves that's the "only true way"

In some aspects that's true, you really shouldn't go for something outside of C/C++ in the embedded world usually (even though embedded systems are getting faster, but there are several specialist systems slower than your smartphone)

But for most apps today? Thanks, but I would try alternatives first.

</comment><comment><USER13> "C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way."

Nobody can speak for all C++ programmers, but I think the biggest drawback of a transition from C++ to Go is a lack of abstraction power. Not having Generics/Exceptions/RAII is just painful.

</comment><comment><USER25> "I believe that's a preposterous way to think about programming. What matters isn't the ancestor relations between things but what they can do for you."

Similarly I can say: "What matters isn't the composition of things but what they can do for you."

Also C++ and Java guys might be coming to Scala instead. Which is not owned by Google.

What is the killer feature of Go that makes it significantly different than C#/Scala or some other popular modern language?

</comment><comment><USER67> Performance is important in another way (I'm referencing the C++ vs go performance discussions here, more than the OP). The more performant you are, the fewer watts you burn. This means phone batteries last longer, and google data centers require fewer power substations. It's a nontrivial concern at any scale. I find blithe 'throw more cores at it' statements rather questionable ecologically.

</comment><comment><USER68> You cannot expect people to replace a language developed and polished over decades with one that barely hit version 1.0. Go is fun to write, has some good ideas, and is a little more readable (in idiomatic form) than C++. But it is new. Once Go has the necessary libraries, and has been thorough tested, then more people will look into it.

</comment><comment><USER69> What bugs me most about Go is that it is already filled with internal inconsistencies, and since it practically demands idiomatic usage, these aren't easily avoided. In C++ one can at least avoid using "bad" parts and patterns.

</comment><comment><USER70> Sometimes you need complexity or extreme performance, and sometimes you need it to stay out of your way. Go sacrifices the latter value for the former value. D and Rust have far more potential to woo C++ programmers.

</comment><comment><USER71> "We didn't figure it all out right away. For instance, it took us over a year to figure out arrays and slices."

And that might be how long it takes me to fully understand the difference.

</comment><comment><USER72> Didn't we discuss this already last year? [https://news.ycombinator.com/item?id=4159703](https://news.ycombinator.com/item?id=4159703)

</comment><comment><USER73> There is cgo which allows one to call into C controlled code. That to me is best of both worlds, working in Go when I need to and memory control when needed as well.

</comment><comment><USER74> I'm very dissapointed in Go philosophy... Edpecially about RAII...

</comment><comment><USER75> I personally don't like go, because it doesn't have language features, which must be included in any new programming language, I mean generics and exceptions.

</comment><comment><USER76> Simple answer - if we wanted something slower than C++, then we already have Java. If we wanted some more dynamic we have Python. If we wanted something more Brogrammer style, we have Ruby, so what fit is Go good for?

<comment><USER32> To earn upvotes at HN :)

</comment></comment><comment><USER77> >Go is, I believe, more expressive than C or C++

Really? Why does it always seem like everything he says about go is designed to make people question his grasp on reality? There is no way to reasonably argue that go is more expressive than C++. You might very well feel that the huge increase in complexity that comes with C++ is not worth the comparatively smaller increase in expressiveness, but pretending go is more expressive is simply absurd.</comment>


Get a Microchip in your brain - <AUTHOR>

Assuming there is a microchip that can be transplanted into your brain, entirely running on your bodies glucose , while giving you automatic access to enormous database memory and the internet while interacting   with your neurons. you had the same control about it as you had about your thoughts.   You d be the first human to receive the transplant . Would you (and under which conditions)  "volunteer" ? <comment><USER2> I would do it</comment>


Restaurants prepare for new calorie-count rules - <AUTHOR> http://www2.tbo.com/content/2010/mar/23/restaurants-prepare-new-calorie-count-rules/news-breaking/

<comment><USER2> Ways to make money from this:

1) Make a brochure for your area "Eating Better in NAME_OF_TOWN USA". List all the meals that have the lower calorie counts. Ask the local businesses to pay to be listed. Publish this bi-annually. Do this in every town you can.

2) Start an eating-healthy club that uses goal-setting and social shaming to help people lose or maintain their weight. Ask local businesses to sponsor membership fees in exchange for listing their lower-calorie menu items in your newsletter. Do this in 1000 towns. You'll need to find someone local to set this up. Start by contacting people in outgoing/enterprising professions such as real-estate.

More ideas?

</comment><comment><USER3> This policy move is completely misguided and paradoxically almost guaranteed to make people more overweight.

Anyone who thinks this is a good idea should read Gary Taubes's review of the obesity literature in Good Calorie, Bad Calorie.

Our society appears to have become obese in large part from gorging ourselves on nutrient-depleted carbs (sugar, flour). This is just going to encourage people eat even less fat and more carbohydrates because of the calorie difference between fat and carbohydrate.

<comment><USER4> I think this is a great idea actually, assuming step 2 is followed: proper nutritional education.

In Canada, nutritionists are heavily subsidized by the health system (the idea being that whatever the cost now certainly beats giving you a new heart in 20 years), and in fact nutrition courses are _free_ for people in at-risk weight ranges.

This has worked out great for me personally - I used to be obese, and this type of education has been instrumental in allowing me to return to normal weight. In fact, given the depth of the obesity problem in America, I would think that this sort of education should be mandatory in the schooling system.

All the labeling in the world will do you no good until your population learns what the labels mean.

<comment><USER5> Is there a correlation between the availability of good information and informed decisions? We know that fast food is bad for us. Even stepping inside one to buy something means that you're going to get something not good for you. Availability of information at McDonald's does not help you buy and consume good food, because if you are _at_ McDonald's it's already too late.

You are probably an exception because you were motivated to lose the weight in the first place. I suppose I'm one of the lucky skinny types that overweight people hate, but it seems to me that obesity is less about knowing what is in your food and simply eating less of it. If calories consumed are greater than calories burned, you gain weight.

While traveling around Europe, I happened to be at the same hostel as a Canadian doctor and he was more than happy to share lots of opinions with me -- especially about the U.S. health care system. So I asked him about weight and food. He said simply: People get fat because they eat too much. He also said, drink a lot of water and eat slower.

Later, I read an article that most people can't tell the difference between thirst and hunger. If you drink water when you _feel_ hungry, often the hunger pangs go away. Of course that couldn't be true for me! So I tested it and sure enough, when I got hungry, I'd drink water and I wouldn't be hungry anymore.

Food is just like TV or cigarettes. It alleviates boredom. It gives us a good feeling to eat. We eat foods that are too dense with calories. Steak. Chicken. Twinkies. We are emotionally trained to think meat is better. In my rural area, vegetarians are _weird_. "You don't eat meat?? Why?!? OMG, I could never live without meat. What are you a sissy?"

But it isn't like that. Food is mostly emotional -- always has been. The reason all those women in the really old paintings are plump is because it was a sign of wealth. Rich kings could keep their women fat. Turns out they were the ones who could afford to pay painters as well, so we don't see all the skinny people who lived back then, but skinny is the norm, not the rule.

In the U.S., people think it is hard to be skinny, when the opposite is true -- it's hard to get fat.

Funny that your username is potatolicious and you're commenting on a food thread...

<comment><USER4> > _"We know that fast food is bad for us."_

We intuitively know this, but we do not intuitively know what is _good_ for us. Sure, you can insist that people ought to cook everything from scratch, but given modern lifestyles this is really just a moral high horse, and stands little chance of being realistic advice that will be followed. Not to mention that a _lot_ of home cooking is dangerously unhealthy for you (meatloaf, anyone?).

The information that led to my dramatic weight loss wasn't some kind of holy secret grail, it was simply training on what foods I need, how much of it I need, how to read nutritional labels, and the common pitfalls (e.g., trading fat for sodium) that one ought to watch out for. Instead of harping "fries are bad for you!" the program taught me was _was_ good for me, which in the end was infinitely more helpful. We publish a pretty good guide on food groups and recommended servings, but the whole system doesn't account for the world of processed, industrialized food we live in today. How good are those crackers? Unsalted? What does that mean? It can still be an invitation to a coronary unless you are smart about scrutinizing labels.

> _"obesity is less about knowing what is in your food and simply eating less > of it"_

True and false. Most obese people (including myself) eat too much, but much of it has to do with _what_ is being eaten as well. Trading fat for carbs, trading fat for sodium, etc etc, all contribute to bad health.

Also, nutritional education also opened my eyes on _how_ bad certain foods are for you. We intuitively know burgers and fries are bad - but _how_ bad? Even most "normals" don't know this quantitatively, and this knowledge has helped me avoid a lot of foods. There are shades of "bad for you", and it's important to know this. "Stop eating burgers and ice cream" is a moralistic stance to take, and technically correct, but ultimately unhelpful.

</comment></comment></comment></comment><comment><USER6> How much wiggle room is built into the law? As mentioned in the article, portioning varies by location and chef. What happens if a chef adds an extra tablespoon of ranch dressing or gets a shipment of slightly larger chickens? The US is such a litigious society that it's a question of when, not if, lawsuits will be filed. I'd like to think provisions for this are built into the law but I doubt it.

Also, what about specials? Have some fish left over from the weekend and want to run a special? Well figure out your exact portions, calculate calories, and reprint your menus. Oh wait, the fish went bad while you were doing all of that. Sorry. Try again next week.

<comment><USER4> I'm not sure about the state the article is about - but in Washington it only applies to chains, which have sophisticated supply chains that ensure a pretty narrow tolerance of serving sizes and contents.

This certainly doesn't apply to your corner mom and pop shop where serving sizes and contents vary by the plate.

</comment></comment><comment><USER7> This is at it's core the classic government vs. personal responsibility issue.

This is already required in NYC for chains. It's kind of nice to know that the Five Guys burger and fries I'm about to throw down for lunch satisfies all of the calorie and fat limits recommended for the day in just one meal. At the same time, is there a need for government to mandate this?

I think it's a good tool for people who are looking to be a bit smarter about their consumption habits. Most people understand that the food they're eating isn't good, but I think the problem is that few understand just how bad it actually is. High fat/calorie restaurant chains have little incentive to do something like this, so maybe the .gov getting involved is needed.

<comment><USER8> I think it's a little more complicated than that actually, it appears that the restaurant industry actually lobbied _for_ the new regulation. ([http://reason.com/blog/2010/03/22/conspicuous-calorie- counts...](http://reason.com/blog/2010/03/22/conspicuous-calorie-counts-com)).

In this case, it seems to be less a case of the federal government vs personal responsibility, so much as industry pushing for the federal law to _avoid_ having to deal with emerging individual state and local laws. I'm assuming the industry might also be planning to use the labeling to help defend against some of the lawsuits that are being brought against them by people with obesity related disorders.</comment></comment>


Java SE 6u24 - <AUTHOR> http://www.oracle.com/technetwork/java/javase/downloads/index.html

<comment><USER2> They can't seem to get auto update working for Windows 64-bit JDK. Need to uninstall and install on every update. May be by JDK 8 or so we might have a chance of getting that.

</comment><comment><AUTHOR> the famous floating point glitch seems to fixed

<comment><USER3> They've had that available for a week:

[http://www.oracle.com/technetwork/java/javase/downloads/inde...](http://www.oracle.com/technetwork/java/javase/downloads/index.html#fpupdater)

This fixes a number of other vulnerabilities:

[http://www.oracle.com/technetwork/topics/security/javacpufeb...](http://www.oracle.com/technetwork/topics/security/javacpufeb2011-304611.html)

<comment><USER4> Also, as I understand it from another story, 6u24 doesn't break the update mechanism, while the FP bug patch does/did.

Ah, here's the mention, in the ReadMe link located in your first linked document:

[http://www.oracle.com/technetwork/java/javase/fpupdater- tool...](http://www.oracle.com/technetwork/java/javase/fpupdater-tool- readme-305936.html)

 _The FPUpdater tool is not intended for use on systems managed through auto- update as this will disable future auto-updates. We recommend that you wait until the next Critical Patch Update (CPU) when you can update your installation by going to<http://java.com/latest> ._

(Whether you want auto-update is, I guess, a separate question, though not an insignificant one.)

</comment></comment></comment><comment><USER5> When do we get closures?

<comment><USER6> It has been extremely well documented that closures are planned for Java 8. If you absolutely, positively can't wait, anonymous inner classes are your best work-around at the moment. However, it turns out you can, in fact, get by without closures.

Or is this just a thinly veiled attempt to insult the current state of Java? If so, it might be more productive to simply choose a different programming language that you like better.

<comment><USER5> Whoa! Slow down, buddy. Didn't mean to push your buttons there. You're right, I do get by just fine using inner classes, and will continue to do so. I was just wondering for the pure convenience of making code prettier.

</comment></comment></comment><comment><USER7> So it's now "Java for Business"...</comment>


Millions of Spiders in Pakistan Encase Entire Trees in Webs - <AUTHOR> http://www.wired.com/wiredscience/2011/03/pakistan-tree-spiders/

<comment><USER2> I'm saddened that HN is degrading into Digg.

<comment><USER3> <http://ycombinator.com/newsguidelines.html> please view the 3rd from the bottom paragraph.

Although, I do agree that this particular link is not as interesting as some I see on here.

<comment><USER2> Got it. I'll quit my bitching.</comment></comment></comment>


So Coded Conf: Monks, Web and Confetti - <AUTHOR> http://2015.socoded.com

<comment><USER2> Site does not work in Safari. There are quite a few errors & warnings in the console log...

<comment><AUTHOR> Hey, unfortunately that's true. We had this great idea of an awesome monk video, did all the shooting and editing etc and after trying to find a pure HTML playback solution that worked everywhere we had to stop at some point. So: SORRY! Really meaning that, it's just a matter of how much of our spare time can go into the website as there is so much more to organize. The easiest way is to checkout: [http://2015-info.socoded.com](http://2015-info.socoded.com) if you experience any trouble. That should work across the board.

</comment></comment><comment><USER3> seems pretty cool. looking forward to join. Anybody interested to travel from SF together?</comment>


Privacy, security and employee protests will shape year ahead for Silicon Valley - <AUTHOR> https://www.nytimes.com/2018/12/29/opinion/tech-2018-trends-2019-predictions.html <comment><USER2> [https://outline.com/5F36xr](https://outline.com/5F36xr)</comment>


Facebook Democratized the News, but New Changes Do the Opposite - <AUTHOR> http://www.nytimes./roomfordebate/2016/05/17/is-facebook-saving-journalism-or-ruining-it/facebook-democratized-the-news-but-new-changes-do-the-opposite <comment><USER2> Bad URL. Try submitting again.</comment>


Real Secret to Startup Success - <AUTHOR> http://smartfaststartup.com/2011/06/08/real-secret-to-startup-success/

<comment><AUTHOR> Core idea:

       The idea that a successful startup most often fails before it succeeds
       is becoming quite popular. But the concept has been alive in the DNA of
       Silicon Valley for quite awhile.  Silicon Valley is really one of the
       only environments in the world where failure is actually treated like a
       good thing--but only if you learn from it and keep going.

       The real secret is to build on what you learned in the last failure.</comment>


Ask HN: How would you solve the liability-interview feedback problem? - <AUTHOR> Most interviewers aren't going to give you real feedback because of potential liability. If they are very transparent of the reasons that you were rejected for a job interview, they put the company at risk of being sued. How would you get around to solving this problem that can satisfy both the interviewer/employer and interviewee parties? <comment><USER2> As an interviewee: if you are failing interviews chronically, you should contact some of the interviewers you felt you connected best with (personally/directly) and ask for feedback. No guarantees for any individual, but if you talk to many people, you may get feedback from somebody.

As an interviewer: Be brave. From a CYA perspective, you may wish to avoid electronic communication about anything that could be seen as conspiratorial. (ie. Don't send a text about having somebody deflate a football)

In general: Sometimes you don't get the job for reasons that have nothing to do with your interview performance. Maybe they had a choice of two or three people they liked and there was nothing wrong with you but they liked somebody else better. In some settings (academia and government) somebody has been pitching management for six months, a year, or more, to create a job for themselves, but they have to interview other people anyway because policy/the law says so.</comment>


Tell HN: the word "Niger" (the country) seems blocked in Venmo memos - <AUTHOR> Was donating to a charitable cause in Niger and was able to use the word "Niger" in late April ("sadaqah" = charity in Arabic): https://imgur.com/a/yq1tWCq
I no longer can. Two examples with the word "Niger" in it: https://imgur.com/a/pDunMej
Reproduced on someone else's phone as well.
I suspect it's because 1) of recent USA events and 2) "Niger" is one letter away from being the n-word. Contacted customer support but they didn't seem to understand I was trying to file a bug report. My goal isn't to get a customer service rep in trouble, so I won't bother posting the transcript unless people think it would be helpful.
Ideas on how to inform Venmo of this? Wanted to create an Ask HN, but couldn't figure out a short enough question for the title character limit. <comment><USER2> This demonstrates why censorship via automation is so difficult. You basically need to understand a lot of the context around the use-case, in order to determine if the word should be allowed/disallowed.

Even if you succeed, people evade these systems by developing slang and substituting special characters...

Preventing hate speech from users is a very hard problem, with automation alone.

</comment><comment><USER3> Hit up their public accounts such as Twitter/facebook etc. They will probably respond more promptly there. Be nice about it and let them know the issue in a clear and coherent way.

<comment><AUTHOR> That's a good idea. DMed @VenmoSupport on Twitter. Thank you.

</comment></comment><comment><USER4> Stop using venmo & probably paypal. They uniquely block transactions based on stupid keyword basis. Also happens with 'persian food'.

On top of that, venmo really wants to make your transactions public, while ones like square cash do not. I also don't think they do the stupid keyword thing too.

</comment><comment><USER5> It's sad when a whole country becomes a racial slur in some other country. But I guess for every person who has a valid reason to use the word, there are a thousand trolls trying to use the country name as a loophole. So I'm not surprised if customer service thinks you're filing a troll bug report.

<comment><AUTHOR> That's what I was thinking: it's an overly aggressive attempt at blocking the n-word.

Tried a payment with the word "Nigeria" in it and that went through successfully.

<comment><USER6> Would it make sense to only censor the word if it's lower case?

I mean I still see no reason why a transaction shouldn't go through even if it had the word spelled properly. Black people don't have a problem using it (deservedly so!) and I there are contexts where it is somewhat acceptable to use it if only to refer to (for instance) a racist character in a novel.

<comment><USER6> Can't edit now, but I just want to say that I've reconsidered this point of view and now find it mildly racist and insensitive. Apologies if anyone was hurt by this.

</comment></comment></comment></comment><comment><USER7> While AI remains out of reach, AS (Artificial Stupidity) once again asserts it's omnipresence.

</comment><comment><USER8> If you use the word "Syria" in the memo the payment will also be blocked.

<comment><AUTHOR> I tested that out. A memo of "Syria" causes the payment to go into review and doesn't block it outright. "Niger" in the memo results in the "Please try another payment note" error message shown in the screenshots.

</comment></comment><comment><USER9> Maybe try "N3r" in its place.

</comment><comment><USER10> 1 is actually the likely answer and IIRC has to do with regulations beyond Venmo (experienced something similar with a different country). They likely won't be able to help beyond suggesting not mentioning it in your description.

<comment><USER11> Which regulations?

<comment><USER10> they cite OFAC (Office of Foreign Assets Control) regulations [0], which is what I got as an answer as well when I experienced something similar.

[0] [https://www.inc.com/tess-townsend/venmo-reportedly- blocking-...](https://www.inc.com/tess-townsend/venmo-reportedly-blocking- payments-that-use-the-word-persian.html)

</comment></comment></comment><comment><USER12> Venmo only allows payments to _individuals_ (unless it's an approved venmo merchant), and only _within the USA_.

You're violating their terms of service six ways to Sunday, donating to a charity in Niger.

In your case, Venmo is The Wrong Tool for the Job.

<comment><AUTHOR> Payment was to a US citizen who was doing some charitable work in Niger, and the individual isn't working on behalf of a charity.

I appreciate the information though.</comment></comment>


Biosband - <AUTHOR> http://biosband.com/en/app-home-2/ <comment><USER2> " Biosband is not in any case a slimming (sic) or an appetite suppressant."

What _is_ the science then? Any actual peer-reviewed support for your concept?</comment>


Automatic Algorithms Optimization via Fast Matrix Exponentiation - <AUTHOR> http://kukuruku.co/hub/algorithms/automatic-algorithms-optimization-via-fast-matrix-exponentiation.html

<comment><USER2> This is very, very cool. Moving this kind of intelligence into the compiler and runtime is one of the things I desperately wanted to do in grad school. The academic machine ground that desire out of me in short order, but I still have a tremendous love of the work.

<comment><USER3> Are you working on compilers and runtimes? If you are interested in doing this, please shoot me an email svembu at zoho

</comment></comment><comment><USER4> This is great when your inner loop is calculating the nth Fibonacci number, but I'm skeptical that there are all that many practically occurring inner loops that are linear recurrences where the author of the code has not already recognized them as such.

</comment><comment><USER5> The language he describes is not Turing-complete, which limits the number of use cases. Still very interesting when you have such a situation.

</comment><comment><USER6> Have you considered doing matrix decompositions for faster exponentiation? I guess the floating point handling would be hard to get right though.

</comment><comment><USER7> See also [https://news.ycombinator.com/item?id=8799088](https://news.ycombinator.com/item?id=8799088)</comment>


Big Tech Back in Vogue on Wall Street - <AUTHOR> http://www.ft.com/intl/cms/s/0/594989b4-795f-11e5-933d-efcdc3c11c89.html <comment><USER2> First 2 comments:

> It is amazing what "cub" [rookie] reporters refer to as "solid" earnings. > Not one mention is ever made in reference to free cash flow, the cost of > capital or return on invested capital. Let's be honest, the continuation of > money printing by the world's central banksters is fuel behind the recent > market melt-up.

> A new air for an unsustainable bubble. As [the commenter above] mentions, > the profit reported by Amazon is ridiculously small in relation to its > market value.

Google re-direct link to the article:

[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB8QqQIwAGoVChMI1fbzsInbyAIVCYI- Ch06kAPb&url=http%3A%2F%2Fwww.ft.com%2Fcms%2Fs%2F0%2F594989b4-795f-11e5-933d-efcdc3c11c89.html&usg=AFQjCNGYTfh5z88gyHNRRYvwP1JHt_ib8Q&sig2=oBsPGhY64u3bHFwVVRVQ8w)</comment>


Groupcache – A Go caching library, intended as a replacement for memcached - <AUTHOR> https://github.com/golang/groupcache

<comment><USER2> the thing is readonly, good luck</comment>


Ask HN: How do you keep track of your personal email templates? - <AUTHOR> When writing a new email, I often find myself opening my "Sent" folder looking for a similar type of email that I have already written. This is especially the case for standard emails such as sending a document for review to my boss, requesting work from home, scheduling a meeting and so on.
Having a single database with these email templates would be a time saver because, instead of rewriting all new emails from scratch, I could reuse my past emails and just slightly adapt them to the new circumstances. Is there any tool or strategy that you use to keep a list of personal email templates for later reuse?
The following features would be useful in such a tool:
- be independent of any specific web email client because I routinely use multiple web clients,
- be able to tag templates, such as in https://www.starterstory.com/how-to-say-no,
- offer quick search by tag and body text,
- if possible, can also search by date sent and recipient, as that is how I frequently manage to find the right email among all the ones I sent because it is easier to remember a time and a person than the exact wording used in an email. <comment><USER2> Since I write my emails in Vim/Emacs and then copy them to my email client, I just keep commonly sent emails as text files in a directory and :r them whenever I want to use them as a base.

Speaking of, I should probably switch to a TUI email client instead of copy- pasting my emails from my text editor.</comment>


Dissecting SimpleDB BoxUsage - <AUTHOR> http://www.daemonology.net/blog/2008-06-25-dissecting-simpledb-boxusage.html

<comment><USER2> This is pretty hilarious, Colin. If only DB usage were more fungible.

You're kind of like a shark when you smell blood. Is it the security mindset?

<comment><AUTHOR> _You're kind of like a shark when you smell blood. Is it the security mindset?_

Not really -- it's more a getting-irritated-when-people-do-thing-badly mindset. I can do better; therefore they should do better. :-)

EDIT: On second thought, maybe there is an aspect of security mindset here. One of the assumptions I find to be very useful in dealing with security is the bad guys are at least as smart as I am. It's not very far from here to saying "the Amazonians working on SimpleDB should be at least as smart as me".

<comment><USER2> Are you using Jon Borwein's experimental math packages for, say fractionalising the numbers or finding formulas, or some of your own routines you've rolled on your own?

<comment><AUTHOR> The rational reconstruction was just me throwing the values at Maple's convert/parfrac and looking at the convergents for sensible values. The rest was simply looking at the numbers and noticing (eventually) what 2 N^3, 20 N^2, and 80 N looked like.</comment></comment></comment></comment>


US House bill exempts employers with 500 employees from sick day requirement - <AUTHOR> https://www.nytimes.com/2020/03/14/opinion/coronavirus-pelosi-sick-leave.html <comment><USER2> Being an European this is totally incomrehensible to me. I'm not sure if America is going the UK route of handling the virus, but they'll be in lockdown soon and this kind of measures surely can't help.

Seems this virus will underline our social, technological and other differences. Anyone has any good read on this kind of subject?

<comment><USER3> The people making these laws are completely out of touch with reality. Come to think of it, so are the people executing them and judging them. When you're a multi-millionaire with no care in the world, it's hard to relate to the huddled, working masses. This is a token law. Just like the free coronavirus testing is a token law. It won't help much because people will still be afraid of bills to go get any treatment (which is definitely NOT free). Only the test is free. The rest will bankrupt you. And when you don't even have sick time at work or you've just lost your job due to this crisis, you can't afford it.

We are definitely going the UK route. We're just not public about it. The government isn't governing. They aren't doing shit. Some state governments are trying, but absent federal leadership and due to all the red tape, they are faltering. The federal government is actively holding testing back. The crisis is already a disaster here. The way this is going, China and Italy will be models of extreme success compared to us. Our CDC is incompetent. Our government is incompetent. They are telling lies about masks and other things. We have almost no testing. Asymptotical to zero for a country this large. We are so fucked. And you know what they'll say? "Thoughts and prayers." Yeah, thoughts and prayers for better leadership. Welcome to the new third world.

<comment><USER4> >The government isn't governing. They aren't doing shit. Some state governments are trying, but absent federal leadership and due to all the red tape, they are faltering.

Americans didn't want a functioning government, they believe the government that governs least governs best, that government can only be grossly incompetent at best, and malicious at worst. They were bored of the status quo and wanted a brick thrown through the window of the establishment so they could watch the system burn.

When your primary standard for elected officials is their entertainment value, government inevitably devolves into a circus. Are Americans no longer entertained?

<comment><USER5> > Americans didn't want a functioning government

 _Some_ Americans, and many of those were duped by propaganda meant to justify tax cuts and deregulation to benefit some businessmen.

<comment><USER4> Fair enough, some, not all.

But still far more than just a few.

</comment></comment></comment></comment></comment><comment><USER6> it also exempts smaller employers. effectively only covering a fifth of the employee population in the u.s.

</comment><comment><USER7> Where in the bill does it say that? [https://appropriations.house.gov/sites/democrats.appropriati...](https://appropriations.house.gov/sites/democrats.appropriations.house.gov/files/Families%20First%20summary.pdf)

</comment><comment><USER8> The title of this submission does not match the title of the article, which is "There's a Giant Hole in Pelosi's Coronavirus Bill".</comment>


Toll roads hurt the poor? - <AUTHOR> https://www.strongtowns.org/journal/2017/3/7/toll-roads-hurt-the-poor <comment><USER2> Solving traffic congestion through toll roads ignores the root cause issues and hurts everyone.

Fundamental to American culture is the ability to travel freely from place to place unimpeded. Toll roads completely undermine this principal, and instead replace it with a tax and a tracking mechanism.

If the goal is to solve congestion problems government should instead encourage business to locate in such a way to allow mass transit to function efficiently. Encourage centrally located downtown districts with vertical builds instead of massive sprawling campuses. This would allow useful mass transit and encourage employee freedom as all businesses are located together.

</comment><comment><USER3> kinda feels like the tail wagging the dog. Roads are there to benefit society not lets charge more to keep those pesky people off my roads. If cities get bigger they need wider roads.</comment>


Ask HN: Has anyone "hacked" Harvard? - <AUTHOR>

I'm going into my junior year at state school in New York. I'm a business student with a 3.0 gpa and with two years left I've decided to excel as best as I can in hopes of getting into an MBA program at an ivy league school.
I think its not out of the question for me to graduate with a 3.5 which I guess is a little low for a Harvard mba, but I've read the undergrad gpa doesn't matter nearly matter as much as the GMAT score and work/outside school ventures.
But this makes me ask the question: has anyone gotten into HBS (or any other top MBA program) without awesome GMAT scores or a super high GPA, but instead had an impressive entrepreneurial resume or something else special that got them in? <comment><USER2> You need to work for a couple of years before you apply to biz school. Worry about finding the right job for now.</comment>