Predictions for 2020–2029 - <AUTHOR> https://medium.com/swlh/9-predictions-for-2020-2029-555312fc69fc <comment><USER2> Under the section on "reimagining search":

> We live in a state of anxiety without a path to financial independence. The > path to creating wealth from last century no longer applies. The path to > reimagining search begins with helping people to understand their money. The > first step starts with delivering insights into the stories that data can > tell.

Not sure what financial independence has to do with search results? I'm not actually sure those sentences really mean anything at all...

<comment><AUTHOR> You are right that section could be much clearer.

Long term transaction data and browsing history could be used to train a federated learning algorithm to generate search results.

Getting access to that data to understand what stories it can tell is difficult ask without offering a lot of value in return.

In the short term I believe providing insights into a persons finances is the way to provide that value.

E.g. if you have an extra $5k how do your circumstances change if you \- pay off student debt \- pay extra on your mortgage \- buy solar \- contribute to your 401k / retirement savings

or showing how changes in spending alters the amount of pretax money you need to earn to support your lifestyle.

or how does your spending compare to people like you?

</comment></comment><comment><USER3> This is interesting, but is essentially taking the present and multiplying it 10x. Which is never really how the future turns out, but always how humans think the future will turn out.

<comment><AUTHOR> I found the thought process of trying to make the predictions quite rewarding to go through, it will be interesting to look back in 10 years and see how close or not they are

</comment></comment><comment><USER4> The section on Nationalism indicates to me that we're heading towards a period of major, great-power conflict. I could see it being a lot of smaller, officially unrelated wars or one big one.

Since WW2 we have enjoyed the longest ever period without direct conflict between great powers. How much longer can we expect this to last?

<comment><USER5> He's really far off about the EU. The EU will fix its problems and join into the geopolitical theatre as a unified block. No one wants to follow the UK.

<comment><USER6> I concur, in fact Brexit might have the reverse effect of France, Germany led EU moving towards a closer union.

</comment></comment></comment><comment><USER7> Interesting. It is fun to look at this and imagine exciting future. Random things I remember predicted about 2020:

\+ Moon & Mars colonization

\+ Touch-screen TVs

\+ consumer computing moves to Google Glass

\+ VR

\+ Universal currency (BitCoin et al.)

\+ Flying Cars

\+ Cars that can run on Land & Water

\+ Household Garbage to electricity converter

\+ Everything runs on Solar power

\+ Doomsday

\+ AGI

\+ Self driving cars

\+ Holographic displays(like in movies)

\+ No. 5 from the article

\+ Biomed breakthroughs (aka Theranos)

These are from various sources I have read. Interestingly, most rely heavily on trending topics/techs of the time predictions were being made without accounting for how tech & field suddenly changes, such as Theranos and blockchain. :)

[edit: fixing list formatting ]

</comment><comment><USER8> What benefits does a distributed ledger such as blockchain provide enterprise scale users?

<comment><AUTHOR> in private consortiums, instead of having data locked up in silos across organisations, everyone can have a copy of the data and build their own view on top of it.

you don't have to trust any party as to the authenticity of the data as you can see every change that has been made.

I wrote about the supply chain use case here [https://medium.com/twohands/lobsters-on-the-blockchain- df599...](https://medium.com/twohands/lobsters-on-the-blockchain-df5998ad817e)

and how I approach looking at distributed ledger tech here [https://medium.com/@ben_longstaff/my-framework-for-how-to- lo...](https://medium.com/@ben_longstaff/my-framework-for-how-to-look-at-the- future-of- blockchain-719f4243491f?source=friends_link&sk=a867889e653507062d357cd4c2581e2a)

:)

<comment><USER5> These problems are already solved with audit logs and apis. Especially at enterprise level.

</comment></comment></comment><comment><USER9> Regarding the section "The World is on Fire": The farmers protests recently in Berlin were a normal expressions of freedom to demonstrate in Germany. Not much to worry about, and a sign of a healthy democracy.

</comment><comment><USER10> Seriously, when will the frivolous soothsaying on every decade predictions ever stop? As soon as I saw (2) and (3) and below I had to stop reading. They are the same speculative lunatics that attempted to predict the price of Bitcoin to rise beyond $20k. After looking at these latest predictions, I just drew a big sigh.

I'm sorry but even my machine learning crystal ball forecasting an incoming tech crash in this decade is more accurate than the majority of these nonsensical 'predictions'.

</comment><comment><USER11> IMHO the search paradigm of 10 links itself needs to be reimagined. One idea is of that of a self-assembling, dynamically updating "view" of the underlying information (without the need to read documents).

I suspect several smart people are working on it and the challenges are many, but eventually, we will get there.

</comment><comment><USER12> > People are scared and want their leaders to protect their jobs from foreign > competition.

It's not 'competition' that people are afraid of, it is unfair government intervention and tariffs. The idea with Trump's trade wars is that if a country imposes tariff's on US goods, the US will respond in kind until those tariff's are removed and fair competition is restored. Whether or not this is actually happening in practice is another story, but to say nationalists are afraid of competition misses the mark.

<comment><USER13> > It's not 'competition' that people are afraid of, it is unfair government > intervention and tariffs.

People aren't afraid of that either, they are afraid of the rise in cost of living compared to the tepid rise of their wages.

</comment></comment><comment><USER14> I predict the vast majority of people will never again understand that new decades, centuries, and millenia begin on January 1st of years ending in '1' and not '0' because there never was a Year 0. Everyone knew that 50 years ago, which is why Kubrick didn't call it '2000: A Space Odyssey.'

<comment><USER15> It's the 20's, deal with it.

<comment><USER16> It is 20s, but not a new decade :)

