The Twilio API for WhatsApp - <AUTHOR> https://www.twilio.com/blog/2018/08/twilio-whatsapp-api.html <comment><USER2> Back when I was a WhatsApp user, I for one enjoyed the refreshing total absence of notification spam. If I got a ping, it was because a real person I know had something to say. Just a cold, focused person-person messaging app. Even Facebook could not top that

Opening the floodgates to cron jobs dilutes the value of the service for me, and forces WhatsApp down my list of priorities along with SMS - which I haven't had notifications enabled for in many years, because in almost every case the messages are effectively an abuse of time and attention.

<comment><USER3> Greg from Twilio here.

Totally understand your concern -- no one wants more spam. WhatsApp currently requires that brands using this API collect explicit opt-in from users prior to messaging them, and also that they also use pre-approved message templates to reach out to customers. Free-form messages can only be sent if the user replies back, and then only for 24 hours.

Curious, why'd you stop using WhatsApp?

<comment><USER4> > Curious, why'd you stop using WhatsApp?

I assume Facebook. I'm trying to get everyone I know off of it for that reason. Have you considered Signal or Telegram as additional integrations?

<comment><USER5> I share _wmd's concerns here. The _last_ thing I want is to be "contacted by brands" on Signal. And while I know I can manage _my_ experience with Signal, I don't want Signal to become a place where my friends avoid because it turns into a cesspit of "brand engagement" like so many other services...

(Which sucks a bit for WhisperSystems since I'm not paying them, and I don't want them to take money off Pepsi/TMobile/McDonalds in return for "access to me" either...)

<comment><USER4> Very good point. I haven't actually used WeChat, but so far as I know you have to explicitly opt-in by adding the brand as a contact. There are valid non- spam use-cases (e.g. Amazon order updates) and it would be an unobtrusive monetization strategy.

</comment></comment></comment></comment></comment><comment><USER6> > Users increasingly want to talk to businesses the same way they talk with > their friends and family.

Citation needed, IMO. I hardly speak for most users, but if I had to guess, it's far more that businesses want to speak to users the same way that users talk to their friends and family, rather than the other way around.

Not that this doesn't sound pretty neat, but I'm super curious where the demand from users to connect with businesses via WhatsApp is.

<comment><USER3> Greg from Twilio here.

Living in America and not being a regular WhatsApp user, I had a similar reaction when I first heard about this. It wasn't until I started talking to developers outside America -- especially in Brazil and India, areas where SMS is unreliable and expensive, and where WhatsApp is ubiquitous -- that I realized how powerful this product could actually be.

<comment><USER6> Thanks for explaining that.