See [https://en.wikipedia.org/wiki/Decade](https://en.wikipedia.org/wiki/Decade)

<comment><USER17> You all are correct but no one cares. Numbers ending with 0 is what gets attention. Going back to the year 1 doesn't add much anyway since we are pretty sure that the count of years since the birth of Jesus (whoever he was historically) is off.

<comment><USER18> [https://m.xkcd.com/2249/](https://m.xkcd.com/2249/)</comment></comment></comment></comment></comment>


Plivo launches Zentrunk – Enterprise grade SIP trunking - <AUTHOR> http://zentrunk.plivo.com/?ref=hackernews <comment><USER2> Founder of Plivo here.

Zentrunk is our SIP Trunking service that provides you global coverage for making and receiving outbound and inbound voice calls using your current cloud or on-premise communications infrastructure (FreeSWITCH, Asterisk, Cisco Call manager, Microsoft Lync, Skype for Business etc.).

Whether you're looking to add a high capacity carrier that can support your growth, or increase coverage and phone number inventory, Zentrunk can get you started instantly. No minimum spends, carrier negotiations or long-term contracts to maintain, Zentrunk lets you provision SIP Trunks instantly through our user interface or via our API. We are list pricing this very aggressively with further discounts at volume.

E.g (Prices in US start at)

$0.0062/min for outbound calls to local number $0.0030/min for inbound calls on a local $0.45 for a US local phone number

<comment><USER3> Any plans for SRTP/ZRTP support?

Any key differentiators from say Flowroute/Twilio that I should consider?

Thanks.

<comment><USER2> Yes we already support SRTP and TLS. I have no specific inputs about any specific providers but check out what makes us different here:

[http://www2.plivo.com/zentrunk.html#quality](http://www2.plivo.com/zentrunk.html#quality)

</comment></comment></comment><comment><USER4> Wow, awesome. Of all the telco to Internet interface companies I've encountered, Plivo is probably the best.

(SIP trunk quality makes a huge difference. I've been stuck using a Packet8/8x8 number for a while and it is horrible.)

<comment><USER5> Better than Twilio?

</comment></comment><comment><USER6> I signed up for Plivo a couple days ago. It's perfect, best I have seen so far

</comment><comment><USER7> When will you open sign-up? Form is not there.

<comment><USER2> There is a form for beta access at the end of the page. Sign up there and we will get you setup.

<comment><USER7> Oh, I see now. It doesn't appear on my Firefox 45.0 browser :)

</comment></comment></comment><comment><USER8> There are much better/cheaper alternatives, like Bitrix24 - [https://www.bitrix24.com/alternatives/free-plivo- alternative...](https://www.bitrix24.com/alternatives/free-plivo- alternative.php)

Twilio is still the king, though it gets pricey fast.</comment>


Ride services decimate S.F. taxi industry's business - <AUTHOR> http://www.sfgate.com/bayarea/article/Taxi-use-plummets-in-San-Francisco-65-percent-in-5760251.php <comment><USER2> Usually I feel bad for traditional businesses quickly displaced by emerging startups. However, I've been in too many cabs where the driver is constantly on the phone while driving, abusing the speed limit, slamming on the breaks every 8 seconds, foul odors, dirty vehicles, roundabout routes, the list goes on. Good riddance.

<comment><USER3> Amen to that. Living here in SF, the customer service aspect of cabs is appalling. I'm tired of getting dirty looks for paying with a credit card, having cabs with their light on and nobody in them drive right by me, playing the "where are you going" game, drivers talking on phones, and general surliness.

The day the industry unionized, that pushed me over the edge. I'm now 100% using Uber to get around and my only regret is that I didn't try it sooner - it's awesome.

<comment><USER4> Don't forget: Uber and Uber's drivers have been responsible for children's deaths, interfering with the normal course of competitor's business, stuffing blind persons' service dogs in the trunk, price gouging during states of emergencies. All on top of a proprietary, unpublished 'surge pricing' algorithm.

I know you think taxis are the devil, but Uber's behavior as a parent company has been downright heinous.

Personally, I avoid supporting them, whenever possible, and go with better- acting players in the market like Lyft and Sidecar.

<comment><USER5> Not sure why you're being downvoted a bunch for this post (seems like you're just stating facts that have happened, as well as your opinions, albeit in a somewhat negatively biased tone, but nothing out of reason).

So here's an upvote. I'd forgotten and/or downplayed these issues and your post made me reconsider and start using Lyft for the first time (been lazy thus far), so thanks for your post. :)

<comment><USER4> Thank you! I've been watching the downvotes, too, and wondering the same thing! Cynical lolwutf wants to think it's tied to yet-another-overly- aggressive Uber suborg, but who knows.

Glad to provide the perspective! Thanks for the upvote.

</comment></comment></comment></comment></comment><comment><USER6> > The new companies, unlike taxi operators, have lesser insurance > requirements, no restrictions on the number of vehicles they put on the > streets, no clean-air standards and less-stringent background checks.

There are clean air standards for taxis? I'm not sure how well they work, since about half of the taxis I have taken recently (worldwide) have had the engine light on, indicating a likely emissions problem. Since taxis drive so much, an emissions issue on a taxi for a month is probably equivalent to a year on many private vehicles.

That said, even private vehicles have clean-air standards in any state (like mine) with emissions inspection requirements.

<comment><USER7> [https://energycenter.org/programs/clean-cab- partnership](https://energycenter.org/programs/clean-cab-partnership)

[http://www.sfenvironment.org/news/press-release/san- francisc...](http://www.sfenvironment.org/news/press-release/san-francisco-to- add-clean-air-vehicles-to-citys-taxi-fleet)

[http://www.sfmayor.org/?page=684](http://www.sfmayor.org/?page=684)

<comment><USER8> Was just going to site that last one:

2/8/12

"Today 92 percent of the taxi fleet is comprised of hybrid or CNG vehicles. There are 1,318 alternative fuel vehicles out of a total of 1,432 eligible vehicles. CNG vehicles account for 89 of those and the hybrids account for 1,229."

</comment></comment></comment><comment><USER9> _The agency...required electronic information systems in all cabs and encouraged the use of dispatching apps. Most cabs now use electronic hailing apps similar to what the ride services offer._

So it took some healthy competition from startups to get the Taxi industry to actually improve their product? Next, I'd like startups to tackle banks, insurance, hospitals, airlines, and nearly every other established industry.

<comment><USER10> Meanwhile, outside the Valley, across the ocean, five years ago, some regular taxi companies where I lived launched hailing apps, all on their own. No startups required. Maybe the competition was stronger?

<comment><USER11> Where is that? Would be interesting to know how Uber is doing in that market.

<comment><USER10> Stockholm, Uber just entered it, so that's going to be interesting to follow.

To be fair though, Uber's app is (now) better than the existing taxi company apps, with its integrated payments and map where you can see how far away your car is, so there's some value there.

</comment></comment></comment></comment><comment><USER12> I'm going to call this submarine marketing (well, really submarine _lobbying_ ) on the part of taxi companies.

If they were truly in dire straits, they'd be turning in their medallions and the city would be struggling to find new buyers.

</comment><comment><USER13> Never has creative destruction ever been so enjoyable to observe and partake. For all the waiting in the cold, rude cabbies, cash only bullshit, and lack of availability, to the taxi industry of SF, I say to you: you have only yourselves and SF City Council to blame.

</comment><comment><USER14> Yellow Taxi, Green Cab decimated themselves. Living in SF there was one thing you learned quickly: calling the taxi was a complete waste of time. The reason Uber, Lyft, etc won was because they could actually perform a job the taxi's had been failing at for years.

</comment><comment><USER15> > Among biggest impacts of the ride services has been the drop in taxi rides > taken by people in ramp taxis, which carry people in wheelchairs. As the > ride services have grown and the number of cabs has diminished, so has the > availability of wheelchair-accessible taxis, which are costlier to operate.

That's certainly a negative effect, but why would it result from the rise of ridesharing services? If taxi companies need to scale back the number of cars in their fleet, shouldn't they only take from the cars that _aren 't_ accessible?

<comment><USER16> It's worth pointing out that they seem to have a monopoly in handicapped transport too. Not saying this is a major plus and not saying it's a profitable market, but they can at least use it to their advantage in marketing and courts.

<comment><USER17> It's not only not a major plus, it's a minus.

Traditional taxi companies are forced by regulators to provide less profitable accessible transport in exchange for being given a monopoly on taxi services. Part of the way that Uber is undercutting the taxi companies is by not providing services to the disabled (or at least not without added cost).

</comment></comment></comment><comment><USER18> I have no sympathy for the SF taxi industry. I can't count the number of times I was left stranded at 2 AM on a friday or saturday night, having to walk home in the rain. It's about time.

</comment><comment><USER19> Here is the best I can find on the clean air standards. I think pushing taxi companies to use hybrids, all electric, natural gas vehicles, etc. [http://www.sfmta.com/about-sfmta/blog/sf%E2%80%99s-taxis- can...](http://www.sfmta.com/about-sfmta/blog/sf%E2%80%99s-taxis-can-help-you- go-green)

</comment><comment><USER20>
      no clean-air standards

Either the author is attempting to bias their readers or was unintentionally misleading -- California generally requires personal vehicles to be smog tested on a regular basis. I should know; my less than four year old car (at the time) had to be smog tested just this past year.

</comment><comment><USER21> Want to kill Uber and Lyft?

Require drivers to be as ADA-compliant as taxi services.

<comment><USER22> Given how few rides occur (less than what a single taxi driver sees in a month), it seems like the sort of thing Uber/Lyft could subsidize, _particularly_ if all they commit to is the incredibly crappy service levels you get from the Taxi company.

<comment><USER21> The really evil part of me is thinking, and maybe I've got the wrong end of the stick here, like this:

When you request a ride with a taxi-service, it's up to the discretion of the service which car to send. You need something for a wheelchair? Fine, they send you what's available from their fleet.

When you request a ride from Uber or Lyft, those two are just middlemen who put you in touch with one of a thousand little companies. Potentially, each one is available.

So, here's the evil bit: require each ride-providing service (a taxi company or an Uber contractor or a Lyft contractor) to provide a minimum of one or two ADA-compliant vehicles.

The independent contractors for Uber and Lyft immediately go away, except for the one or two that are so wealthy as to be able to afford a ramp-van or other compliant vehicle.

</comment></comment></comment><comment><USER23> wait until NFC truly takes off...

<comment><USER24> Then we can have taxi drivers whine and argue about NFC in addition to credit cards?

</comment></comment><comment><USER25> "decimate", so they reduced it by 10%?

<comment><USER26> Interestingly, asking Google to define "decimate" returns a modern definition, "kill, destroy, or remove a large percentage or part of", and a historical one, "kill one in every ten of (a group of soldiers or others) as a punishment for the whole group".

The English language has apparently moved on.

<comment><USER27> Certain uneducated users of the language may have 'moved on'.

Doesn't mean the rest of us should encourage this misuse.

The word devastate much better suits the intent here, which would leave decimate to continue meaning something quite specific (and useful).

<comment><USER26> Honestly I have never really found a situation where I wanted to exactly (or even slightly) mean reduce by 10%. It is too specific of a definition to be truly useful.

I find it much more convenient, and useful, to have a word that means the current modern definition of decimate. Perhaps decimate is a poor choice to represent that, but honestly not every word has to sound or have roots that directly relate to the definition of the word. It is more important words are used, rather than languish or die in history books.

<comment><USER27> There's somewhere around 1,000,000 words in the English language.

> Honestly I have never really found a situation where I wanted to exactly (or > even slightly) mean reduce by 10%. It is too specific of a definition to be > truly useful.

I hope you realise that your use cases for words isn't the same as every other English-speaker's.

> I find it much more convenient, and useful, to have a word that means the > current modern definition of decimate.

The word you're looking for, as mentioned, is devastate. Perhaps ruin, destroy, wreck, ravage, desolate, demolish, raze, etc. If you're happy with a phrase rather than a single word there's plenty more to choose from to convey your desired meaning.

> Perhaps decimate is a poor choice to represent that, but honestly not every > word has to sound or have roots that directly relate to the definition of > the word.

Agreed, but where words have a specific use (even if not to you) it's frustrating to have their meaning modified to a concept that is more than adequately conveyed by dozens of other, existing, commonly used words.

That's my point.

> It is more important words are used, rather than languish or die in history > books.

I'm not even sure what to make of that claim.</comment></comment></comment></comment></comment>


Computing timelines - <AUTHOR> http://www.epocalc.net/pages/comp_timeline <comment><USER2> "You don't have permission to access /pages/comp_timeline on this server."

<comment> unkown-unknowns Works now.</comment></comment>


Dan Bernstein's CurveCP in experimental release - <AUTHOR> http://curvecp.org/

<comment><USER3> The short summary of CurveCP is that it's essentially an encrypted and authenticated TCP[1] (tunneled over UDP). The main selling point is that it's _fast_ , partly by clever protocol design and mostly by use of highly- efficient elliptic curve cryptography.

It's really cool, but sadly probably doomed to obscurity - <USER2> TCP/SSL/IPSec are "good enough".

[1] Actually, Dan Kaminsky stated that it's perfectly usable as a UDP replacement.

</comment><comment><AUTHOR> Text of his announcement:

Hi everybody,

I've posted information about CurveCP at <http://curvecp.org>; and today's release of NaCl includes command-line curvecpclient and curvecpserver tools. There are many reasons that this curvecpclient+curvecpserver software isn't ready for users yet---among other things,

      * the software hasn't gone through anywhere near my usual levels of
        testing and security review;
      * the software prioritizes simplicity over efficiency in several
        ways, missing some of the speed that CurveCP can provide; and
      * the software handles only CurveCP, without HTTPCurve, SMTPCurve,
        etc.

\---but if you're a programmer interested in CurveCP then I think this software is a reasonable starting point for experimentation and further development.

\---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago

<comment><USER4> Isn't the point to have this work below the application layer? We have to make a new encrypted and authenticated transport layer and also rewrite all of the application protocols?

Then again, with key distribution being done with nym urls the network stack is more like a tangled ball of yarn.

</comment></comment><comment><USER5> Here's Dan Kaminsky's thoughts on the proposal, fwiw, as of a month or so ago: <http://dankaminsky.com/2011/01/05/djb-ccc/#curvecp>

</comment><comment><USER6> And NaCl now has signatures based on curve25519: _crypto_sign_edwards25519sha512batch_.</comment>


Free Book: Introduction to Computer Graphics - <AUTHOR> http://math.hws.edu/graphicsbook/index.html <comment><USER2> Why would you start with OpenGL 1.1 and then introduce shader programs in the context of WebGL? Why would you teach people to use vertex3f at all?</comment>


Microsoft will give you Windows 10 for free if you test it - <AUTHOR> http://venturebeat.com/2015/06/20/microsoft-will-give-you-windows-10-for-free-if-you-test-it/

<comment><AUTHOR> So I'm doing this to use it on a virtual machine. I have an old W7 install on a saved and cloned virtual machine, but I figure this is my path to a free upgrade. Seems legit, currently downloading the ISO from MS as I type this. Being a Linux user, I kinda hate it, but sometimes you need Windows, and I'd like to be able to test out things on it too.

</comment><comment><USER2> not even if they paid me man. not even if they paid me.</comment>


Caching Beyond RAM: The Case for NVMe - <AUTHOR> https://memcached.org/blog/nvm-caching/ <comment><AUTHOR> Disclosure: I work at Intel and submitted the post.

Dormando mentions the test was done with the help of Accelerate With Optane, a collaboration we have with Packet to provide access to servers with Intel Optane SSDs. Check out [https://www.acceleratewithoptane.com/](https://www.acceleratewithoptane.com/) for more info, and you can find me and the Packet team over at slack.packet.net. We're especially interested in open source projects that want to test what they can do with the tech and are interested in sharing what they learned with the broader community. Thanks to Dormando for going first!

<comment><USER2> Skylake cpu? Which model?

Assuming using 32GB dimms to use all six lanes (if Skylake)? This is something that has bit me a few times - most Skylake cpus have 6 lanes, so balanced is 192, 384, etc. Not 4 lanes like we are used to!

Would also recommend trying different ram configs anyways, on our side we have seen better thru put on 768 than on 384. Even 512 performs better in some cases than 192.

<comment><AUTHOR> [https://www.acceleratewithoptane.com/access/](https://www.acceleratewithoptane.com/access/) has the server info. We aimed for a balanced configuration to enable the widest variety of use cases. Not everyone will need to use everything provided, and it might not fit everyone's needs!

</comment></comment></comment><comment><USER3> What's the lifetime of an optane or NVMe drive when used as a constantly thrashing cache? Weeks? Months?

Edit: Missed this the first time through:

> _Calculating this is done by monitoring an SSD 's tolernace of "Drive Writes > Per Day". If a 1TB device could survive 5 years with 2TB of writes per 24 > hours it has a tolerance of 2 DWPD. Optane has a high tolerance at 30DWPD, > while a high end flash drive is 3-6DWPD._

<comment><USER4> They also talk in the paper of keeping the thrashing parts of the cache in RAM. Facebook for example calculates the effective hit rate of a larger set of items and only caches those that won't be quickly purged out / overwritten in secondary storage.

<comment><USER5> It's only four more years before the patent on adaptive replacement caching expires. Then we can use it in memcached ...

<comment><USER6> There is CAR which has almost the same performance and no patent. You can use that.

<comment><USER7> Why not just use LRU?

<comment><USER8> Performance. The Wikipedia page on cache policies is pretty good.

[https://en.wikipedia.org/wiki/Cache_replacement_policies#Clo...](https://en.wikipedia.org/wiki/Cache_replacement_policies#Clock_with_adaptive_replacement_\(CAR\))

<comment><USER7> Wiki says "Substantially" better than LRU but actual results seem to show performance converging to same levels the larger the cache gets. (See page 5.)

[https://dbs.uni-leipzig.de/file/ARC.pdf](https://dbs.uni- leipzig.de/file/ARC.pdf)

[p.s. there is also the matter of the (patterns in the) various trace runs. Does anyone know where these traces can be obtained?]

<comment><USER5> All caches have equal hit rates in the limit when the size of the cache approaches infinity. For finite caches, ARC often wins. In practical experience I've found that a weighted ARC dramatically outperformed LRU for DNS RR caching, in terms of both hit rate and raw CPU time spent per access. This is because it was easy to code an ARC cache that had lock-free access to frequently referenced items; once an item had been promoted to T2 no locks were needed for most accesses. With LRU it's necessary to have exclusive access to the entire cache in order to evict something and add something else.

Of course there are more schemes than just LRU and ARC, and one can try to employ lock-free schemes more than I'm willing to do. This is just my experience.

<comment><USER9> ARC often wins against LRU, but there is a lot of left on the table compared to other policies. That's because they do capture some frequency, but not very well imho.

You can mitigate the exclusive lock using a write-ahead log approach [1] [2]. Then you record events into ring buffers, replay in batches, and have an exclusive tryLock. This works really well in practice and lets you do much more complex policy work without much less worry about concurrency.

[1] [http://highscalability.com/blog/2016/1/25/design-of-a- modern...](http://highscalability.com/blog/2016/1/25/design-of-a-modern- cache.html)

[2] [http://web.cse.ohio- state.edu/hpcs/WWW/HTML/publications/pap...](http://web.cse.ohio- state.edu/hpcs/WWW/HTML/publications/papers/TR-09-1.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Facebook has recently published a paper on how they use NVM caches with their MyRocks (MySQL) databases; the morning paper has a really good write-up: [https://blog.acolyer.org/2018/06/06/reducing-dram- footprint-...](https://blog.acolyer.org/2018/06/06/reducing-dram-footprint- with-nvm-in-facebook/)

</comment><comment><USER11> The limiting factor of Optane is actually the controller. The power consumption of the controller itself, as well as the costs of getting high bandwidth to and from CPU and memory. Current products are striking a conservative balance and in the future they could get much faster.

</comment><comment><USER12> An adapter that splits a single PCIE slot(x16) to hold 4 x M.2 NVMe SSDs(x4 each) would be a great way to persist a Redis instance that is not just serving as a cache.

If the same can be done with Optane SSDs, the lower latency will at higher queue depth will certainly help.

<comment><USER13> This already exists: [https://www.tweaktown.com/reviews/8542/asrock-ultra- quad-2-c...](https://www.tweaktown.com/reviews/8542/asrock-ultra- quad-2-card-16-lane-aic-review/index.html)

<comment><USER14> This is not a low profile card, and wastes quite a lot of space. It should take two cards on each side of the board, with the connectors facing orthogonal to those of the x16 slot.

<comment><USER15> You can't put something as tall as a M.2 connector on the back side of an expansion slot without violating the form factor guidelines and enchroaching on the space of the next slot over. The only compliant way to put M.2 drives on the back is to use an offset edge connector so the main board is a bit lower than it usually would be. Amfeltec has some boards like this, but I think they have a patent on their offset connector. [http://amfeltec.com/products/pci-express-gen-3-carrier- board...](http://amfeltec.com/products/pci-express-gen-3-carrier-board- for-4-m-2-ssd-modules/)

<comment><USER14> Oh. Well, there are cases where it would fit without such an exotic connector, but those are non-compliant.

I assume you don't need licenses for just making a dumb PCIe card, if you don't name it with trademarks? Or are there patents you need to license to sell PCIe-compatible, non-electronic cards?

</comment></comment></comment></comment></comment><comment><USER16> What would be interesting to see is if this benefit would be better applied directly to the database instead.

The relative scarcity of NVMe ports/bandwidth per server may make that as unattractive as doing the (RAM) caching on the database server itself, but it's not obvious, if one could only spend the money in one place, where it would be best spent.

<comment><USER17> NVMe drives use 2-4 PCIe lanes, so you can have quite a few of them in a system with a suitable adapter.

<comment><USER16> I'd say that's comparable scarcity to DIMM slots, as the ratio between those and PCIe channels tends to be in the range of 1:2-4 on current CPUs.

</comment></comment></comment><comment><USER18> Is there any reason why memcahced/redis doesn't provide external store as an interface and let people implement the load/store operations? I would like to be able to implement hierarchy of "hot(RAM) -> warm(NVM) -> cold(SSD) -> DB" style cache.

<comment><USER19> no reason, it's doable with a bit more cleanup. The I/O bits are encapsulated entirely in extstore.c with a relatively clean interface. it's not a layered setup, it's actually bolted all into the same hash table, which makes pluggable I/O systems not make much sense.

it ensures that a lot of operations can't touch secondary (like miss, touch, delete, sets of new items, etc), which reduces load on the IO by quite a lot.

edit: Also extstore itself will support NVM + SSD sort-of-layers soon enough. I'll be retesting that on the same optane+ssd machine in a couple weeks.

</comment></comment><comment><USER20> Could have just used LMDB memcachedb and gotten the RAM/NVMe cache management transparently, for free.

[https://github.com/LMDB/memcachedb](https://github.com/LMDB/memcachedb)

</comment><comment><USER21> It is very exciting to see Optane competitive with conventional NVMe drives -- this is something that Intel got right early and their exploration into DIMM- socketed Optane drives is similarly exciting.

It has already been established that for most consumer workloads, the latency differences between memory and Optane is negligible. This article shows that heavy-duty workloads (ie: high-traffic memcached clusters) can be accommodated by Optane and NVMe too. Clusters of 500K IOPS drives can take us most of the way there.

I don't want to get all /r/hailcorporate but Optane drives are great products and (more importantly) you can run them on AMD platforms (ie: SP3) too. Granted, NVMe drives bring the fight and they're much more cost competitive at scale, but that will change soon.

<comment><USER22> I love toys and I would love to jump feet first into optane, but a dollar per gigabyte is hard to stomach.

<comment><USER23> About a decade ago, I paid around $600 for the 80GB X25-M, the first SSD that focused on performance rather than _just_ low latency. One of the best system upgrades I've ever had.

A dollar per gigabyte doesn't seem half bad at all for the top end of performance.

<comment><USER24> My first hard drive upgrade was a 80MB HardCard - an ISA hard disk for my PC XT 286. I recall it cost clost to $1,000.

There's always going to be the top tier storage that costs an arm and a leg - that just means two steps down gets affordable. Optane pricing will drive down NVME which will drive down SATA SSD.

<comment><USER25> The main issue is that video gamers don't see any benefits to NVMe NAND drives. So the "hardcore gamer" market is beginning to stall out on SATA SSD drives.

Why pay 2x more for NVMe NAND if your video game load times aren't any better?

<comment><USER26> They are better at load times. Just not 2x better.

<comment><USER24> The price/performance of a couple 860 Evos in raid0 is hard to beat</comment></comment></comment></comment></comment></comment></comment>


Go is Google's language, not ours - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage <comment><USER3> Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it is hard to form such a community and keep it alive.

For a community-driven project from the size of a database some serious sponsors would be needed. Good examples are Rust, Linux, and PostgreSQL. I wonder why so many companies are happily paying Oracle (and the likes) tons of money instead of sponsoring an open source project like PostgreSQL.

<comment><USER4> I'm curious what the distinction is between Rust (driven by Mozilla) and Go (driven by Google).

<comment><USER5> I had a similar question, but rather, what's the difference between Go with Google deciding what goes in, and Python (a year ago) where the BDFL and a couple core devs decide what go in?

Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.

<comment><USER6> I guess the most important distinction is the "B" part (benevolent). Guido is called that because he is known (since before BDFL is a thing) to listen to other people, and adapt when they disagree strongly with his decisions. Google has never demonstrated the same attitude afaict, and in multiple occasions showed exactly the opposite.

Edit: And to answer the question, no, there's no philosophical differences. And there's nothing wrong with that. Python never called itself a community's language (there are instances core devs said in no ambiguous terms that it is Guido's project). The problem only arises if a project gives an impression that it is owned by the community when it actually isn't.

<comment><USER7> Wasn't Linus the original BDFL?

<comment><USER8> Seems to have been Guido.

[https://en.wikipedia.org/wiki/Benevolent_dictator_for_life](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)

> The phrase originated in 1995 with reference to Guido van Rossum, creator of > the Python programming language.

</comment></comment></comment></comment></comment></comment><comment><USER9> Many like Go because it is an opinionated language. I'm not sure that a 'community' run language will create something like that because there are too many opinions. Many claim to represent the community, but not the community that doesn't share their opinion. Without clear leaders I fear technical direction and taste will be about politics which seems more uncertain/risky.

I like that there is a tight cohesive group in control over Go and that they are largely the original designers. I might be more interested in alternative government structures and Google having too much control only if those original authors all stepped down.

<comment><USER10> My thoughts exactly! It's important to have a community and to work with it, but, especially for a programming language, there has to be a clear concept of which features should be implemented and which not - just accepting community contributions for the sake of making the community feel good would be the wrong way. Otherwise you end up with a feature monster like innumerable other programming languages, and that's exactly what Go doesn't want to be.

<comment><USER11> Go is somewhere in the middle of the spectrum between Lua (dictatorship) and C++ (endless politicking).

</comment></comment></comment><comment><USER12> It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations.

Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team))

There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2]

The way how Go team handles potentially tectonic changes in language is also exemplary – very well communicated ideas, means to provide feedback, and clear explanation of how process works. [3]

Plus, many people in Go community _do not want_ generics in Go (at least, in a way they're implemented in other languages). Their opinion also matters.

[1] [https://news.ycombinator.com/item?id=9622417](https://news.ycombinator.com/item?id=9622417)

[2] [https://blog.golang.org/toward-go2](https://blog.golang.org/toward-go2)

[3] [https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft.md)

<comment> brown9-2 In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: [https://github.com/golang/go/issues/12914#issuecomment-15075...](https://github.com/golang/go/issues/12914#issuecomment-150754067)

<comment><USER12> It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community".

So we have

a) Google having problems with lack of monotonic clock in Go

b) Go team reluctant to break API and break promise of compatibility without really serious reason

c) community feedback in form of well written experience report, explaining how serious the issue is for the community

d) immediate reaction and efforts to find a solution (without breaking API)

Even though team was dismissive of the idea, feedback from the community made them to change their minds.

<comment><USER13> Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.

<comment><USER14> It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they _have_ been spending their time on, rather than pointing out that they haven't spent much time on something.

<comment><USER13> The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.

<comment><USER12> I disagree, as I remember a lot of talks and articles from Go team members where they discuss in detail established work in other languages – on GC, on language evolution, on generics and so on – and deliberately learn from them to avoid same mistakes.

<comment><USER13> It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: [https://news.ycombinator.com/item?id=19979613](https://news.ycombinator.com/item?id=19979613)

<comment><USER12> The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.

<comment><USER15> They stuck their heads in the sand refusing to have a package manager for like 8 years and asking people to put dependencies on a vendor folder.

That's _not_ learning from established work.

<comment><USER12> First, Go had package management – it just has been optimized for monorepos.

Second, since early days of Go, they said that acknowledge their Google monorepo bias, and can't implement package manager that works for everybody without understanding what people outside of Google need. They consciously gave time for community to grow and mature and get enough feedback before implementing proper solution, while actively studying package management solutions from other languages.

I definitely can't call it "refusing to learn from established work". Of course, they could've just copy existing suboptimal solutions without properly giving it a thought – that's what most of the languages do, after all – but that's where Go choses another path.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before.

Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worry about if you're writing Go "the right way", because it's extensively documented what that way is.

Generics is an awesome feature, writing C# is my day job so sometimes I miss it, but I have full faith in the designers when they say it will be in the language in a "Go appropriate way". The last thing I personally want to see is Go being handed over to the community to be designed by committee.

<comment><USER17> I completely agree. When I first started writing Go (coming from Python/C#) I complained an awful lot about what felt like pointless hamstringing of functionality. Go is a simple language, and you don't get many toys. It also feels very verbose at times, and forces you to think a _lot_ about doing things which seem automatic in other languages.

However, as time went on, I noticed a few trends. Firstly, forcing me to think more revealed that what I had thought was automatic was more automagic - <USER2> forces you to take responsibility for what your code does to a far greater extent than other more convenient languages, albeit not to the extent that C/Rust does. Secondly, I noticed that code written in Go tends to do what I expect it to pretty much all the time (with the occasional except of async stuff). Sitting down and writing a program in Go often results in something that actually _works_ the first time it runs, and has far fewer runtime surprises.

As painful as it is to do numerical computation in Go sometimes, I have a very high level of confidence that I can look at a program, deduce with some accuracy its runtime memory usage & footprint, multithread it easily, and reason (successfully) about possible runtime failure modes and behaviour. This is something I find difficult if not borderline impossible to do in Python, especially utilising the standard '10 layers deep' stack of numerical computing libraries.

<comment><USER18> Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot.

It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python.

But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we exposed to for a long.

Say like, PHP was a fractal of shit, but when you use it for a long you will notice that it will make you more aware of what functions to use and how not to fall into some undocumented craphole, be more responsible, and do not take it for granted that some function would work flawlessly. The obvious benefit from the shitty situation.

EDIT: Grammar

<comment><USER19> The nice thing about walking minefields is learning how to watch your step.

<comment><USER20> "If you're walking on eggshells, don't hop."

\-- unknown

</comment></comment></comment></comment></comment><comment><USER21> Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for you with crypto and security.

Generics and zero-cost abstraction can and are concepts that are often abused instead of used when it makes sense. I hope thay Go will never support generics because I sincerly believe it might mean the end of the language

<comment><USER22> I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor.

Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all types versus in Go, a bunch of different implementations of the same thing that you have to check and might have subtle errors?

<comment><USER23> > _" My understanding is that they always planned to have generics, they just > didn't make 1.0 and now the Go community has sort of adopted the lack of > them like a badge of honor."_

As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android had it, copy/paste was a misfeature for idiots. When iOS implemented it, copy/paste became the best thing since sliced bread.

<comment><USER20> See also: Java Generics.

</comment></comment></comment></comment><comment><USER24> The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation.

My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they interact with daily (ie, other Google employees) over people they barely know.

<comment><USER25> The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.

<comment> jon-wood I don't really get this distinction. "Google as a corporation" isn't a thing, it's a collection of people, some of whom happen to be the Go core team. It's likely that due to being close to Go developers at Google there's a bias towards implementing features that would help those people, but I very much doubt the subject of genetics in Go comes up at board meetings.

<comment><USER26> Implementing features Google needs sooner, rather than later, is one thing, but at some point, Google-the-profit-driven-corporation's needs will contradict the broader Golang community's needs, at which point the question is who "wins"?

What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all.

Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.

</comment></comment></comment></comment><comment><USER27> For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again.

It needs close parenting. Java has been ruined by the push to include everyone's pet feature.

<comment><USER28> >everyone's pet feature

Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.

<comment><USER29> > Java has only things that were proved to work in other languages.

But they still somehow keep finding ways to make them not work so well when implemented in Java.

C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.

<comment><USER30> Idk, have you seen the interfaces with default implementations in latest C#? Also duck typing? Both are mistakes IMO. First missteps I feel like I've seen C# make.

<comment><USER31> If by "duck typing" you mean dynamic, then I don't know what you're complaining about. It has a very niche set of use cases where it is needed. If people are abusing it then it's on them. There is no good or even alluring reason to use dynamic outside of it's intended purpose, so I don't feel like it's one of those "shiny hut dangerous" features you see in some other languages.

</comment></comment></comment></comment></comment><comment><USER32> Google are bad at building developer communities (or at the very least they don't care about it much). They build things for themselves and their way is the Ivory Tower way of running a community. The overlords decide and their word is set in stone, the plebs should just accept the fact that their concerns and use cases are just too trivial and they should listen to the smart people at google and do it their way, which is the only way.

This isn't the first time google open sources internal tools, trying to build a community but really ignoring them completely. GWT, Closure compiler and of course Angular comes to mind.

Angular built a great momentum and community, and the angular team at google basically ignored most ongoing concerns to work on their next big project that'll fix everything (first it was Object.observe, then dart then angular 2).

Contrast google's handling of Angular to Facebook's handling of React (and react-native) - The routinely incorporate community influencers into the core team, they include other major corporations in their decisions and community, actively engage in developer relations to get feedback, explain controversial choices and build a community.

Sun's model with Java is even more different - incorporating major stakehodlers in the language into the actual decision process via the JCP.

Of course Google isn't the only ones who are bad at building developer communities around their open source. Apple and Amazon barely even try.

If google is Ivory tower, Microsoft is the Herbalife way of building a developer community - actively supporting influencers, providing official seals of approval and using a top down hierarchy of advocates. They do listen to community input a lot more, but Microsoft is still the overlords of all their projects.

<comment><USER21> Saying that they have failed to build a community around Golang is totally wrong

</comment></comment><comment><USER33> I'm so tired of people purporting to speak for "the community" \- especially when they diametrically oppose my own views. It feels a lot like they are co- opting me for their own agenda while simultaneously excluding me.

The things mentioned as evidence that community doesn't matter have a _lot_ of buy-in from the community. Modules in particular are an effort that - at least from what I can tell - is heavily driven by non-Googlers (in particular Rog Pepe, Paul Jolly and Daniel Marti are people who put a lot of work into making modules actually work for practical workloads).

These kinds of pieces only make sense if you have an extremely limited view of who is or is not part of "the community" \- in particular, if you throw everyone agreeing with the Go team out of that bucket.

</comment><comment><USER34> Haskell is an excellent example of a community-driven language. It's more mature and advanced than most commercial offerings too, offering a superior type system, fast and efficient executables, lightweight fiber concurrency, software transactional memory, higher-kinded parametric polymorphism and many more features.

<comment><USER35> Haven't most of the top Haskell devs been on the Microsoft payroll for years and years?

<comment><USER36> SPJ is a Microsoft Research Cambridge employee, but as far as I know that doesn't give Microsoft Research (let alone Microsoft itself) any undue influence over the language's direction, they can't gatekeep or ram things into Haskell or GHC.

<comment><USER35> It would still be corporate sponsorship and not a true community effort though. Not having to work to pay bills makes it much easier to run a large project.

<comment><USER36> Pretty sure SPJ does have to work to pay bills. It's just that they work for a research institution and can thus do part of their work in / on the project. In no small part because _CS research was one of the use cases for creating Haskell_.

</comment></comment></comment></comment></comment><comment><USER37> I've only followed the modules controversy tangentially, but I did go to a presentation by Sam Boyer, where he started getting emotional and muttering about organizing some sort of resistance movement. Russ Cox made it a point for Go's regex library to have bounded worst-case performance at the cost of worse average time, and Go's fast compilation times are a source of pride for the core team. That they would frown on a dependency management system like dep that is based on a NP-complete algorithm doesn't seem to have struck Sam as a total deal-breaker. In this respect I am fully behind Cox. As the OP says, the Go team has taste, and I want them to keep the language simple, sane and manageable, not a monstrosity like C++, Java and now sadly Python as well.

</comment><comment><USER38> "... can't we have something like OpenGo ..." > " ... this won't happen ... "

I'm confused as to what's stopping someone from forking it, calling it OpenGo, and building a community around that.

<comment><USER3> This could be done, of course. But how likely is such an approach to succeed? It would effectively create a new language and in turn to a new ecosystem. Why not just use a different language (Rust comes to mind) then?

<comment><USER39> Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?

<comment><USER40> A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.

<comment><USER41> Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me.

There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author):

>>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few:

>>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency.

>Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it's true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it's a matter of opinion.

That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article.

And that's the issue! It was not a point for debate. Google was being forthright. Google was saying " _from day one_ " it was a _literal_ showstopper, and the community seems to have read it as a _figurative_ showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go.

[1] [https://peter.bourgon.org/blog/2018/07/27/a-response- about-d...](https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep- and-vgo.html)

<comment><USER42> > Google was saying "from day one" it was a literal showstopper,

For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.

</comment></comment></comment></comment></comment></comment><comment><USER43> The post makes it sound as if Go being Google's language (not the community's) is a bad thing. I don't see where this sentiment is coming from as the strong opinions enforced by Go core devs is probably one of the defining features of Go.

As with many open source projects under benevolent dictatorship, this can result in streamlined and consistent features with long-term success.

</comment><comment><USER44> There is an assumption here that the community is unified, you are part of the community, and therefore if the community doesn't get what it wants, then you don't get what you want.

Actually, the community disagrees on stuff, so you're unlikely to get what you want, regardless. The only way you always get what you want is if you write your own language. (Assuming you're skilled enough to implement it.) But a language nobody else uses is of little benefit.

There needs to be some core team that makes coherent decisions. Unless the community is tiny, the core team is not the community. There are inherently tensions. However it's unclear that Go's core team is doing worse at listening to their community than other language's core teams?

<comment><USER45> 100%. Look at Ruby's community. It's a pretty great community in my experience, but at the end of the day Matz, Kokubun, etc. act as gatekeepers.

Democratic creation of software would be a disaster. There's so many philosophies of development and differing opinions that you wouldn't be able to make progress. At the end of the day the reason a language exists is to implement the vision of those who created it. The community is a labor force to implement, test, and verify the decisions made by the heads.

I totally encourage people to write their own languages though. A language no one uses can be beneficial to computing at large as experiments in language implementation. We all know silly languages like Brainfuck that you would probably never use for work, but can be useful learning tools.

</comment></comment><comment><USER46> It can be forked it if the opinions are widely shared and you think people will support you to run it better ? The tone of the article seemed to be casting shade relative to the institution funding it's development as the foundation of why there are problems ? It's normal in a large scale open lanuage there will be disagreement around direction of the project.

Many models around how those disagreements are resolved exist across many projects. You can choose one of them or build your own project and make your own decisions :)

<comment><USER47> I'm convinced that the people who just suggest forking an open source project with 100s or 1000s of man years behind it lack practical experience in building or maintaining large software systems.

Dismissing valid criticism with "just fork it if you don't agree" has got to be some of the most useless advice parroted around open source.

</comment></comment><comment><USER48> To their credit, the Go team withdrew most of Error Values draft 2 [1] after a great deal of negative feedback. However, they've kept one unpopular change to fmt.Errorf().

We can hope that draft 2 of Error Handling [2] won't look anything like draft 1, for reasons such as [3].

[1] [https://github.com/golang/go/issues/29934](https://github.com/golang/go/issues/29934)

[2] [https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback](https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback)

[3] [https://medium.com/@mnmnotmail/golang-how-dare-you-handle- my...](https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my- checks-d5485f991289)

<comment><USER49> From [1]:

> The most contentious point of the original design was the special-case > handling of a trailing ": %v", ": %s", and ": %w" in the format string, > which did not follow the usual printf model in which the meaning of % verbs > is context-independent and all non-% text has no meaning at all. We will > remove those special cases from Go 1.13.

At least, they removed the really ugly special cases!

[1] [https://github.com/golang/go/issues/29934#issuecomment-48968...](https://github.com/golang/go/issues/29934#issuecomment-489682919)

</comment></comment><comment><USER50> > Python has always been Guido van Rossum's language regardless of who he > worked for at the time.

(from the article) I think the high-level point that Python has not been tied to a company is true, but it's not been true that Python is "Guido's language" for decades. Python has a very effective community process. Guido has certainly served as a tie-breaker and of course as BDFL (no longer!), but I see the language being largely steered by the community and community leadership.

</comment><comment><USER51> I believe that solid (benevolent) dictatorship is better(faster, can make unpopular decisions, etc) than democracy.

I don't like any language, but tbh I hate go the least, and I believe this is because few very very dedicated people with enormous amount of experience can simply make unpopular decisions.

</comment><comment><USER52> This.

But Go is one in a long line of proprietary languages that those of us who have been around the block know to stay away from. Recently: Java was Sun's, C# is Microsoft's, Swift is Apple's, Go is Google's. With any luck, all will be footnotes in ten years. Those of us who knew better than to get invested in them will be fine. Everyone else gets a chance to learn something.

<comment><USER53> Each of the languages you mentioned is wildly popular, well run, and not going anywhere. If you chose not to learn Java a decade ago because you "knew better" you aren't any better off than you were before, given that this language is the core foundation many companies and open source projects, maintaining relevance for 20 years. Not learning Swift now means you won't be able to do effective IOS development. Not learning Go means you're missing out on the language that a lot of important systems software is built in such as Kubernetes and Docker and won't be able to contribute to them.

I think also it's inaccurate to call any of these languages proprietary. They are all open source and if you wish you can fork them and make your own. C# in particular is now run by the dotnet foundation which is nonprofit with elected board seats, putting it in a better place for governance than many community driven languages.

<comment><USER52> You can fork them and become (or remain) irrelevant.

Ios development is a walled garden. C# is barely used except to target Windos. Go? Too early to say. If it did fade away, who would miss it, _really_? Its express design purpose was to be not powerful enough to make big mistakes in. Has it transcended that? If so, what is its purpose now?

Java has shown staying power, despite its shortcomings, although its connection to the Apache Foundation ("where projects go to die") offers just a ray of hope.

<comment><USER54> I write software for embedded Linux devices in C# for a living, not exactly targeting Windows now is it?

<comment><USER52> That use qualifies neatly under "barely".

</comment></comment></comment></comment></comment><comment><USER55> I like Go's concurrency approach and its concurrent GC implementation, but I personally don't like the language that much. It would be awesome if the runtime system could be factored out, and targeted by other languages.

</comment><comment><USER56> No matter how good it is, I won't invest personal time in Google's products because Google like to kill Google products.

<comment><USER57> technically Go is not a product but your point still stands.

</comment></comment><comment><USER58> I really wish Go had learned a lesson from Java: programmers will eventually want generics, and adding generics to a language that was not designed for them leads to new and unexpected obstacles.

The lack of generics makes Go uniquely unsuitable for functional programming, an unfortunate outcome when functional programming is the New Cool Thing.

<comment><USER59> > New Cool Thing See that's your issue. Go tries super hard to _not_ be that > and evidently has succeeded.

<comment><USER13> The original view of the golang authors was that it was made to replace C++. It obviously failed at that, and ended up being used as a faster Python.

</comment></comment></comment><comment><USER60> There are 2 things I like about Go,

1\. Compared to most compiled languages the toolchain is very easy. 2\. Reduced ways of solving things in the language itself.

My main dislike of C and C++ is that there are numerous ways of solutions for the same problems, this forces me to weigh the solutions constantly against things like "Is this a safe way, does it create fast code, will this way fit when my project is further or must I constantly refactor my code". The extreme flexibilty of C and C++ are more a burden for me than an asset.

<comment><USER61> I personally also dislake C++'s standard library, lack of standard functionality in it and the difficulty of maintaining dependencies and the whole resulting build process with crosscompilers. GNU Make was not enough, CMake was not enough, GN is almost rocket science, then there is Meson. And choice of clang or gcc. Chrome/Fuchsia is an example of how complicated it can be. But does it have to be like that? There are definitely good reasons to use C++ or C in some cases (system, low-level, games etc) but C++ is a difficult language and it's not necessary for lot more other cases. Rust is yet another story, solving some problems but making new ones.

Go made me enjoy the programming again. And of course, managing modules is a very difficult task so it had to be done somehow and somehow really, really good and I think they delivered the working solution. Various previous attempts were bad for various reasons (Kubernetes can tell you).

</comment></comment><comment><USER62> Go is designed with Unix philosophy in mind by people who created C and then wrote Unix in it. So lucky us that they are the gatekeepers.

Having said that, Go's license allows everything and it would be interesting to see a fork and compare it with the mainstream a year from now.

</comment><comment><USER63> _There are many answers for why this won 't happen, but one that does not usually get said out loud is that Go is Google's language, not the community's._

More precisely, its design belongs to a small number of capable people who are on the same page, with regards to a pragmatic, minimal-ish design. This is better than a "benevolent dictator," in that there are some checks and balances. It's also better than design by mass committee from the public.

</comment><comment><USER64> No shit Google has the final say, they're the maintainers. They pay developers millions of dollars to make the final call on what's best for the language. Even if someone were to start a community fork there would still have to be a central board of governance.

Suggesting that we should split the community for a feature that you like in other languages is a dumb and lazy argument.

</comment><comment><USER61> It is actually a good thing. The more forks there are and more complicated ideas and toys, the more mess and chaos. It can eventually kill the whole ecosystem.

I love open-source and libre software but there needs to be some central authority who oversees the changes and is forward-thinking. I actually love Go in the way it is and it wouldn't be it if you kept asking community what features to integrate. I am looking forward to generics as it solves some cases (containers holding items of a templated type sharing some common methods). But even if Go stayed the way it is, I would be fine. The point of open and libre in this project for me is that Google can't shut it down and that's enough for me in the case of prog language.

Please, if you want to make super-crazy-new community-driven uber-language which will change the world, make yet another and truly yours language or join Rust or whatever more community-driven language you like. Thank you! :)

</comment><comment><USER65> The problem I have with the article is that, as an outsider, it reads like this is not about Google. It reads like this is about features that the author liked which were not merged.

In an alternative timeline where Go was not sponsored by Google, deciding what to merge into it and what to leave out would fall into some sort of "Core Team". In that timeline, if that Core Team decided to not include the features that the article author is describing, then we would have an article titled: "Go is The Core Team's language, not the community's".

I can only offer one answer. Maintaining an open source project is a lot of work. If you care enough about those changes, make a fork, include those changes, and maintain it yourself. If that's too much work, then you are stuck with what others able to dedicate the effort decide.

<comment><USER66> Do managers of open source projects typically get paid? Seems like a lot of work for a volunteer...

</comment></comment><comment><USER67> This is a difficult one. On one side we have a massive corp that is pushing it's own language and essentially steering it the way it wants.On the other, there's ever growing community that has its own ideas and suggestions on how the language should evolve. I'm too early in my journey woth Go to be able to have in-depth discussions on its functionality, however what I don't want to see it turning into another JavaScript,which is such a mess and free ride for everyone who thinks they have another good idea how to fix it.Unless there's a proper independent steering committee,I can't see this working too well without Google's ownership.

</comment><comment><USER68> Yeah, that's the case with any coherently designed language or software package. I don't really have a problem with it. Now that they've come up with a workable module system, the issues of it coming from Googleworld are minimal. I don't personally care about generics, and I like the error system so I find Go to be a great language to work in.

But that's all just my personal opinions. What I found interesting was the callout of OpenJDK as a community-run language, but is it? I feel like OpenJDK is the worst of both worlds. Too much corporate overhang, _and_ all the worst aspects of design by committee. But YMMV.

</comment><comment><USER69> Oooph, from my perspective, this is the very same thing with clojure, and the single thing that drove me away from the language. Substitute spec/schema for vgo/dep, and you're telling the same story.

I value individuals and companies sharing their developments with a community. One has to remember though, to own something is different from benefitting from other's work, and if you want to have a say, you'll need to get your hands dirty, fork, and work.

</comment><comment><USER70> Nice to read all the comments on this story. The story is about the how Go is not truly open source and community driven and the flame war starts on how Java does not implement generics correctly etc. Guys: each language has it's benefits and it's shortcomings. If we want (need?) more control over the language, can't we just fork it? Start a new language that is based on the current implementation of Go?

<comment><USER61> exactly. Or what prevents them from using beloved and 100% correct Java in the first place?

</comment></comment><comment><USER71> C# unfortunately has the same issue, but the effect is much more visible. Few people (I'm sure you can find examples, but given how popular the language is on Windows, it's a tiny minority) use C# outside of Windows and it's a shame. There is no good open ecosystem so even as a former Windows dev I hardly use it anymore.

<comment><USER72> The limiting factor for me, as a long-time C# dev now working outside of Windows, is that many of the tools I used haven't been ported to .NET Core.

Take Umbraco, for example. If someone were to port it to .NET Core and rewrite parts of it to use Postgres as a db option there would be zero reason to ever use WordPress again.

<comment><USER73> Other than like 90% of ISPs only offer cheap hosting for PHP.

<comment><USER72> You're right, although I'm not sure if people necessarily go to their ISP or to the cheapest host possible.

Most of the time, in my experience at least, someone that wants cheap hosting and is using something like .NET or Python will Google "cheap python hosting" and see what is cheapest/recommended.

PHP tends to be the outlier, because it's absolutely everywhere, but I think the web has matured to a point where people will look for specific hosting for their choice of tech. Hell, back in my freelancing days when I used to rebuild broken WP builds, most people that weren't given hosting by their client chose it from looking up "cheap wordpress hosts".

<comment><USER73> When time came to replace my XML/XSLT based website by something else, just to get up with the times, I resisted to touch PHP, but in the end having it at my ISP versus the trouble of using something else won.

Nowadays I am able to use PHP 7.x, so I just keep using it there, and suggesting it for the less tech savy friends that want some kind of dynamic website.

Because while I do build sites in Java and .NET, I do accept that they aren´t that easy to set up at most ISPs, and cloud based one click solutions tend to be more expensive.

</comment></comment></comment></comment></comment><comment><USER74> This is absolutely true. In general I feel like it's good when a language belongs to a core team, but they don't appear to be learning from past mistakes. The core team put out a proposal for modules and then immediately implemented it with very little community feedback except what could be done after the fact without breaking much. There was huge backlash and they claimed they would do better and seek community feedback earlier, but now they require that you use a Google web service when fetching modules (I've turned it off) and shoved that out between two versions without any community feedback as well.

Strong central leadership is great, but leadership needs to actually listen to the people they're leading (and not just as an after thought).

</comment><comment><USER75> Agree that generics are much needed but also wary that if you let the community take charge then you end up with a frankenstein language like PHP.

Also a huge fan of go mod over vgo so I had no issues of them scrapping the community dependency manager and rewriting it to be part of the language

</comment><comment><USER76> > In practice we'll only get a chance to find out who Go really belongs to if > Go core team members start leaving Google and try to remain active in > determining Go's direction. If that works, especially if the majority of > them no longer work for Google, then Go probably is their language, not > Google's, in the same way that Python has always been Guido van Rossum's > language regardless of who he worked for at the time.

This is laughable. Anything built within Google belongs to Google. There's no way the company will let anyone from the core team leave and take the language with them. Keep in mind, Google's version of Go and the community might be vastly different, as the former has different needs versus the latter.

</comment><comment><USER77> I really like C and common lisp in that they do not seem to be owned/driven by a singular entity

<comment><USER78> And that they have two excellent, interworking implementations. And a language spec, by ISO even.

</comment></comment><comment><USER79> I'm not sure what this article is trying to say. Microsoft C# is a Microsoft project. Go is a Google project.

There is someone who need to govern the project. This is a company in these cases.

The only other option I see is some board like (in case of .NET) the .NET foundation to allow more control.

</comment><comment><USER80> Golang solves a specific domain problem google has.

They extended plan9s c compiler with some syntax Sugar for co routines and fixed some whacky c stuff then threw in some gc.

There's new and innovated about golang.

They just had to open source golang because they used the plan 9 c compiler which was open source.

<comment><USER81> A small group of programming language professionals with fifty+ years of shared experience developing compilers decided to keep on going with the language family they invented and extended.

<comment><USER40> I'd say they have fifty+ years of implementing the same language over and over. During the fifty+ years they studiously avoided learning what anyone else had been doing, and it shows.

</comment></comment></comment><comment><USER82> >> _But Google is the gatekeeper for these community contributions; it alone decides what is and isn 't accepted into Go._

So ... much like Linux where Linus is the gatekeeper, and he decides what goes in and what doesn't, and also abuses people while at it?

<comment><USER10> But he's trying to be nicer, so cut him some slack :)

</comment></comment><comment><USER83> People don't care who owns Go. They just write awesome software in Go such as Docker, Kubernetes, Prometheus, Grafana and VictoriaMetrics [1]. Go authors created simple, clear and productive programming language. Community-driven design for programming language may be disaster - look at incomprehensible C++ Frankenstein.

[1] [https://medium.com/@valyala/open-sourcing- victoriametrics-f3...](https://medium.com/@valyala/open-sourcing- victoriametrics-f31e34485c2b)

</comment><comment><USER84> this is exactly one of the reasons i learned Go in the first place. without the backing of a major corp it's damn hard to have major success. not impossible, or unheard of, just hard.

</comment><comment><USER85> I am about to learn a new programming language and I decided against Go just because of this fact. I do not trust Google and reading this article just makes clear how critical the state of the language is in terms of control by the community.

Python looks most promising and I already worked with it, but I am not sure yet. Can anyone recommend a viable alternative for Go? Any web-focused language that is performant, modern andalready well used?

<comment><USER86> You should use a language based on how well it performs for your problem and domain, and the community around it. Not based on one article or because google is maintaining it.

<comment><USER32> I think his fear of google's stewardship of the language is the fear of what it'll do to the community around it.

<comment><USER87> Its incredibly unlikely that Google would take decisions for the language that would make it less effective at what it does.

<comment><USER32> No, but it's very likely that they'll make decisions that'll alienate the community and thereby cause it's ecosystem to lose more and more relevance. It has done that with other open source projects they stewarded.

<comment><USER88> If they alienate the community, the community can fork it, right?

<comment><USER89> Only if there are major contributing developers who do not work for Google. Is that the case with Go?

If there are no major non-Google contributors to Go, then the fork may not be successful due to lack of familiarity with the code base.

<comment><USER88> It depends on what you mean by "the community". If it's a community of contributors, and Google pulls it into a direction the contributors don't want, then they can fork it and continue contributing to it. If it's a community of users, then they have no choice but to follow whatever the contributors decide. I agree you need to have major contributors on board with a fork.

<comment><USER32> There's more nuance to it though. Users eventually become contributors (at least some percentage are), they become and stay contributors when they feel heard and feel like they have the ability to influence development. That's what nurturing an open source community means. If you start alienating your non-core contributors they'll stop contributing, if you nurture and support your non-core contributors they might become core contributors. No body wants to work voluntarily on a project they can't influence - that's not a contributor, that's an employee.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER90> Does anyone stops the author from forking it and starting an "OpenGo" and implement anything he cannot wait for mainstream releases?

</comment><comment><USER91> I think Microsoft or Apple for example, made their own programming languages in much more ethical way than Google's sceptical which is: "ohh we are going to make our __own __language and get the help from the open source community. " Everyone knows that companies are "exploiting" open source today which is really sad.

<comment><USER92> > Everyone knows that companies are "exploiting" open source today which is > really sad.

Often enough it seems like companies go out of their way to deal with open source just for the "cred" and hiring opportunities that it brings. The open source itself is a just a drag on their internal team, which has to deal with tickets and contributions they don't want or need.

<comment><USER91> They don't need what? Free testing and debugging from thousands of people running their software on completely different hardware and OS? You may see useless tickets but companies are paying millions for QA and testing.

<comment><USER92> My observation has been that the free testing they get is often for cases they never hit in their production use cases.

For example, FB doesn't use DraftJS on mobile, so it took a whole year long effort and a person who used to work for FB to fix mobile support. They just didn't need it, didn't have resources allocated to dealing wit it, and were understandably unresponsive on the subject. Now maybe they can use it in the future on mobile if they want, but they would have just fixed it if that need had ever arisen for them organically.

</comment></comment></comment></comment><comment><USER93> As 2014, i submit same topic, ask google open source golang under an opensource foundation , they did not want do it [https://groups.google.com/forum/#!topic/golang- nuts/OhhG5lu2...](https://groups.google.com/forum/#!topic/golang- nuts/OhhG5lu2Zno)

</comment><comment><USER94> You could say the same thing about Linux. If Linus doesn't like what you made, it's not getting into the kernel.

<comment><USER95> There is a significant difference: Linus is a real person with an actual personality which you can get to know and reasonably choose to trust. "Google", as an entity, not so much. Even we grant Google personhood, they've shown themselves, shall we say, less than dependable in regards to long-term support of their offerings.

</comment></comment><comment><USER96> Good. This is how you don't get C++.

</comment><comment><USER97> Can the same sentiment also be shared for Swift/Apple? Or is Swift organized in a way that doesn't have these issues?

Maybe this is just an inherent problem for all company focused languages/frameworks (react, golang, kotlin, etc), and we need a good example of how to make it work for everyone

</comment><comment><USER98> Yeah, the same story with Typescript and other languages. People learned nothing from Oracle stories.

</comment><comment><USER99> I wonder if the same thing that happened to Android OS, will happen to Golang. Starts off as opensource and free and slowly tie the users down to Google as they did with App Services, etc. "Look but don't touch" kind of opensource?

</comment><comment><USER100> I love Golang to some extend, the moment it's released, it's like new fresh air from Java. But because i don't like Google, i never adopt Golang.

Thanks God, we have Javascript, and maybe Rust.

<comment><USER101> > Thanks God, we have Javascript

Best language to write multi-threaded apps.

</comment></comment><comment><USER102> So proprietary is bad? I have no issues with things being owned by a single entity, especially when they're financially backed by that (massive) entity.

What is being proposed as the alternative here?

<comment><USER103> I even think that for language and base class library design a strong ownership is key to success. They make the language consistent and the library easy to learn.

In both aspects, just compare .NET/C# with PHP.

<comment><USER102> Exactly. I want my language to be crazy good and have an amazing library to tap into. In fact, it was Go's great standard library (JSON parsing, hardened prod' ready HTTPS server, SSH, crypto, etc) that formed a large part of why I love the language.

And yeah, I'd rather go with .NET/C# over PHP any day (although I understand PHP is getting better and better, which is good to hear.)

<comment><USER103> Well PHP and .NET do not play in the same league. But it is about consistent language and library design. Great failure in PHP and great success in .NET/C#.

I developed PHP till 2007, then as a hobby project in 2013. Massive improvement. And I heard very good things about performance the last years. Swoole even can compete with the top tear languages

</comment></comment></comment></comment><comment><USER104> I like Go a lot, but the fact that Google doesn't use it extensively in their own environment makes me wonder why that is. It almost feels like a Trojan horse.

<comment><USER105> Rewritting software is expensive.

I'd be surprised if any new language becomes prevalent in less than multiple decades within Google's unfathomable scale.

</comment></comment><comment><USER106> You want Go to be designed by the Internet equivalent of a cooperative? Isn't that how you get stuff like C++?

For some things Democracy is excellent (governance of nations, because it might be the least bad option). For other things a dictator is good (Amazon seems to be providing a lot of societal value under Chairman Bezos) . For yet other things perhaps a motivated group of technocrats might be better (Go).

I don't suggest I know the answer definitively. I could be wrong. But Go's results are good. Perhaps it would be fair for me to concede that I should examine this question again in 10 more years. What is good for 5-10 years might show problems in 20-50 years time.

After all, even communist North Korea was a relatively functional place for a time.

</comment><comment><USER107> after using golang for a year, I thought it was limited but ok... then I switched to Rust once it was fairly matured - haven't looked back

</comment><comment><USER108> I am kind of OK with that. C# is Microsoft's language, Java is Oracle's, Swift is Apple's, Rust is Mozilla's.

</comment><comment><USER109> even if is baked by google, currently, they have a nice spot on the market, and I dont see any competition :)

</comment><comment><USER110> what matter at the end is the result.

Some hard decision was made for the better of the language and its users at the end. Thank you for the courage taking the hard decision.

If want to argue, argue that other package manager do better job than modules instead of community did effort and it goes for nothing but experimental.

</comment><comment><USER111> Similarly Rust is Mozilla's language. If you want a real open Language, use the open source F# or C#.

<comment><USER112> What makes you say that?

</comment></comment><comment><USER113> This is the same thing with Rust, where original core team are Mozilla's employees.

<comment><USER114> Many (most?) people on Rust's Core/Governance Teams don't work for Mozilla (anymore).

See [https://www.rust-lang.org/governance/teams/core](https://www.rust- lang.org/governance/teams/core)

<comment><USER112> (3 out of 9 people are Mozilla employees)

</comment></comment></comment><comment><USER115> And for most of the SMB it's cool they can ride Google's horse for free.

</comment><comment><USER116> Fcuk the community, according to history and experiences.

</comment><comment><USER117> Rust is another choice ~

</comment><comment><USER117> Rust is your choice :)

</comment><comment><USER118> Free as in, beer.

</comment><comment><USER119> wrong on so many levels.

</comment><comment><USER120> Projects are directed by those willing to put in the work. If you don't put in the work, it's not yours alone!

</comment><comment><USER121> What a surprise (not).

</comment><comment><USER122> Um, Yeah, GOOD! This demand for Generics is pure sheep brain garbage. Once you learn to write software properly you find only like 1 or 2 small use cases where Generics might actually help

<comment><USER122> Down vote me all you want. Been writing production software in Go for nearly 4 years and have never asked or needed Generics. Saying that there isn't a community because Generics are wanted by "some people" is daft.

The whole point of Go is to be small and opinionated and committees can only produce outcomes that are large and inclusive of all opinions.

</comment></comment><comment><USER123> To determine how open a language really is look at how many widely used implementations of the compiler there are for the language. If there is only a single implementation of the compiler/interpreter than it is not really open but controlled by that core compiler team.

<comment><USER124> Most languages I can think of have one very dominant implementation and maybe another one or two that few people use. Python, Ruby, Java, C#, Go, Rust, Haskell... C/C++ are the only exception since Clang became serious competition to GCC and Visual Studio. Even Javascript only really has Chrome and Firefox.

<comment><USER78> That's "consumerization of IT" for you. Millenials and younger are used to looking at pretty websites of "language ecosystems" and blogs about trivial programming problems to assess languages, rather than independence, maturity, and long-term viability as they used to before, and as demonstrated by having language specs and multiple interworking implementations, pluralism of APIs, etc.

<comment><USER124> I don't think the number of implementations correlates strongly with long-term viability. As long as there is at least one FOSS implementation available the language won't die as long as it remains useful.

</comment></comment></comment></comment><comment> dis-sys Seeing Huawei got recently blacklisted for all US made chips, parts and some Android services from Google, an interesting question to ask is whether the US government will one day force some foreign companies (e.g. Huawei, ZTE and DJI for example) to stop using programming languages invented & implemented by US companies.

<comment><USER125> That's not how open source works.

<comment> dis-sys The license can change any time they want. They can change the license to prevent certain companies from using future releases and/or security patches.

Let's don't forget the fact that Huawei had legally binding contracts with all those US suppliers.

<comment><USER126> So? Just fork the last freely-licensed Version then.

<comment> dis-sys then start to use clean room process to reimplement all future bug fixes? nice!

<comment><USER127> Where comes the expectation from, that someone else fixes your problems for free? If you clone Go now, you get a robust codebase for free, and you could do any maintenance on your own (as a reasonably large organization)

</comment></comment></comment></comment></comment></comment><comment><USER128> This is an important point that people need to keep in mind. From a psychological perspective it is also a little bit evil in that it "feels" like a community and people participate like its a community, but the reality is that it isn't a community at all in the communal action sense.

Essentially Google gets "free" developer time as people work on problems and pitch in possible solutions. Google can influence what is worked on by whining about things, and they are free to take or discard the offerings.

This isn't particularly surprising to me as it feels very similar to the way I felt when working there. Which is that people in engineering worked on projects that they were passionate about, but whether or not those projects got support, or were shipped, or released into products. That stuff was all done "elsewhere" by some group of people who were generally known, but not really part of the day to day. I tended to think cynically of them as 'class A' shareholders, or 'class B' shareholders[1].

I don't think there is anything wrong with managing a program this way, I do however think they go out of their way to create a community illusion to foster more participation. That tells me that if they were up front about things, they feel people might not be as eager to participate. To the extent that they are deceptive in their communications, that I would consider wrong.

[1] Class B shareholders get to vote on shareholder issues, but there is always more voting power in the class A shares so that the class A folks can veto or reject any notion they dislike, no matter how popular with the class B folks.</comment>