</comment></comment></comment><comment><USER7> Interesting business model indeed if this article [https://techcrunch.com/2018/08/01/whatsapp-business- api/](https://techcrunch.com/2018/08/01/whatsapp-business-api/) is to be believed. Though the part of a business only being able to respond to customer initiated messages doesn't seem right - I, even now, get WhatsApp messages from bookmyshow and makemytrip (movie and travel booking portals in India) for bookings done, without me ever sending them a WhatsApp message. They were a part of the early adopter program. And the Twilio API also offers to send unsolicited messages for a fee ($0.0075 it looks like).

<comment><USER8> Pranav from Twilio here. You're right — businesses can contact users first, provided they only use message templates pre-approved by WhatsApp.The article gets that wrong. The messages MMT or BMS have sent you so far should be according to these templates. Also, businesses can not send unsolicited messages though - users have to opt-in to receiving messages from them. You probably did that when you gave them your WhatsApp number after buying a ticket or a flight.

<comment><USER9> How is the opt-in requirement enforced in the API? Some sort of ticket or per- user authorization hash?

</comment></comment></comment><comment><USER10> Is this against Facebook/WhatsApp's policy to use this as a business?

From: [https://developers.facebook.com/docs/whatsapp/overview](https://developers.facebook.com/docs/whatsapp/overview)

"Please note that if you use anything other than the official WhatsApp Business API or other official WhatsApp tools, we reserve the right to limit or remove your access to WhatsApp as this violates our policies. Please do not use any non-WhatsApp authorized third-party tools to communicate on WhatsApp."

<comment><USER11> This changed 24 hours ago.

<comment><USER10> They just added that language 24 hours ago?

</comment></comment></comment><comment><USER12> As a digital nomad that swaps sim cards for cheap data, this is good news. I hope most business adopt a WhatsApp option. IME most developing nations have 10+Mbps LTE for $3 GB and useless wifi. International roaming is crap because you need to be on the right network depending on the town.

<comment><USER13> Why not just get a VOIP OTT app so you have a stable phone number to be reached at?

<comment><USER14> still would need to swap sim cards for different providers as you nomad around.

<comment><USER15> Hopefully this becomes unnecessary in a few years as the eSIM standard moves along, and your SIM is virtual (and multiple operator "SIMs" can be provisioned on a device).

[https://www.gsma.com/esim/](https://www.gsma.com/esim/)

<comment><USER16> I am really looking forward to prepaid providers offering this. Recently when I was in Canada for a few days, and was stuck on a slow international data plan through TMobile, I would have paid $10 or $20 for an eSIM if it was as easy as downloading an app.

</comment></comment></comment></comment></comment><comment><USER17> WhatsApp has a public API? Or is this a partnership?

<comment><USER18> Whatsapp is currently opening API to few partners

[https://blog.whatsapp.com/10000648/Growing-our-Tools-for- Bus...](https://blog.whatsapp.com/10000648/Growing-our-Tools-for-Business)

</comment></comment><comment><USER19> Your pricing is fu*ked. >9c to Germany, >7c to Ireland, > 8c to France, nearly 10c to Netherlands. More expensive than SMS.

</comment><comment><USER20> I can't take my eyes off the rotating 3d code gif and am wondering how something like that was made.

<comment><USER3> Greg from Twilio here.

We are fortunate to have a guy on our Brand team, Aaron, who is very good with video.

</comment></comment><comment><USER21> I'm really hoping that WhatsApp would open their (chatbot) API to devs soon, following Facebook Messenger, Telegram, LINE, Kik, etc.

This Twilio API for WhatsApp is more suitable for s/spammers/marketers, because it will be prohibitively expensive for casual chat.

</comment><comment><USER22> Can I access whatsapp messaging from a twiml bin, or do I have to host a script on a third party somewhere ?

I really, really like using twiml bins because no third party or hosting is required - the code resides on, and runs on, twilio ...

<comment><USER3> You can use TwiML Bins! Also, have you tried Functions? It's like TwiML Bins, but with more JavaScript.

[https://www.twilio.com/console/runtime/functions/](https://www.twilio.com/console/runtime/functions/)

<comment><USER23> (aws lambdas with twilio sdk baked in)

</comment></comment></comment><comment><USER24> I guess AWS will be next. Would be great to have as an SNS destination.

</comment><comment><USER25> Smart. I'm amazed that there isn't one for iMessage as well. Most of the world has replaced SMS with either iMessage or Whatsapp, would be great to have both.

<comment><USER26> I wouldn't be surprised if Twilio gets into this soon as well, since Apple is opening up the iMessage platform.

[https://www.apple.com/ios/business-chat/](https://www.apple.com/ios/business- chat/)

<comment><USER27> Damn that's actually pretty interesting.

</comment></comment></comment><comment><USER28> Can business accounts on WhatsApp be part of groups?

<comment><USER3> Greg from Twilio here.

The API doesn't currently support groups. It's a big feature request though.

</comment></comment><comment><USER29> Why is this priced the same as SMS? How does WhatsApp allow it? Why does it only allow Twilio? Is there an API I can connect to directly?

<comment><USER30> [https://blog.whatsapp.com/10000648/Growing-our-Tools-for- Bus...](https://blog.whatsapp.com/10000648/Growing-our-Tools-for-Business)

</comment></comment><comment><USER31> Does Twilio handle the end-to-end encryption on behalf of its users? If so, they can still be intercepted or modified at the API level.

<comment><USER3> Greg from Twilio here.

This is a great question, and we can do a better job describing what's happening here.

Messages are encrypted between your users and Twilio using WhatsApp's end-to- end encryption. Your requests to Twilio are secure with our HTTPS REST API. You can also redact your messages on Twilio for even greater privacy.

Appreciate you highlighting this. We're working on getting the copy updated on our website to be more clear.

</comment></comment><comment><USER32> Is this for businesses only, or can individuals with a Twilio account also make use of this API?

<comment><USER3> Greg from Twilio here.

Right now it's for businesses only. Any developer can use Twilio's sandbox, but to ship to production you'll need a verified WhatsApp Business account.

</comment></comment><comment><USER33> How much will it cost? It needs to be much cheaper than SMS. SMS adds up fast.

<comment><USER34> [https://www.twilio.com/whatsapp/pricing/us](https://www.twilio.com/whatsapp/pricing/us)

Looks like it'll also add up fast.

<comment><USER35> $0.0135 per message. That's almost like SMS, to be honest.

<comment><USER36> But extremely cheap compared to the markets they're targeting. SMS is expensive in countries outside of the US, and that's why WhatsApp is so widely used.

<comment><USER10> Is it cheaper than the same functionality in WhatsApp's business API?

[https://developers.facebook.com/docs/whatsapp/api/messages](https://developers.facebook.com/docs/whatsapp/api/messages)

<comment><USER36> Unknown, it's not currently public pricing afaict. Probably behind an NDA or variable,

</comment></comment></comment></comment></comment></comment><comment><USER37> Any word on pricing?

</comment><comment><USER38> Whatsapp is so ugly and stupid messenger:

1\. Desktop client is a proxy for mobile app. If phone goes offline, desktop client is disconnect.

2\. You can't add contact from desktop client. So if you use whatsapp for business, you need a phone right right next to desktop PC and every time switching between phone and desktop.

3\. Only local contact list and only one device. If we have few managers that uses WhatsApp for sales or tech support, we can't share one account for few PC's.

4\. Impossible to logout from mobile app. To logout on iOS you need to delete WhatsApp and then install it again.

5\. No chat logs on the server. You need to backup your chat's INTO THE FILE and then move it to another device.

6\. Only one device! You can't simultaneously use whatsapp on phone and tablet.

I can continue this list very long. So I do not understand why this crap is so popular?

<comment><USER39> Popularity, if all your family and friends have it, it's hard to move all that to a new platform.

</comment></comment><comment><USER40> [Removed]

<comment><USER41> Hey there - I lead Twilio's documentation team. There's nothing worse than frustrating docs, I'm sorry ours are coming up short for you.

I'd love to talk more about it and hear how we can serve you better. And it looks like you work with Django a lot? So do I - maybe I can help if you've got a specific project in mind.

My email is email@example.com - would love to talk more about all of this.</comment></comment>


Trained dogs help conservationists find rare Iowa turtles - <AUTHOR> https://www.iowapublicradio.org/post/specially-trained-dogs-help-conservationists-find-rare-iowa-turtles <comment><USER2> I saw a big study of Mississippian culture shell middens and was surprised to see that the most common shell was turtle. There must have been a lot more turtles back then in the midwest...

<comment><USER3> yep - it is hard to miss something you have never seen. North America was teeming with life.. how would anyone know it now, living in car trips to stores and watching TV only ?

<comment><USER2> It's still teeming with life for those who bother to go out in search of it. Yellowstone is overcrowded but it astonishes me how few visitors come to, say, Bridger-Teton National Forest (other than for that Great American Eclipse, during which the traffic began to evoke Times Square) and Couer d'Alene National Forest.

</comment></comment></comment><comment><USER4> I live in rural Arkansas, where we have lots of turtles and terrapins.

I learned this year that if you see a turtle on the road and want to move it (so it doesn't get run over) you should carry it to the edge of the road and place the turtle in the same direction it was travelling. If you orient it differently, or place it on the 'starting' side of the road, the persistent turtle will re-orient and again go on the road to advance in the original direction.</comment>


The letter to the Patent Office you have to read - <AUTHOR> http://www.cbsnews.com/8301-500395_162-57581797/the-letter-to-the-patent-office-you-have-to-read/

<comment><USER2> What a useless letter! Did I miss a real argument in there or was it all ad hominem attacks?</comment>


Ask HN: How is Quilt different from ClusterHQ? - <AUTHOR> I just noticed a Quilt job posting on the front page [0] and am wondering what is different about Quilt compared to the late ClusterHQ.
If you recall, ClusterHQ created FlockerHub, and wanted to be "Git for Data".  Then in December of 2016, right before the holidays, ClusterHQ abruptly shutdown [1] [2].
Coincidentally, I had interviewed there a month before.  After going through the process and meeting the team I was left feeling the mission and product were too much a solution in search of a problem, so I passed.  Then while I was living it up in Hawaii I was shell shocked to learn they'd abruptly closed up shop, with a public blog post titled "Cluster F*cked" [1].
Now I keep seeing these Quilt job postings on HN and am left wondering, is it more or less the same thing?  A solution in search of a problem?  What is different about Quilt vs. ClusterHQ?
Quilt's homepage seems to be selling the exact same pipe dream story and hawking similar wares...
[0] https://quilt-data.breezy.hr/p/15c4a8807cf6-technical-lead
[1] http://archive.is/vjiLw
[2] https://news.ycombinator.com/item?id=13239032 <comment><USER2> I used to work at ClusterHQ, left in April 2016. Some background-

Last day at my job the co-founders were ousted by the board and CEO (the CEO who eventually wrote that post about Clusterfucked), and all the employees in the UK were laid off. Much of the US engineering team left over next few months, and new members hired, so by the time you interviewed it was almost a completely new team.

One of the those co-founders, Luke Marsden, and some other people from original ClusterHQ have started [https://dotmesh.com/](https://dotmesh.com/), which perhaps expresses the original vision better.

I can't say whether the product idea is a good one, though I've definitely talked to people who would find it useful.

As far as Quilt goes:

* The ClusterHQ vision was based on _filesystem_ snapshots (probably Dotmesh too). Thus use case might be "take cheap snapshot of database whenever a 500 error occurs, for later debugging".

* The Quilt vision is data science-oriented, it understands the underlying data, and e.g. exposes it to data science tools like Jupyter.

So they're going after very different markets.

</comment><comment><AUTHOR> Easily clickable links:

[0] [https://quilt-data.breezy.hr/p/15c4a8807cf6-technical- lead](https://quilt-data.breezy.hr/p/15c4a8807cf6-technical-lead)

[1] [http://archive.is/vjiLw](http://archive.is/vjiLw)

[2] [https://news.ycombinator.com/item?id=13239032](https://news.ycombinator.com/item?id=13239032)</comment>


Queen of shitty robots (A Blue Monday antidote) - <AUTHOR> https://www.youtube.com/watch?v=OOGeSmzWktA <comment><USER2> Marriage material, right there! We love you, Queen if the Shitty Robots!

</comment><comment><USER3> Hilarious !</comment>


Writing a Raytracer in Rust – Part 1 - <AUTHOR> https://bheisler.github.io/post/writing-raytracer-in-rust-part-1/ <comment><USER2> I too have been writing a raytracer in Rust[0] recently. I tend to use raytracers as my go to project when learning a new language, especially those that are OOP, since it touches a few different areas that are commo such as:

\+ Protocols/traits/interfaces and using that for polymorphishm, think intersectable/primitve types.

\+ It typicall involves both understanding heap and stack allocated memory in the language as well as understanding the general memory model to build scene graphs etc

\+ Building a small linear algebra library usually touches things like low level operations and performance operations as well as operator overloading if the language supports it.

\+ Writing images to disks via pixel buffers

Primarily though I think raytracers are very fun projects because you can produce nice looking results quickly which I find helps with motivation and passion for the project. I'm pretty pleased with some of my renders already[1]

0: [https://github.com/k0nserv/rusttracer](https://github.com/k0nserv/rusttracer)

1: [https://raw.githubusercontent.com/k0nserv/rusttracer/master/...](https://raw.githubusercontent.com/k0nserv/rusttracer/master/docs/bit- later-render.png)

<comment><USER3> I also agree. Learning a new language by building a raytracer is a lot of fun.

What also helps a lot is that you can use only spheres to create a Cornell box (use very large spheres for the walls). And ray-sphere intersection is 'easy'.

Then the next step is path tracing. This will help you to learn a lot about handling recursion (with or without recursion).

Other areas that you learn:

\+ How scope is handled

\+ (In dynamic languages) how the conversion between floats and ints work.

\+ Multi threading

<comment><USER2> Totally forgot about recursion. The recursive steps for reflection and refraction aren't strictly speaking path tracing are they? I honestly don't know that distinction well. Multi threading was definitely a lot easier in Rust than when I gave it a shot in my Swift version.

<comment><USER3> I think path tracing is just a form of ray tracing. The only difference is that you continue another path at a point where the ray hits an object and collect all the light energy back to the pixel.

<comment><USER2> From a quick Google.

Path tracing doesn't trace towards light sources for shadow rays and instead just sends several rays in different directions and accumelates the resulting colors of those rays.

<comment><USER4> Path tracing is just like ray tracing with randomized deviations of the rays and reflections, and this is repeated many times to reduce the noise. This can also be done with shadow rays to some extent, for soft shadows.

(But it seems like every person you ask knows a different meaning for terms like raycasting, path tracing and physical based rendering)

</comment></comment></comment></comment></comment></comment><comment><USER5> Peter Shirley's "Raytracing in One Weekend" e-books are a nice resource for people who want to do this themselves from scratch.

<comment><USER6> It's kind of surreal to see this post and this comment here, because that is literally what I did last weekend - adapted that book to Rust!

[https://github.com/xmonkee/rusttracer](https://github.com/xmonkee/rusttracer)

<comment><USER7> It looks like Ray tracers are new Fibonacci calculators / Tower of Hanoi solvers :)

</comment></comment></comment><comment><USER8> > raytracing an image takes much longer than the polygon-based rendering done > by most game engines.

Minor nitpick, but it has nothing to do with the fact that it renders polygons. Ray tracing can also render polygons. More precisely, game engines use rasterization which works by projecting triangles onto the screen rather than tracing rays through the screen.

<comment><USER9> It also depends very much the geometric complexity of your scene. With hundreds of millions of polygons it's not difficult for raytracing to outperform rasterization, especially if most of those polygons are instanced.

<comment><USER10> Indeed, with hundreds of millions of polygons, a rasterisation method will generally have to splat them all onto the screen one by one (minus some clever occlusion pre-processing). By contrast, a ray-tracer has the ability to shove all the objects into a R-tree or kd-tree, and efficiently search for only those objects that intersect the ray, and produce the objects in guaranteed order of distance from the camera.

<comment><USER11> I'm a bit sceptic of this claim. You can also produce acceleration structures for reasterized polygons, create hierachical level of detail representations of your scene and render whatever LOD is necessary. This reduces the number of polygons that have to be rendered considerably. It always seems like the claim that raytracing is faster for tens of millions of polygons due to acceleration structures misses the point that accelerations structures can also be applied to rasterization.

<comment><USER12> Ray tracing and rasterization are pretty much duals of each other. Enough effort put into one can achieve very similar results to the other.

Meanwhile, I don't know how much effort would be required to effectively rasterize a beach with individually modeled grains of sand. [https://www.fxguide.com/featured/the-tech-of-pixar- part-1-pi...](https://www.fxguide.com/featured/the-tech-of-pixar-part-1-piper- daring-to-be-different/)

</comment></comment></comment></comment></comment><comment><USER13> I didn't follow this bit (from Part 2):

"This requires a bit more geometry. Recall from last time that we detect an intersection by constructing a right triangle between the camera origin and the center of the sphere. We can calculate the distance between the center of the sphere and the camera, and the distance between the camera and the right angle of our triangle. From there, we can use Pythagoras' Theorem to calculate the length of the opposite side of the triangle. If the length is greater than the radius of the sphere, there is no intersection."

The two sides he describes have the camera in common - so the "opposite" side of that triangle is the line from the center of the sphere to the right angle - I don't see how this helps....

Edit: ok I finally get it but I think he should just label some of these lengths on the diagram with letters (a,b,c etc) and then just show how they are related by stating Pythagoras theorem explicitly...

</comment><comment><USER14> Is anyone able to shed any light on the FOV correction? I'm not sure I understand exactly what is happening there.

<comment><USER8> Scratchapixel has a lesson on it [1] which takes the same approach.

[1]: [https://www.scratchapixel.com/lessons/3d-basic- rendering/ray...](https://www.scratchapixel.com/lessons/3d-basic- rendering/ray-tracing-generating-camera-rays/generating-camera-rays)

<comment><USER14> Of course, because we have the plane fixed at 1 unit in front of the camera, instead of moving that distance we have an adjusting factor that we multiple the co-ordinates by to change our field of view.

Thanks, I looked at scratchapixel but only found the stuff about how pinhole cameras work.

</comment></comment></comment><comment><USER15> > Despite that, it also happens to be the simplest way to render 3D images.

I'm not sure I would claim that -- with a line drawing routine in hand (a for loop), you can have 3D perspective renderings of objects with a few matrix vector multiplies.

<comment><USER16> Line drawing algorithms can be surprisingly tricky. I don't think what you describe would be easier than a basic raytracer, which would be about a page of code, and the most complex math involved is the quadratic formula.

<comment><USER17> Surprisingly tricky being something around two or three dozen lines of C for filling a triangle (with some constraints), after it's been transformed appropriately.

But that is not the only way. You can iterate over a plane and test whether the coordinates are within a triangle. It ends up being very similar to the code you'd have for ray tracing a triangle.

</comment></comment></comment><comment><USER18> Pixar's RenderMan is not a ray tracer, btw.

<comment><USER19> This is correct, RenderMan is a path tracer which is more physically correct in a lot of aspects (light bounces, caustics, conservation of energy, etc). Before that it relied on the Reyes architecture with ray tracing extensions according to Wikipedia but Pixar stopped supporting it in 2016.

<comment><USER20> To be really pedantic about it, RenderMan is an API. Photorealistic RenderMan (aka PRMan) was the Reyes implementation of said API, and the new path tracer is called RIS.

</comment></comment></comment><comment><USER21> It's be really cool if someone wanted to port this raytracer[0] to Rust and compare benchmarks.

[0] [http://www.ffconsultancy.com/languages/ray_tracer/benchmark....](http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html)</comment>


'It's gone haywire': When Covid-19 arrived in rural America - <AUTHOR> https://www.detroitnews.com/story/news/nation/2020/05/06/vulnerable-rural-america-coronavirus-pandemic/111668024/ <comment><USER2> Trying to convince medical students to practice in rural/underserved communities by trying to appeal to altruism is clearly not working when many of them may be half a million dollars in debt. It's such a big problem but it seems like there are no easy solutions in sight. Even debt relief programs are clearly not enough. Or perhaps there just aren't enough doctors to begin with.

<comment><USER3> Why should we convince them on altruism and not by paying them more? I thought USA was all about the market deciding where resources should go?

<comment><USER4> Because rural life is fundamentally economically inefficient, so they can't pay more. Transportation and overhead is too expensive. It only works if its subsidized by altruism of the urban economy, or a huge portion of locals learn the skills for themselves.

<comment><USER5> The way I see it is, a rural economy has to be propped up by at least one "export" of some kind. This usually isn't informational; the information economy gravitates toward urban centers. Whether or not the information economy has to stay in urban centers is unclear, but it seems to be the case right now.

Traditionally that export has been mining, manufacturing, and/or farming. Things that require lots of cheap space and labor and not much else. The first two have taken deep dives in the past few decades. This makes rural life, in many places, simply uneconomical. Without something bringing money into the town, people don't have money to spend on local services. Healthcare is an expensive local service. If we leave it up to the market, the answer is often simply "don't live in a rural area". I'm not saying we _should_ just leave it up to the market, though many would, but I think these are the base facts.

Edit: I hadn't actually read the article yet and I hope the above doesn't come off as insensitive in relation to the OP's tone. But I still think it's the truth. Rural America right now is the most broken part of our country's broken system. Something fundamental has to change.

<comment><USER6> The crux of the rural decay problem is that we've left it up to the _global_ free market, and China/India/other developing countries have sucked up all the manufacturing jobs (national labor cannot realistically compete with Chinese labor).

<comment><USER5> Sure, but that's still the free market. Free-market purists (many of whom _live_ in rural areas) have to realize that this is what comes from taking a hardline stance against government action when it comes to the economy. Stuff just shifts to maximize efficiency, with no regard to the lives that break in the process. This is the unregulated force that they so blindly worship.

<comment><USER7> Many conservative people in rural areas are not pure free market people. Hence the wide support for Trump. He's a populist and nationalist. Ask anyone in rural America and I guarantee you will be hard-pressed to find anyone that thinks the US should do nothing to stop jobs and production from moving overseas because they believe in the free market.

<comment><USER5> I'm more pointing out that when they talk about that sort of thing, they're often being hypocritical after using "small government" and "free market" arguments five minutes before to denounce everything from social services, to capital gains taxes, to environmental regulation. There's a deep-cutting double-standard. I'd have more respect for it if they just admitted to self- interest, instead of preaching against deregulation except when it negatively impacts them.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> We are just getting started in dealing with covid-19 health and economic issues.

There are no quick fixes and we need to hope that almost everyone does the right thing (wearing masks, social distancing, keep shopping at local businesses) because we can't really get the economy going until almost everyone gets on board.

<comment><USER9> Whoa, you have local businesses?

Our leaders have deemed that even curbside pickup is far too dangerous, so Amazon is the only shop in town.

<comment><USER10> Here in the Midwest, everything except 1) franchise stores and 2) single- proprietor stores have gone to curbside pickup. They invented a whole pickup process at our grocery store, with shipping containers in the parking lot containing staged carts with numbers, masked-and-gloved young people filling and shuttling carts to the container. They text you when your cart is ready. Drive over and park in a numbered space and reply with your space number. Somebody comes out of the container with your cart and you pop your trunk.

Cars coming and going all day. Works well for everybody (with a car).

</comment></comment></comment><comment><USER11> Just today morning, I saw an article in NYT about how US should not be happy that it's COVID numbers are tapering.

They show the total numbers split between NY city and whole of US, and it clearly shows that apart from NY, Boston and a couple of other cities, there is a rapid growth in cases across the country.

</comment><comment><USER12> That's a devastating story.</comment>


Internet Now Major Source of Campaign News - <AUTHOR> http://pewresearch.org/pubs/1017/internet-now-major-source-of-campaign-news <comment><USER2> This is a no-brainer. We've seen our traffic shoot up recently, some of it no doubt because of election related news. But we've taken steps to diversify our news offering to prevent a post-election drop off. I think some of the bigger sites (HuffPo and definately Politico) will see substantial hits to their traffic.

<comment><AUTHOR> I agree. It's just these election thingies are very good markers for where we're at because of how they dominate coverage. Still amazing that the internet got mentioned as a first or second choice by only one in three people. That's a tripling on 2004 but there's still a long way to go. Even among 18-29 year olds only 50% cite the internet as a primary source.

Also these numbers show how much newspapers really are dying among the young. Only 17% of the 18-29 demographic cited them first or second.</comment></comment>


Evan Davis meets Warren Buffett - 1 of 6 - <AUTHOR> http://www.youtube.com/watch?v=MuR7XcDJw0I

<comment><USER2> "From an actuarial standpoint, I only have 4000 days left..."

What mindset to get your priorities together. I only have about 20,500 days left. Gosh.It's longer than Buffet, but it still makes me want to get cracking, and spend (just a little) less time on HN :)</comment>


How I built the Chrome T-Rex Game in real life - <AUTHOR> https://medium.com/@urish/i-saw-a-dinosaur-or-how-i-built-a-real-life-version-of-chrome-t-rex-game-92175f6cad2c <comment><USER2> The fun part is the conference he started this in (Geekcon) didn't have internet this year. Very appropriate :)

</comment><comment><USER3> Really cool demo! The author is the same guy from the Simon robot and the low energy Bluetooth stuff.

<comment><USER4> The phrase "Simon robot" reminds me of the following _Simon-playing_ robot, way too cool not to mention in this context: [http://redfrontdoor.org/blog/?p=702](http://redfrontdoor.org/blog/?p=702)

</comment></comment><comment><USER5> This is so COOL!!!!

</comment><comment><USER6> somewhere in the article must be the link which I can't find, or which is ad blocked.

<comment><USER7> Here's a video of the project: [https://www.youtube.com/watch?v=aOIL5mnZ_t0](https://www.youtube.com/watch?v=aOIL5mnZ_t0)

<comment><AUTHOR> also, the final version: [https://www.youtube.com/watch?v=OjaPpAnbbkI](https://www.youtube.com/watch?v=OjaPpAnbbkI)</comment></comment></comment>


Python code gained 17x performance improvement over an older C implementation - <AUTHOR> https://blogs.oracle.com/solaris/reimplementing-a-solaris-in-python-gained-17x-performance-improvement-from-c <comment><USER2> [https://news.ycombinator.com/item?id=21304861](https://news.ycombinator.com/item?id=21304861)

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

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

All in the past two days.

And it isn't "Python can be faster than C", but "hash maps can be faster than linked lists" or "doing less can be faster" or "software designed decades ago doesn't handle tens of thousands of users well"</comment>


China's economy heads for a hard landing - <AUTHOR> http://www.firstpost.com/world/china-economy-hardlanding-6115.html

<comment><USER2> What would the development of a mid-level robotic AI do to China's economy? That is, something capable of accepting speech commands and doing manual labor and costing about $5,000 per unit?</comment>


Ideas at Google do not burst forth from the Heads of Geniuses - <AUTHOR> http://friendfeed.com/e/633a838a-de4c-11dc-b679-003048343a40

<comment><USER2> I agree, but these ideas come to fruit, mainly b/c there are a lot of smart people working at google and keep the mediocre factor low.

In any big company, as soon you get few idiots as managers, they will start hiring even bigger idiots, lowering productivity, increasing political b.s and chronyism -which tends to kill inovation from below. Most decissions are done in upper management level, from people with fancy titles as VPs of something, who often are disascotiated from reality and the user base, or favorise poor ideas and products b/c it suits better their career. In these companies, where Top down level approach of management exists, the engnieers take a back seat.

At google, despite its large size, it still manages to have a bottom up aproach to new products and ideas.

<comment><USER3> The Peter principle ( <http://en.wikipedia.org/wiki/Peter_Principle> ) can lead to a bozo explosion ( <http://blog.guykawasaki.com/2006/02/how_to_prevent_.html> ).

I believe that there are two factors which influence likelihood of a bozo explosion. The first is the organisation's rate of expansion. The second is the quality of human resources.

Regarding the rate of expansion, it is widely known that a company which repeatly grows at 100% per year is consumed by bozos. However, an organisation which does not expand may also be consumed by bozos. This is because the superstars don't wish to remain in a company which is mere "treading water" and therefore the quality of staff declines. It is very likely that the optimal rate of expansion is small and steady on the basis that it is better to not hire at all rather than hire badly.

Regarding human resources, if you've got a company with 100 staff then it is logical to delegate hiring. At this point, hiring takes a life of its own. After human resources personnel are added or replaced, you'll have people who've been hired by people who've been hired by people that you hired personally. If you're not careful then new hires could be of _any_ quality.

Google has been relatively close to 100% expansion in some years. So, I'd argue that Google's human resources is closely monitored. Indeed, you could take an educated guess and say that the success of hiring could be monitored with an algorithm. Maybe this is a ranking algorithm? It is also extremely probable that job applications are filtered automatically.

</comment></comment><comment><USER4> Google seems to have a Darwinian approach to innovation. Perhaps it works. These success stories are the ones that thrived and made it to the next generation. It's nice to hear for every Google News there is unmentionable projects. I wonder if Google has a technical caste system similar to MSFT.</comment>


Two Weeks of Rust - <AUTHOR> http://www.matusiak.eu/numerodix/blog/2016/1/10/two-weeks-rust/ <comment><USER3> "No segfaults, no uninitialized memory, no coercion bugs, no data races, no null pointers, no header files, no makefiles, no autoconf, no cmake, no gdb. What if all the problems of c/c++ were fixed with one swing of a magic wand? The future is here, people"

It certainly is.

The advantages over C++ seemingly never end. I'd add to the list: rigorous portability, non-broken macros, ADTs and pattern matching, a careful language stability protocol, standard test and doc tooling, flexible namespacing via visibility and modules, the _absense_ of vast lacunas of undefined behaviour, simple numeric promotion rules, meaningful compile-time errors for generic code. Plus things already mentioned in the post like Cargo.

People tend to focus on the safety side of Rust, but as impressive to me is just the... solidity on all these other axes. If you stripped out lifetimes and the borrow checker you would still have an incredibly compelling alternative to C++.

<comment><USER4> Languages come and go but C++ remains. I wonder if this one will be different.

Im not trying to be a jerk. Just voicing my concerns. Learning a new language and producing code in it is a huge commitment. It better be around in 10 years. Will it still be as clean and simple, or will it have grown complex. What if Mozilla stops sponsoring it?

C++ is 35 years old. It has stood the test of time. I would not be surprised if it was still popular in 35 years time, when I retire. There is so much C++ infrastructure code in this world, that its not going anywhere.

In the meantime C++ has evolved. I cant remember the last time I had an uninitialized memory, null pointers, or buffer overflow -bug. Those are low level C problems. If you avoid C-style programming and stick with modern C++ (RAII, value semantics, STL, boost, etc) you wont get them.

C++ is changing fast. In the next few years we are getting high level concurrency and parallel language support and libraries (no more low level thread problems), we are getting modules (no more preprocessor hacks), compile time reflection (no more manual serialisation), concepts (no more ugly error messages), ranges (no more cumbersome iterators), and a whole lot more.

And finally there is "C++ Core Guidelines" which aims to be checkable by tools. So you get a warning when you are relying on undefined behaviour.

I think C++ is still the future.

<comment><USER5> It's funny to see how these languages topics always explode. I read it when it had about 20 comments and then it predictably devolved into a mess of hype and comparisons.

Anyway, I think your strategy is sound. Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years. I got bit by this with Swift v1 in a little app. When 1.x came, it failed to correctly transform the source and the whole thing was a major PITA to update. Completely soured me from using Swift.

I can understand why Mozilla wants to use Rust. It solves a problem for them, they largely control how the project evolves and can plan for it. To me, the big questions are what will happen to Rust if Mozilla changes strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will continue to be a successful organisation. Personally, I root for them, in spite of their recent missteps.

I think Rust might be a good choice now for language aficionados and early adopters which can afford to waste time in exchange for other potential benefits. I would absolutely not use it to bring a project to market or for an OSS project which has a long term vision. In 5+ years I expect such a decision could be worth revisiting.

<comment><USER6> > Rust is a young language and I would be pleasantly surprised to see code > written today still compile in five years.

We have had a code stability promise for months now in 1.0. So what you are saying here is that you do not believe that Rust will adhere to what it very publicly planned to do. Do you have specific reasons for this?

> To me, the big questions are what will happen to Rust if Mozilla changes > strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will > continue to be a successful organisation.

Rust has a core team and community that overlaps a lot with, but is very much not identical to, Mozilla. Probably most Rust users aren't even Firefox users.

Rust is not "Mozilla's language". It's the Rust community's language.

<comment><USER7> > We have had a code stability promise for months now in 1.0. So what you are > saying here is that you do not believe that Rust will adhere to what it very > publicly planned to do. Do you have specific reasons for this?

Since 1.0, Rust has in fact had multiple significant stable-breaking compiler changes, not to mention that, among other things, adding any new method to a trait or type in the standard library has the potential to cause breakage. The official code stability promise has not been violated by these changes only because it's riddled with exceptions.

<comment><USER6> > Since 1.0, Rust has in fact had multiple significant stable-breaking > compiler changes, not to mention that, among other things, adding any new > method to a trait or type in the standard library has the potential to cause > breakage. The official code stability promise has not been violated by these > changes only because it's riddled with exceptions.

This is essentially the same as any other language. Adding a new method to traits or types can _also_ break JavaScript, the other example you gave.

In fact, I know of one such example where code _was_ broken in the wild because of new methods being added, and we did not revert the change. Marijn Haverbeke's winning js1k entry relied on the 4th and 7th letters (or something along those lines) of every CanvasRenderingContext2D method being unique, because it compressed code by renaming the canvas methods with what was then a perfect hash function. A new Firefox version was released months later that added new methods and broke the code. That was deemed an acceptable piece of breakage, and Rust's policies are very similar.

Anyway, the vast majority of breakage that we've seen so far was due to the libcpocalypse. This was an issue with people not specifying specific versions of libraries they depended on, not the language.

<comment><USER7> Here's another example with less trivial breakage, which was reverted:

[https://www.fxsitecompat.com/en-US/docs/2015/string- prototyp...](https://www.fxsitecompat.com/en-US/docs/2015/string-prototype- contains-has-been-renamed-to-includes/)

Unless you mean to refute the idea that JS doesn't break _anything ever_ \- which it clearly does, _occasionally_ , but proof-of-concept golf code that intentionally takes fragile shortcuts isn't the best example.

...But JS has moved away from monkey patching builtin objects for good reason, whereas Rust tends to be relatively promiscuous in adding methods to other people's types via trait impls. This isn't bad per se, but I do think it creates bigger compatibility risks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use.

However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves.

As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether.

Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system.

There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem.

[1]:[https://github.com/rust- lang/crates.io/issues/75](https://github.com/rust-lang/crates.io/issues/75)

<comment><USER9> Is there a language package manager that you would consider a good role model in this respect?

<comment><USER8> I'm not aware of any language-specific package manager that gets close to having developer-package authentication, but chromium's add-on system comes pretty close as it requires add-ons be signed by the developer's private key (at least, that was the case before I stopped developing for it). I believe android's packages are secured in a similar fashion.

<comment><USER10> IIRC Common Lisp's asdf-install did use GPG signing from developers; IIRC- again, most people disliked it. Now quicklisp exists, which does _not_ use GPG; a quick google didn't reveal any info on package authentication. Maybe a lisper can chime in?

</comment></comment></comment></comment><comment><USER11> I'm working with Rust 2 months. In my opinion, pluses:

\+ Compiler with very helpful error messages;

\+ Cargo is the best package manager in the universe;

\+ Result<> is the most correct way to return results from function, I dreamed about it;

\+ Community of smart and friendly people.

Minuses:

\- Functions are not first class citizens - you can't return function as result;

\- Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness;

\- Often you need just add lifetime definition to satisfy compiler, without doing anything with this lifetime anywhere else in code;

\- Extremely verbose syntax;

\- Rust has exceptions (panic), and you can't catch them. And with promised panic::recover you'll have limitations of supported structures;

\- Errors handling encourages copy-pasting;

\- Syntax is not intuitive, especially when traits and lifetimes comes into declaration - in such cases you can look at own code and think "I hope at least compiler can read it";

\- Nested structures is pain;

\- Lack of optional and named arguments, lack of predefined values in structures;

\- Too few modules for web. Just 1 module for MySQL (thanks to it's author - actively maintained);

\- Usage of safe code can lead to out-of-bounds errors, with thread panic (hello to vec macros).

And I still think it's best language we have:) Biggest advantage - most of errors can be found on compilation step. But price is all of these minuses.

<comment><USER12> > \- Functions are not first class citizens - you can't return function as > result;

Of course you can: [http://is.gd/YASF8T](http://is.gd/YASF8T)

One issue is that closures don't really have their own types, so to return closures you need to use trait objects, which means dynamically-sized types, which means you have to box them

\- Rust book on the subject: [https://doc.rust- lang.org/book/closures.html#returning-closu...](https://doc.rust- lang.org/book/closures.html#returning-closures)

\- Example of returning a boxed closure: [http://is.gd/pJIqiu](http://is.gd/pJIqiu)

> Violation of "explicit over implicit" rule in methods declarations: argument > self/&self is implicitly omitted in call, but exist in signature.

That's a debatable assertion, in a method call, the self/&self is the subject, the part before the dot.

> Because of this, for example, you can't use method of class as request > handler in Iron, you need closure wrapper with same order and count of > arguments.

By "class" what do you mean? Because AFAIK it works on struct methods [http://is.gd/xu6HRc](http://is.gd/xu6HRc)

> Rust has exceptions (panic), and you can't catch them

That's because Rust doesn't have exceptions, it has panics, they're not a general-purpose error-reporting or control-flow mechanism.

> lack of predefined values in structures

[http://doc.rust-lang.org/std/default/trait.Default.html](http://doc.rust- lang.org/std/default/trait.Default.html)

> Usage of safe code can lead to out-of-bounds errors, with thread panic > (hello to vec macros).

Safe rust doesn't mean no panics. `panic!` is safe rust.

<comment><USER11> println() is not Iron request handler, you gave wrong example. Signature matters.

I don't see how you can declare field if structure to have default value 65535, even with Default trait.

I posted opinion not to argue and really frustrating to see downvotes for opinion. Make discussion more constructive.

<comment><USER12> > println() is not Iron request handler, you gave wrong example. Signature > matters.

println is not relevant here it only shows the result of the call, the point is that you can use a method as a function, I expect the issue is elsewhere (but not having used Iron, I wouldn't know where).

> I don't see how you can declare field if structure to have default value > 65535, even with Default trait.

Implement Default then call it when instantiating struct: [http://is.gd/2YSoKd](http://is.gd/2YSoKd)

> I posted opinion not to argue and really frustrating to see downvotes for > opinion. Make discussion more constructive.

Er… I didn't downvote you? I just replied to some of your objections which I assume is what you expected?

<comment><USER11> > Implement Default then call it

It's far from "default values in struct declaration". I mean this:

struct X { i:u32 = 5, j:u64 }

</comment></comment></comment></comment></comment><comment><USER13> I never found the borrow checker to be that hard to work with. For a start, if you're developing a systems language in a modern way, (say C++11/14) you're already used to thinking in terms of move semantics, const refs and shared vs unique pointers.

Secondly, Rust's compiler gives INCREDIBLY detailed explanations of what the borrow checker doesn't like, where the conflicting scopes begin and end, and helpful suggestions of what to do to make it work.

<comment><USER9> On one hand it indeed feels like more strict version of move semantics in C++, on the other hand it also prohibits what is central idea of STL - <USER2> multiple mutable references to the same object (almost all algorithms operate on at least two iterators from the same container). It seems there is no place for STL-like library in Rust - which is quite regrettable.

<comment><USER14> Most algorithms that I use from the C++ stdlib take `container.begin()` and `container.end()`, and use the latter to check for the end condition in the main loop. Given that Rust has the `Iter` trait which allows you to iterate straight through any type that implements it, I do not see the point in having multiple mutable references. I mean, sure, it is useful sometimes, but it also brings in a lot of headaches with it :)

<comment><USER9> Right, in most cases you could replace begin(), end() with whole container / range, when considering arguments to the algorithm function. Though, there are some exceptions, like std::rotate, or just cases where you want to place result in the same container.

Looking from the perspective of implementation of those algorithms, it is no longer that simple and single iterator is rarely sufficient, consider: std::unique, std::reverse, std::partition, std::sort, std::inplace_merge to name a few, where there is much more to it than just checking for end.

<comment><USER15> Some of those do show up on iter.

[https://doc.rust-lang.org/std/iter/trait.Iterator.html](https://doc.rust- lang.org/std/iter/trait.Iterator.html)

But some of the more specialized ones don't work using just iter. But on the other hand, no iterator invalidation.

<comment><USER9> The crucial difference I had in mind, is that those from C++ work in-place. Returning a new collection as a result poses no problem for either of those languages. Writing specialized version for each collection is also possible, but with STL you don't have to do that.

Maybe it would be possible to implement those algorithms in Rust in terms of ranges like in D, instead of iterators? I will have to try and see.

<comment><USER16> The problem with Ranges is you _can 't_ trust anything they tell you about bounds, and they _can 't_ trust you about bounds, so every access has to be checked. This hurts in algorithms like binary search and sorting (which are some of the few algorithms that don't work for iterators).

Ultimately though, there just hasn't been a lot of demand for ranges. Iterators and slices do most of the work people care about. We actually had tried to make iterators more like ranges back in the day, but we tore it out because no one cared. To this day you can't sort a VecDeque, _and no one has ever bothered us about it_.

<comment><USER9> I did indeed look a little bit about previous attempts at collections in Rust, but didn't find too much about ranges. What would be good keywords and place to look for, any hints?

It seems to me that you can go quite far with mutable but mutually disjoint ranges - which is more or less what slices do for vectors currently. They are also safe, because you can only split them into subslices (which borrow ownership), but not extend them (what could potentially create overlapping ranges). Moreover as long as there is any range to given container, you can't perform operations that could invalidate derived ranges (things that reallocate vector, etc.)

Range checking don't seem that bad, because in most cases it is not about trusting what a range tells you, but range trusting itself which is fine. Take you example of binary search, if range would know how to split itself in the middle, it wouldn't really have to do any bounds checking. For sorted ranges maybe operation like lower_bound or upper bound would be great primitives, or single operation that encompasses both situations:

      let (lower_range, equivalent_range, upper_range) = range.split(&value);

Of course, in general as you point out, you would have to pay a price of bounds checking for random access.

As far as I can see, this should be sufficient to implement algorithmic part. What I still find hard to do, is to modify collections based on resulting range. For example, how to write equivalent to following C++ code, that first moves consecutive duplicates to the end of array, and then erases them from container:

      std::vector<int> v { ... };
      v.erase(unique(v.begin(), v.end()),
              v.end());

I have a few ideas, which mostly boil down to following: create a description of operation to be executed, but is executed only after all ranges have returned their ownership over collection. But so far this interface have not been fully satisfactory.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> The submission and expanded discussion at /r/rust: [https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_r...](https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_rust/)

</comment><comment><USER18> In 2016 I would like to see a Rust frontend for GCC, with LTO support and all the list of target backends GCC support.

<comment><USER8> There used to be gcc front end during Rust pre-1.0, but it seems that the language was too unstable for it to keep up.

A gcc front-end would be great, if only to show that the language spec is mature and complete enough that other implementations can be built on it.

</comment></comment><comment><USER19> I'm a little skeptical after first reading "Disclaimer: I'm digging Rust. I lost my hunger for programming from doing too many sad commercial projects. And now it's back. You rock, Rust!" and then seeing comparisons to Python in the text where it seems like the author might prefer writing in Python, especially with all of the Rust cons listed.

Is the author saying Rust is a breath of fresh air from C++ or from all other programming languages? Ruby was my breath of fresh air for a while, but lately I've not been enthusiastic about any language or framework, really, so I curious how great Rust really is these days.

<comment><USER20> As somebody who comes from the Python community just like the author, I can relate to some of his points:

"In Python I try to avoid even having dependencies if I can, and only use the standard library. I don't want my users to have to deal with virtualenv and pip if they don't have to (especially if they're not pythonistas)"

This rings so true to me. Package management in Rust is much better than in Python.

Also, Rust feels a bit like "pythonic systems programming". I mean that it just feels like the right tool for the job. And it might feel a bit verbose in the beginning, but in reality it's explicit and precise. It feels pretty ergonomic just like Python.

Isn't it fantastic that people start comparing Rust to more high level languages like Python and Ruby instead of C++ or C? It says a lot about the language design and its goals.

<comment><USER21> Am I the only one who doesn't find Python's dependency management a problem?

"pip install -Ur requirements.txt" and you're done. A virtualenv is one extra line.

<comment><USER22> Very easy when you're in control of the machine (and are a developer). A while back I had written a tool in Python purely for myself (mistake #1), and relied heavily on dependencies which needed to compile C extensions (mistake #2), and then it turned out to be very useful for others on my team (mistake #3), which consisted of mostly non-developers (mistake #4) using Windows/Mac (mistake #5). I've since left, and while they supposedly have a dev who can help them install the tool, I'm still running it for them on a regular basis because I don't want to be mean and they haven't sorted it out.

Python's dependency management is great for devs who have a GCC toolchain, but it really sucks when you need to share code with non-developers.

<comment><USER23> It's good to be nice like that but you should still be getting a consultancy fee.

</comment></comment></comment></comment></comment><comment><USER24> I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve on c++ and not improve the syntax or containers? It's like python never existed.

<comment><USER25> _> It's like python never existed._

Whitespace / indentation used for scope delimiting in Python is a bad idea. No, thanks. I'm glad Rust isn't using anything like that.

<comment><USER24> I agree that whitespace scope delimiting is a bad idea, but I was thinking more about general syntactical clarity. Just because C++ uses every possible typographical symbol doesn't mean rust should. Simple example which had me WTFing:

        use std::collections::{HashMap, HashSet};

Are all those ::s and {}s adding to clarity?

Why are there no easy to use initializers for maps? It's 2015! I have to do:

        let mut map = ::std::collections::HashMap::new();
        map.insert("a".to_string(), "b".to_string());
        ...

or some such nonsense. Oh, right, I have to write a macro and basically learn another language. Also, using the macro system for basic things like println just seems bonkers to me; use macros when you really, really need to do something special, not everywhere.

<comment><USER26> Println is a macro because it needs to be: it does compile-time checking of the format string.

<comment><USER25> Do you think it's feasible to implement initializer lists in Rust, or there is some language limitation which makes it hard?

I.e. I'd prefer to write:

        let v: Vec<i32> = {1, 2, 3, 4, 5};

Instead of

        let v = vec![1, 2, 3, 4, 5];

<comment><USER27> Initialistion from initializer lists in C++ basically rely on the = operator being able to do arbitrary work, e.g. allocations and generally manipulating the heap in arbitrary ways. Rust tries to avoid implicit performance sinks like that, and so doesn't have constructors in the same manner as C++.

That said, in future, it is likely to be possible for things like `Vec::from_array([1, 2, 3, 4])` and `HashMap::from_array([[1, 2], [3, 4]])` to work.

<comment><USER25> Rust doesn't need to take the C++ approach to implement it, but it can still use the same syntax which is simply much neater. HashMap::from_array([[1, 2], [3, 4]]) looks horrible in comparison.

Exact implementation is another question. That's why asked, whether it's feasible or it's something hard to fit into the language.

<comment><USER27> I don't see how Rust can get the same syntax as C++ without having the implicit performance sink I mentioned: creating vectors and hashmaps needs to allocate, and so letting this happen implicitly is not great. In fact, the syntax was pretty much the whole meat of my comment.

<comment><USER25> Why can't Rust do what it does already with macros, except using the simpler syntax described above? I.e. that syntax can mean explicit allocation (it's just a short form for it).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> How does Rust interoperate with C++? For example, would it be easy to integrate V8 into a Rust project?

<comment><USER29> With specific C++ features there is still a lot of work to do, however the C FFI is solid and simple to use if that is enough for you (see e.g. [https://doc.rust-lang.org/book/ffi.html](https://doc.rust- lang.org/book/ffi.html)).

Interfacing Rust and python, ruby, node can be quite simple in fact (micro demo for node: [http://calculist.org/blog/2015/12/23/neon-node- rust/](http://calculist.org/blog/2015/12/23/neon-node-rust/))

</comment></comment><comment><USER30> Nice to see rust getting along. Coming from C and C++ is really dig the new ideas for better and more save low level languages.

What really bugs me, is what the author describes as being'concise'. Shortcuts like fn, pub or vec, in my oppinion, hurt readability more than they help me to write code faster. But maybe thats just my brain, or lack of time using rust.

<comment><USER17> As far as I understand, the length of keywords and common identifiers is roughly proportional to the reciprocal of frequency. `fn` and `pub` are used a lot; `return` is less used (Rust returns the last expression by default); `continue` is even less so, and it's familiar to C/C++ programmers.

<comment><USER30> thanks a lot for the info. I can perfectly see the reasoning behind it. Still, i find it harder to read. But as i said, that can be a lack of practice.

</comment></comment></comment><comment><USER31> I've been experimenting with Rust for a few weeks, and I really like it, but I hope they improve how you write functions that return iterators. I can't find all the discussion now, but here is some of it:

[http://stackoverflow.com/questions/27535289/correct-way- to-r...](http://stackoverflow.com/questions/27535289/correct-way-to-return-an- iterator)

[https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...](https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/)

[https://github.com/rust-lang/rfcs/pull/105](https://github.com/rust- lang/rfcs/pull/105)

[https://github.com/rust-lang/rfcs/pull/1305](https://github.com/rust- lang/rfcs/pull/1305)

Reading those RFCs can be frustrating, where a discussion goes on for over a year and people add more and more wants to an idea until it sinks. Same thing with the discussion about a `yield` keyword:

[https://github.com/rust-lang/rust/issues/7746](https://github.com/rust- lang/rust/issues/7746)

[https://github.com/rust-lang/rfcs/issues/388](https://github.com/rust- lang/rfcs/issues/388)

It reminds me of the JCP in Java. I guess every standards committee is like this, and I actually like how careful the Rust team is about extending the language---but I think we should be prepared for it to evolve slowly. Right now I feel like Rust's pace will be more like Java than C#.

<comment><USER26> One reason you're seeing slowness is that the compiler is undergoing an internal refactoring that will _completely change_ the way these kinds of features will be implemented. So they're effectively on-hold-ish until after that's done.

Also, this particular feature seems easy from a usage perspective, but the type theory behind it is actually pretty intense, and there's multiple possible ways of doing it. So those need to be explored, discussed, and figured out.

This feature is one that's of high importance, and is coming sooner rather than later.

<comment><USER31> Thanks for the reassurance! Sorry if I sound critical. There will always be a tradeoff between speed and purity---Java vs C# is a actually a pretty interesting case study---and for a language that is as experimental as Rust, I think taking your time to make careful decisions is the right approach. I'm just trying to prepare myself for the wait. :-)

Also thanks to you personally for your work making Rust accessible to us newbies. The book is very nice, and a few weeks ago you were really quick to answer a question of mine on IRC. Keep up the good work!

<comment><USER26> No bad feels taken!

You're welcome. I hope the next iteration of the book is even better :)

</comment></comment></comment></comment><comment><USER32> The article is comparing Rust principally to Python (a new dynamically typed language) and C++ (an old statically typed language). It's certainly plausible that it can bring benefits over these.

More interesting to me would be comparing it to a new-ish multi-paradigm language, of which there are many right now (e.g Swift, OCaml, Haskell, F#, Scala). It seems like in practical applications these newer FP languages will be much more productive than Rust, as memory management is much simpler. Rust's principle of zero-cost abstractions is great in theory, but can't think of many applications where it's the limiting factor except perhaps embedded devices and kernel development.

<comment><USER33> Rust is designed as a _systems programming_ language, so it was explicitly made for situations where zero-cost abstractions and explicit memory management matter. Embedded devices and kernel development are two places that matters, but there are more: web browsers, web servers, databases and runtime systems all come to mind.

<comment><USER32> I don't think that one can necessarily equate systems programming with manual memory management (see e.g. Go). It's true that manual memory management will (probably) be more efficient and more predictable, but ultimately depends on how important that is in your application.

<comment><USER34> Go is not a systems programming language (as the term is usually understood), and Google labelling it that way when they first introduced it is unfortunate.

<comment><USER32> Citation needed. Plenty of people regard high-level languages as nonetheless suitable 'systems programming'. This is the first FAQ on golang.org! See also

[https://ocaml.github.io/ocamlunix/](https://ocaml.github.io/ocamlunix/)

<comment><USER35> I would define the term "high-level language" to mean that it's possible to write programs in the language without needing to worry about the specific hardware that the program is running on.

I would consider systems programming to be things like writing operating systems, drivers, high-performance native applications (for many difference definitions of high-performance), and databases.

I consider rust to be a high-level language and I further consider it to be suitable for systems programming using my definitions.

However, I don't consider go to be suitable for a lot of systems programming tasks because it has a significant runtime system that includes a garbage collector. Just because they describe themselves as a "systems programming language" doesn't mean that I believe them (at least as far as I understand that term). That said, there are certain applications that work fine with GC, and in those cases it can be a very nice way to achieve memory safety without programmer burden.

</comment></comment></comment></comment></comment></comment><comment><USER36> Future? well, 10 year later, quantum computer maybe come to reality which is much much faster than current computers. At that time who will care about Rust or C++? The easiest language will win.

<comment><USER35> You shouldn't expect quantum computers to bring a "free-lunch" speedup the way that clock-speed increases did for such a long time.

</comment></comment><comment><USER37> When you've worked with languages with a garbage collector, having to worry about memory management and all that jazz seems a step backwards just to save a few cycles. You want to be focusing on the domain problem not the machine. (This is directed at people who use Rust as a general purpose lang, im sure it's good for low level systems programming).

<comment><USER28> It would be nice if the language itself provided hooks (or whatever you would call it) to implement your own GC (or, of course, to use a library for that purpose). I have not yet encountered such a language, though (LLVM has a low- level language that allows it, but I don't know the details).

<comment><USER38> Rust does that. Rc type is implemented in Rust. ([https://doc.rust- lang.org/nightly/std/rc/struct.Rc.html](https://doc.rust- lang.org/nightly/std/rc/struct.Rc.html)) There's also arena allocation available as a library. ([https://crates.io/crates/typed- arena/](https://crates.io/crates/typed-arena/)) You can add your own memory management abstractions as libraries.

<comment><USER28> Very interesting.

I'm also interested in one particular kind of memory abstraction: abstracted access to memory mapped files. Here the problem is that the base address of the memory mapped area might change whenever you perform the mapping. And you would like to use standard data-structures (like maps, lists, etc.) inside the memory mapped area.

<comment><USER38> Mmaped files are already available it seems ([https://crates.io/crates/mmap/](https://crates.io/crates/mmap/)), although I've never tried it. You'd have to implement the interesting structures on top of that yourself however.

<comment><USER39> Relative pointers are great in memory map data structures. All pointers are relative to current offset. That way it's almost always also possible to get away with just 32-bit pointers -- you get +- 8 GB range.

A library that can do that in Rust would be great.

<comment><USER40> A signed 32 bit "offset" value gives you 2GB in each direction, not 4GB in each direction.

<comment><USER39> Only if you use byte aligned relative pointers. For data structures you don't need better than 32-bit aligned pointers. So you get +- 8GB relative offsets. It's not all that unreasonable to use 64-bit or even 128-bit alignment, for +-16 GB and +-32 GB respectively.</comment></comment></comment></comment></comment></comment></comment></comment>


Japan's aging population could actually be good news - <AUTHOR> http://www.newscientist.com/article/dn24822-japans-ageing-population-could-actually-be-good-news.html <comment><USER2> > But fewer people in future will mean it has more living space, more arable > land per head, and a higher quality of life, says Eberstadt. Its demands on > the planet for food and other resources will also lessen.

Different day, same Malthusian bullshit. These people can only think of humans as net negative parasites on the planet, rather than individual agents with a positive expected value to society. Density is GOOD — it leads to cross- pollination of ideas and the advancement of the world. Yes, the planet is on a path that will require us to eventually get smarter about resource consumption. Advocating fewer people on Earth is the most harmful & naive way to solve that problem.

If your life raft is sinking, do you try to patch it, or do you throw someone overboard? Your instinctual answer says a lot about the type of person you are.

[edit: I'd remove the last paragraph if it weren't intellectually dishonest to do so. I feel like it's causing people to miss my main point. It was written more out of anger than reason. Please ignore.]

<comment><USER3> > Different day, same Malthusian bullshit.

We are currently experiencing a human-induced mass extinction event and reduction of biodiversity comparable to the largest natural catastrophes in the planet. The way things are going, by the end of the century most of the large mammalian predators will be definitely extinct, and if carbon emissions are not reduced by the end of the century, by which we should become a carbon- _negative_ society, the oceans will not be able to support most of the base of its food chain.

I question your valuation of human society above the base of the biological systems that support its very existence. A large population living in a humongous wasteland is of dubious utility for its inhabitants.

I reckon you haven't been able to see the true impacts of humans on most of the ecosystems in the planet. Ultimately, I think you're confusing density with population; a large population is not a requirement for a dense population. Furthermore, the percentage of the population that contributes to innovation is a very, very restricted subset of it.

<comment><USER4> I don't get it. The ecosystem is not a constant system. It is summary randomness, guided by evolution. Whatever you are trying to preserve, be assured new randomness will happily take its place.

<comment><USER5> The current randomness supports human life. I'm not so sure that whatever replaces it will too.

</comment></comment></comment></comment><comment><USER6> Here's the problem I see with both population decline and life extension: lots of research indicates that the creative peak happens from 20-40 or so. Geniuses rarely continue to be the same level of productive after that. In other words, progress is probably better served by giving two people the chance to live 50 years than one person the chance to live 100, though resource consumption is about the same. An aging society, one without new generations of people with new ideas, is not a vital and creative one. Progress is served by turnover.

<comment><USER7> > Here's the problem I see with both population decline and life extension: > lots of research indicates that the creative peak happens from 20-40 or so.

I'm not sure that's as clear as you think it is. There's a number of issues and confounds which mean that simply plotting age vs achievement can be very misleading. Check out "Age and Outstanding Achievement: What do We Know After a Century of Research?" [http://www.resources.emartin.net/blog/docs/AgeAchievement.pd...](http://www.resources.emartin.net/blog/docs/AgeAchievement.pdf) , Simonton 1988

<comment><USER8> I get a DNS lookup failure for that domain. It looks like the correct URL is [http://resources.emartin.net/blog/docs/AgeAchievement.pdf](http://resources.emartin.net/blog/docs/AgeAchievement.pdf)

</comment></comment></comment><comment> guard-of-terra In countries where fertility rate is much under 2.0, people tend to have two opinions on demographics:

1) If you don't have enough (read: a lot of) money then don't have children. If you're not ready to spend all your time on children while still making enough money then don't have children. If you're not the model family then don't have children. If we think you're not the best parent possible then don't have children. You better not have your children too late and certainly not too early. And yes, we're going to take your child away the first moment we suspect something from above violated.

2) People are so damn selfish, they don't understand that their prime happiness is their children, they spend their lives on themself and so we're all going to die as a nation and as an economy.

Surprisingly enough we often see both at the same time in one individual. More often than not.

<comment><USER9> People's individual choices don't always line up with their beliefs about what the country as a whole should do.

I am told BART was approved by a whole lot of voters who liked the idea of _everybody else_ using BART, so they could have less traffic on the roads. Nobody was voting for BART so they could use it themselves. (Or so the story goes).

</comment></comment><comment> guard-of-terra I also think of this problem as about an elective one.

Imagine you have half voters over 65.

Why would they care about innovation or ecology or whatever common good? They would only care about getting their cut of social security. This way they can easily throw a society off the cliff if it happens tomorrow. They don't care about tomorrow.

Yeah, and they also like to tell youth how to live their life. Especially in the areas themself can no longer do anything. This can lead to repressive and suffocating societal changes.

<comment><USER10> Are you an idiot? Are you seriously suggesting that just because someone is over 65 they stop giving a shit about the planet, society and/or the greater good?

</comment></comment><comment><USER11> 1\. Overcrowding in Japan is largely due to such a large percentage of the population congregating in Tokyo. If the Japanese economy (and thus population) were more decentralized, this wouldn't be such a big problem.

2\. A lot of the reasons for the high cost of living has to do with protectionism. For example, the rice farmer lobby benefits from very high tariffs on imported rice. Most of the rice farmers are old men, so more young people (or the existing young people being more politically engaged) could actually help fix this problem.

<comment><USER12> With regard to #2, Japan has a food security problem that will be alleviated by a lower population. Cramming more people in and becoming even more vulnerable to a disruption in shipping is an obviously bad idea.

</comment></comment><comment><USER13> It's the "Children of Men" solution to the automation/jobs crisis.

<comment><USER14> And yet: something that bothers me about that book/movie is that its portrayal of the labor/immigration dynamics seems exactly backward.

Without a fresh supply of young workers, but _with_ all the factories/tools/capital/housing that supported a larger population, the benefit of incremental workers becomes gigantic.

The winning regions in such a scenario would be those that welcome massive immigration to maintain production.

Even assuming some xenophobic fear arising from the uniqueness of the zero- fertility situation, nations like the UK or US, that already have the benefit of worldwide adoption of its language (and cultural exports), and functioning beachhead immigrant communities of all types, would in such a scenario be most likely to recognize that immigrants could soften the pains of a population- shortage.

Keeping immigrants out would require even more of the dwindling population wasted on 'guard labor', and even more empty buildings/communities and idle factories. And to the extent that there are culture clashes – there's now plenty of space to congregate in voluntarily-segregated communities, but still within the same national boundaries for easier trade.

So while I loved a lot about the 'Children of Men' story/movie, its economics were all wrong.

</comment></comment><comment><USER15> Interesting:

"Japan has the world's oldest population, with a median age of 46 years, an average lifespan of 84, and a quarter of the population over 65. "

That is a very old population!

</comment><comment><USER16> This comes without surprise. A higher median age for any population is usually indicative of higher quality of life.

There's a good TedTalks video on the subject. There's also a good book called Common Wealth written by Jeff Sachs that covers this.

</comment><comment><USER17> an aging population means GDP will decline!

Ziss is unspeakable! Ziss is an unmitigated disaster for corporate profits!

GDP uber alles!

Ve must force japan to take in immigrants! For ze sake of corporate profits! GDP uber alles!</comment>


Try the konami code on Airbnb - <AUTHOR> http://www.airbnb.com

<comment><USER2> <http://konamicodesites.com/>

</comment><comment><USER3> ↑, ↑, ↓, ↓, ←, →, ←, →, B, A

<comment><USER4> You have to hit "enter" at the end.

<comment><AUTHOR> false</comment></comment></comment>


Isaac Asimov Asks, "How Do People Get New Ideas?" - <AUTHOR> https://www.technologyreview.com/s/531911/isaac-asimov-asks-how-do-people-get-new-ideas <comment><USER2> When I was young I thought that 2Pi was a more naturally occurring value than Pi. I didn't really tell people about it. Much later in life, I discovered the Tau movement. I doubt that I was exposed to this before my thought of it.

This made me wonder how many truly original thoughts do people have? It's hard for me to think of even one other clear example. Most thoughts/ideas are triggered or build upon others which we are exposed to. The only other large category of original thought is humour. Someone has to be first to make the associations.

<comment><USER3> It might also make you wonder how many profound thoughts _don 't_ gain traction. How many times does an event repeat itself before the pattern is accepted as common knowledge worthy of scientific evaluation?

</comment></comment><comment><USER4> I was expecting a theme similar to "Destruction and Creation," [1] but instead Asimov describes the perfect recipe in which learned odd people perspire in private, then congeal and adapt in public. Brilliant article.

[1] - [http://www.goalsys.com/books/documents/DESTRUCTION_AND_CREAT...](http://www.goalsys.com/books/documents/DESTRUCTION_AND_CREATION.pdf)</comment>


So how many readers _actually_ read a blog post? - <AUTHOR> http://swizec.com/blog/so-how-many-readers-_actually_-read-a-post/swizec/2453

<comment><USER2> Whilst I accept from a business perspective that more detailed metrics help choose direction, figure out what works and whatnot, as a user I'm somewhat against the ever-finer grained tracking of activities.

"Hits", "Performing Social actions", ...

Obligatory _Snow Crash_ quote:

" _Y.T.'s mom pulls up the new memo, checks the time, and starts reading it. The estimated reading time is 15.62 minutes. Later, when Marietta does her end-of-day statistical roundup, sitting in her private office at 9:00 P.M., she will see the name of each employee and next to it, the amount of time spent reading this memo, and her reaction, based on the time spent, will go something like this:

Less than 10 min.: Time for an employee conference and possible attitude counseling.

10-14 min.:Keep an eye on this employee; may be developing slipshod attitude.

14-15.61 min.: Employee is an efficient worker, may sometimes miss important details.

Exactly 15.62 min.: Smartass. Needs attitude counseling.

15.63-16 min.: Asswipe. Not to be trusted.

16-18 min.: Employee is a methodical worker, may sometimes get hung up on minor details.

More than 18 min.: Check the security videotape, see just what this employee was up to (e.g., possible unauthorized restroom break).

Y.T.'s mom decides to spend between fourteen and fifteen minutes reading the memo. It's better for younger workers to spend too long, to show that they're careful, not cocky. It's better for older workers to go a little fast, to show good management potential. She's pushing forty. She scans through the memo, hitting the Page Down button at reasonably regular intervals, occasionally paging back up to pretend to reread some earlier section. The computer is going to notice all this. It approves of rereading. It's a small thing, but over a decade or so this stuff really shows up on your work-habits summary._"

</comment><comment><USER3> People don't read. They scan.

<http://www.useit.com/alertbox/reading_pattern.html>

Your scrolling js metric is clever, but that doesn't mean they've read a thing. All it means is they've scrolled to the bottom of the page.

<comment><USER4> I read when a writer shows me that she's got interesting stuff to say and isn't going to repeat what she's said previously. I scan when someone shows me what they're saying isn't important (a tl;dnr summary is a strong sign of something not being important) or can be easily summarized.

When I write, I write for people who realize what I'm writing can't be summarized to tl'dnr. That means I probably collect far fewer "hits," but I would tend to imagine those who do follow my work are more engaged.

</comment></comment><comment><USER5> I've caught myself scanning at articles from people I don't know. I try to understand the gist of it to see if it's worth reading carefully, but when it comes from writers I know and respect I'll take my time and have a pleasant read.

It would be interesting seeing the same statistics for a well established author. I'm guessing the numbers would tell a different story.

<comment><USER6> Agreed. For example, when a Rands article comes up, I always load it up in a tab and wait until I have the time to properly read it, and I almost always read it to the end, because I know that the article will both delight me and instruct me.

</comment></comment><comment><USER7> Some blogger about 1.5 years ago asked readers to include some unusual word, like "mongoose" in their comment, as a test of reading comprehension, and the first 30 or so comments failed to follow that instruction.

<comment><USER8> ars technica did this and the result was sad <http://i.imgur.com/K9jIy.jpg>

<comment><USER9> I don't understand how this is sad. All it showed was that people skipped a word that had "bananas" in it, a word that has pretty much no meaning in the context of the article.

Its similar to how I ignore spelling mistakes in news articles. I may see it for a second, but since that isn't the reason I'm reading it, I'll just move on and probably instantly forget.

</comment></comment></comment><comment><USER10> I'll admit, sometimes I skim posts and go straight to the comments on HN. Sometimes I find the discussion here to be more scintillating than the link itself.

<comment><USER11> I think it's a wholly legitimate thing to do, and it requires no apology. I do it all the time. Pretty much every time I come across a new link here, I rapidly and subconsciously run a few checks on it before clicking it open:

1) Is the title relevant to my interests? 2) How many upvotes has it received? 3) How many comments has it received? 4) (Upon scanning comments) Are the comments interesting?

The only problem with this method is that it can tempt you to reply to comments without actually having read the article in question. That's bad form, of course.

</comment></comment><comment><USER12> Some reference style posts are not intended to be read in full. I've done a few of these on my blog such as comparing the 5 major browsers, how good the iPod touch is for reading many different sorts of reading material, best aa batteries which describes the different battery technologies and includes a buying guide, etc. I organize the material so that people can read the specific sections that are of interest to them, and skip the rest. Google Analytics (a crude measure, I know) tells me that average time spent reading per page on these reference posts range from 4 minutes (the browser post) to 14 minutes (the battery post). So pretty sizable chunks of the posts are being read (by those who continue on to a second page, at least).

Then again - these being reference posts - the vast majority of readers come in through Google search looking for answers or advice, which is obviously much more targeted than a community news site. The times are far lower on days where a bunch of people come in due to a listing at Hacker News or Reddit.

</comment><comment><USER13> As I often do, I skipped the article itself and went straight to the HN comments.

<comment><USER14> HN has articles? I thought it was just a comment board.

</comment></comment><comment> mkr-hn The swarm of useless links (why would you link to twitter.com?) and red underline is not helping. I never did find the link to this blog post you talked about through the whole article. And gray headers don't do much for breaking up the text.

These are confounding variables.

</comment><comment><USER15> Copy format has some play with this too. Interesting that in this particular case the section headings are anti-aliased but the paragraph texts are not. If you're not going to used anti-aliased you should pick a font that is not so rounded and apparent. Reading anti-aliased text is akin to rubbing my eyes with sand paper. Okay, it's not that bad but it has the same psychological effect of making me not want to keep reading.

I will also admit, that even when the copy font displays pleasantly, I will only skim paragraphs to determine the general theme and tone of content to determine my interest and whether or not I will keep skimming, start reading, or leave altogether. But still, bad font choice is very distracting and doesn't help.

</comment><comment><USER16> Piles of (automatic?) random links in the blog post, no link to the test blog post.

I wondered if the layout and wording of the 20th paragraph that the writer was so mystified by so many people stopping at _looked like an ending_.

</comment><comment><USER17> You have about 300 ms of my time where I scan the first paragraph and decide whether or not to continue. Maybe that indicates I have terrible reading skills or maybe it means I have an advanced pattern recognition filter.

<comment><USER18> Is the 300 ms a measurement or WAG?

</comment></comment><comment><USER19> I wonder that too. It seems that sometimes the comments on HN to a blog post don't match up (I wonder if they even read the same post I just read).

If I click on a link and find something I like enough to finish I will vote up and add a comment if I have something to add.

</comment><comment><USER20> What if blog posts had several versions, from TL;DR to full post which would unfold as you scrolled the website.

</comment><comment><USER21> I'm interested to see what your percentage of completed reads of this post is :)

<comment><USER22> I suspect higher than average due to the fact that people are being called on it.

<comment><USER23> I suspect that it's lower than average due to Error establishing a database connection

</comment></comment></comment><comment><USER20> And he is testing us right now, I get it, I get it.</comment>


PIM Systems - <AUTHOR> Hi to everyone! I have been trading for some years through an online store and realized that it's time to find a suitable PIM system (product informatiom management system). Honestly, I have already read a lot about them and found that there are such a free options as open-source systems. For example here: https://treolabs.com/journal/treopim-pimcore-akeneo-open-source-pim-systems-in-comparison But are they really easy to use as it is described? I would be very grateful if someone had the experience with self-adapting of PIM system to their store and can share information about it.<p>Moreover, I am interested whether there is always a need for additional paid modules? When choosing the system from the point of view of pricing policy, I would prefer TreoPIM (https://treopim.com/). Pimcore is also very good, but expensive for my company. Please share what kind of systems do you use? <comment><USER2> I have used Akeneo PIM and it is excellent and really easy once you grasp main concepts - Product Model, Product, Family. For the integration with the store you might need a paid module or just to program it yourself.</comment>