Unbounded High Dynamic Range Photography Using a Modulo Camera - dnt404-1 http://www.media.mit.edu/research/highlights/unbounded-high-dynamic-range-photography-using-modulo-camera <comment><AUTHOR> > No more will photographers or even ordinary people have to fumble with > aperture size and exposure length.

This is a "computer scientists" understanding of photography, and this phrase alone can even be seen as "dangerous" by photographers. There's more to aperture size and exposure length than "how much light reaches the sensor", like focus, depth of field, motion blur and bokeh, to name a few, that is not aknowledged by that understanding. The technology is good, but it won't change the way photographers deal with photography, at best, it will give them a better tool to work with.

I also wonder how much impact this could have. Foveon Inc. had developed a great sensor that was going to be revolutionary, about 20 years ago. Today only Sigma uses it, and the UX is so bad in those cameras that the (very good) technology they had their hands on never got a chance to shine.

Also, is this implementation very different from having a 16-bit ADC in normal sensors? The end results would be the same: higher dynamic range. And the increase in bits seems a lot closer (because it would mean little changes to the current manufacture processes) than a whole new type of sensor being use in cameras.

<comment><USER2> > This is a "computer scientists" understanding of photography, and this > phrase alone can even be seen as "dangerous" by photographers.

The actual headline of the article is actually _more_ informative and less misleading than the subhead:

"Unbounded High Dynamic Range Photography Using a Modulo Camera"

In photographer's terms, they're referring to ending _blown highlights_ (caused by filling the wells in a sensel) not _saturated_ images (caused by exaggerating color data).

There's a school of photography that basically lives and dies by over- saturating images (e.g. [http://kenrockwell.com](http://kenrockwell.com) ) and they'd likely have a cow over the headline, but understand and be totally onboard for the actual goal.

Depending on how quickly the well can reset and how many times resets can be counted this will either be better or worse than simply improving existing approaches. The state of the art in full frame sensors is just under 15-bits of dynamic range. So to _equal_ it an 8-bit sensor would need to be able to count resets at least 128 times AND be able to do this in 1/8000 of a second, at the same sensel density and efficiency! Don't hold your breath.

[http://www.dxomark.com/Cameras/Nikon/D810](http://www.dxomark.com/Cameras/Nikon/D810)

(I'd also suggest that trends towards using multiple sensors to assemble high resolution images will easily blow this away since they can use high- and low- sensitivity sensors to synthesize more dynamic range and resolution. Also see recent Olympus patents to capture polarization data at the same time.)

BTW: assuming they can do this stuff, they presumably can read the sensor pretty darn fast — so they should be able to eliminate image "tearing" in digital video and the need for mechanical shutters altogether. That's probably a bigger issue than dynamic range.

I suspect that clearing a well in < 1/10,000,000 of a second (which would only lose 10% of the photon detection time during a 1/8000s exposure) is going to be tough. Assuming 25% of the sensel real estate needs to be sacrificed to the modulo circuitry, that's a loss of 32.5% of photon data which is about the same loss as for pellicle mirrors (as seen in Sony's pretty unsuccessful SLT cameras) for a feature that won't be much use in many situations.

<comment><USER3> > _BTW: assuming they can do this stuff, they presumably can read the sensor > pretty darn fast_

What's funny is that the iPhone (and a high end Android phone) has way faster processors than your typical $10.000 DSLR.

<comment><USER2> Actually they're not so much faster -- although the camera companies don't have the economies of scale to iterate nearly as fast as the phone companies (so they hang onto a processor generation for a couple of years).

A good smartphone can capture 4K video or 20fps 8MP or whatever off the sensor — both around 160MB/s. A $10k DSLR is handling 16MP at 11fps — that's around 300MB/s (remember that the DSLR is handling 14-bits per sensel).

The interesting thing is that if you look across the camera lineups, there's almost no difference in CPU between a $300 consumer camera and a $10k professional (there is a big difference in RAM - the DSLR is able to store 50+ uncompressed images in RAM (let's say 3-4GB), while the phone or low end camera processes them into JPEG before storage.

</comment></comment></comment></comment><comment><USER4> The title here is terrible because over-saturation is an effect of poor tone mapping, which is inevitable if you want to display an HDR image in a low dynamic range display. An accurate title would be the end of over- _exposed_ images, but why not just keep the original?

<comment><USER5> Two different senses of the word 'saturation'. The subtitle of the article (current title here) is unfortunate.

<comment><USER6> Yes. I expected to see an article about stock images being overused across lots of publications, and whatever the fix for that is.

</comment></comment></comment><comment><USER7> Looks to be more related to exposure than saturation but still, it's an interesting new take on dynamic range. I'm more a hobbyist than an expert but current tone mapping techniques (at least anything mostly automated) can often leave you with "halos" around objects where the software has feathered the edges between lighter and darker areas. Then the article mentions the issues with using multiple shots for tone mapping.

I still try to just expose "properly" for the effect I want and shoot RAW to give me a little leeway in tweaking shadows and highlights but I'd be interested in trying out software that uses this technique if only for something new to mess with.

<comment><USER4> Halos are a problem, but they can mostly be removed with good post-processing. Note they're not a fundamental aspect of tone mapping. Tone mapping is just whatever algorithm you chose to compress the HDR information into a low dynamic range we have for displays. The great thing about this camera compared to multi-exposure HDR (apart from the halo effect you mentioned) is you can actually take pictures of moving objects or even make HDR movies (the temporal variation should actually help with better phase unwrapping). That would be amazing for the film industry I think.

<comment><USER7> Out of curiosity, with regard to video, what would be the difference between what you describe and a nicer version of the sort of processing used in (for example) some Axis security cameras? I guess the current method is just to capture a decent range and then process each frame to boost the gain on shadows and lower the gain on highlights, right? Sort of an extension of quick-and-dirty HDR on still photos.

Either way, this is the sort of stuff that has always interested me about photography and videography. The creative aspects are obviously the end goal for most people (myself included) but I've always been a sucker for the technical aspects of it...the craft to the art as it were. Nothing prompts me to pick up my camera and shoot some photos or some video like learning about some new tool or technique that I want to try out. It may be the mark of the eternal amateur but still enjoyable.

<comment><USER4> I'm not familiar with those cameras. But if they're using a conventional sensor, this technique yields qualitatively different results.

</comment></comment></comment></comment><comment><USER8> I am probably less technical than most of you but the upside of this technology (at the point it is real world ready) might be producing what I would call a RAW file that is RAW(ER). By that I mean the file would simply contain a wider range of scene information that could be accessed by Adobe Camera Raw or the like. For the class of photographers that have no interest in RAW the information would help the JPEG engine in the camera make a "better" informed JPEG (or whatever the standard is at that time). To me capturing more scene info is better than less assuming there are minimal penalties being paid elsewhere (file size, burst shooting etc).

As a side note, it seems to me that aperture and shutter speed would still be essential as they affect not only exposure but depth of field and subject motion. Perhaps a technique that allows proper exposure independent of fstop/shutter/ASA would allow exploration of extremely wide aperture with slow shutter but no need for ND filters.

In any event it will be interesting to see what happens.

</comment><comment><USER9> What's with the completely useless thumbnail at the bottom?

That said, the technological explanation sounds simple and solid. Why aren't cameras doing that already?

<comment><USER10> I wondered the same; it takes two hyperlinks to get to the project's home page where they have a larger version. [http://web.media.mit.edu/~hangzhao/modulo.html](http://web.media.mit.edu/~hangzhao/modulo.html)

<comment><USER9> Nice, thank you!

</comment></comment></comment><comment><USER11> It seems like this would make big glass even more important. This solution protects for over exposure, but doesn't address under exposure on a scene that moves (think indoor bar photography). So it isn't a end all solution that will everyone capture reality with their cell phones, but it is an awesome step in that direction.

</comment><comment><USER12> I had an idea similar to this that solved the oversaturation issue.

Use 2 cameras. Have them at right angles to the shutter point, separated a few inches. At the T junction where the camera pointing would cross with the shutter area, put a prism there.

The prism would give each camera 1/2 of the available photons. Now use any standard HDR processing technique.

<comment><USER13> Interestingly enough that's how Technicolor used to work. Three separate exposures from a single lens, split off by pellicle mirrors.

The downside is that like any pellicle you are dividing your light between multiple exposures, meaning you some mixture of a longer exposure, a faster lens, or more lighting. Technicolor required special high-intensity arc lighting. Also, the pellicles must be kept spotless because dust shows up on the final image.

Next-gen sensors will actually implement this physically - some receptor sites will be larger than others.

<comment><USER12> Admittedly, my understanding of traditional optics is very limited. I happened upon it in a dream whilst trying to figure out how to handle dynamic scenes while using SLAM.

I was thinking of a prism (new word: pellicle mirror) like this one :

[http://static1.squarespace.com/static/54ca877ce4b014ea90e14b...](http://static1.squarespace.com/static/54ca877ce4b014ea90e14bda/54ca9f5de4b021f8b6d68cc1/54caa186e4b021f8b6d6c6b8/1422565766946/penta_3.png?format=original)

Except I don't need the deconvolutional prism. I can handle that in software easily with a X or Y matrix flip. And I assume we are using the same CCD module for both areas; given that, I can sum the contrast between the pixels and calculate the min and max, as well as can calculate the HDR image from both sources.

Calibration would be easy to handle, using a checkerboard to link the CCDs to each other (assume aligning errors will happen).

I also see no reason why the pellicles wouldn't be kept clean. The same goes for the CCDs as well. I'd embed them in a dark acrylic box and try to seal them as best as can be.

<comment><USER13> The acrylic box blocks all your light (dark is bad), and now you have to keep THAT clean instead. Any surface in your optical path needs to be kept clean, but especially those that are between the center of the optical system and the sensor. Dust on the front element doesn't matter too much, dust on the rear element matters a lot and pellicle mirrors are even worse since they're closer to the focal plane. Scratches from cleaning are real bad too.

As long as your lens system is sealed it's not a problem. But many systems are interchangeable-lens, and when the lens is removed then dust can float in. Or some lenses generate a "vacuum" effect as they focus in and out.

Sensors often incorporate an ultrasonic motor which vibrates it and throws dust off. Or some sensors are mounted on shake tables to reduce blur from operator motion - you can do a similar thing there too. At the end of the day you just have to be careful though.

Like I said, totally possible optically, and yes, very simple to process. The downsides are that when you split the beams each sensor only gets half the light intensity, which means you need to get more light into the optical system in the first place, and you need 2 sensors, which are by far the single most expensive component in the whole camera.

You can actually do something similar with Magic Lantern, a hacked-up open- source firmware for Canon cameras. They scan alternate rows of the sensor at different sensitivities, and use the low-sensitivity row as the most- significant-bits of dynamic range for the high-sensitivity image. You lose a bunch of vertical resolution, but hey, you don't need 2 sensors.

</comment></comment></comment></comment><comment><USER14> I wonder how this compares to just adding a few extra bits to the sensor data. The paper ([http://web.media.mit.edu/~hangzhao/papers/moduloUHDR.pdf](http://web.media.mit.edu/~hangzhao/papers/moduloUHDR.pdf)) compares against an "8-bit intensity camera", but most cameras today use 12-16 bits internally. Isn't "this pixel overflowed" essentially just an extra bit of information?

The pictures using the "modulo camera" are definitely better quality, but don't look noticeably better than what I could do with a RAW from my camera and 2 seconds in Capture One or Lightroom adjusting the shadows and highlights.

</comment><comment><USER15> As a photographer who at times needed to deal with HDR this is great news. In the past, I had often wondered why some scheme like this wasn't possible. However, the title of this post is horrible. I understand they were trying to market it in a way it was accessible to most readers. That said, photography has become quiet popular and most people now understand HDR. So they could have just presented as true HDR with only a single frame image.

</comment><comment><USER16> I would love to feed a photo of an overexposed zebra to their reconstruction algorithm and see what happens. I think it will be spectacular!

</comment><comment><USER17> Read about something like this on [http://image-sensors- world.blogspot.co.uk](http://image-sensors-world.blogspot.co.uk) a while ago - instead of saturating the CMOS when max brightness is exceeded, it just keeps going.

Looking forward to seeing this commercialised.

</comment><comment><USER18> This is a great idea. It would be interesting to see the failure modes though because the phase-unwrapping surely can't handle every situation (e.g. adding a constant value >255 to the whole image).

</comment><comment><USER19> Anyone know what they mean by an "inverse modulo" algorithm? That only seems meaningful for numbers coprime to the sensor ceiling value.

</comment><comment><USER20> "Beginning of the end for over-saturated images" ?

Well, then, say goodbye to the Disney channel, the most oversaturated channel out there.

</comment><comment><USER13> Here's an idea, instead of separately tracking the number of "resets" we just add those bits on to the left hand side of the measurement. We could call it... having more bits in the ADC. Expose for the highlights and then pull more detail out of the shadows with your extra bits of ADC precision.

There are not 1 million ADC units in a 1-megapixel camera, there's a few ADCs (a Canon 7D has 2 image processors with 4 ADCs each) that are iterated across the CCD sites to progressively read them out. To make this new sensor, you need to cram 50 million sets (50mp is state of the art) of voltage comparator/charge reset/digital counter circuits onto the CCD, and for N bits of rollover accuracy they need to be able to trigger, erase the charge, and resume exposure at least N times during the exposure time E (which is say 1/500th of a second, since they're complaining about movement during multiple HDR exposures). Practically speaking the trigger/operation/resume period must be significantly less than E/N since I see no way to retain the exposure during the period when the charge well is being drained to zero. If this time is non-trivial, that translates to losing the fine bits of your ADC accuracy.

In their image they compare a 13-stop exposure (the current state of the art) to an 8-stop exposure (state of the art in 1900). So assuming they didn't just pull a photoshop out of their ass, they are overall claiming a 5 stop increase from state of the art. That's 5 extra bits of recovery (1 stop is double the range, i.e. an extra bit), so they think they can trigger the reset circuit 5 times during an exposure. That implies this circuit must have a minimum cycle time of 1/2500th of a second (practically speaking a lot less to give time for the actual exposure). With this math I'm also assuming that the comparator is perfect and doesn't lose any accuracy - variance in trigger threshold or trigger time translates to losing some of your accuracy again. They also need to generate little enough waste heat to avoid hot pixels (this is a major reason the ADC is on the image processor rather than the CCD), and you need 50 million sets of these on the CCD.

If you can do it then go for it. It's a nice idea on paper but I think there's a lot of physical obstacles to overcome. If it were that easy someone would have done it already. It's especially difficult given that reading out the sensor is _destructive_ \- measuring it wipes the charge, so I'm not sure how any of this would work at all given that.

Now what would actually be interesting is to apply the image-processing techniques to dual-DR imaging, as they mention in their "related works" section. The open-source Magic Lantern firmware for Canon DSLRs allows you to scan alternating rows at different ISOs, so effectively you can capture a lot more dynamic range at the expense of your vertical resolution. It's all volunteers and they probably haven't applied all the fancy image-processing magic with the convolutions and the hippity-hop rap music. How about reconstructing those overexposed lines instead? Or working on some of the sensors with physical implementations of dual-DR?

<comment><USER21> Reconstruction is based on guessing in software/ISP. That way you don't need to keep track of the number of resets.

</comment></comment><comment><USER22> The original title of the article is, "Unbounded High Dynamic Range Photography Using a Modulo Camera"

</comment><comment><USER23> Can somebody explain how this design differs from existing self-resetting pixel designs?

<comment><USER16> I'm not sure what you mean by self resetting pixel designs. Do you perhaps means the self-shuttering (rolling shutters) on CMOS sensors?

This is very different. If you oversaturate either a self shuttering sensor or a shuttered CCD, that information is gone. All you know is that this is "100% bright, or more". Your software which turns raw sensor readings into an image makes the area full brightness, and you get blow outs.

With this approach, say the light is bright enough to make a pixel read 567% (if that as possible). A standard sensor would record 100%. This sensor would empty itself five times and record 67%. Then, the algorithmic magic happens which looks at neighboring areas and figures out how many roll-overs happened and adds the 500% back in.

You can't do that perfectly (hence my comment before about an overexposed zebra), and it will introduce new forms of aliasing, kind of like de-bayering the bayer masks makes moiree patterns.

<comment><USER23> I've seen CMOS pixel designs in the past that can detect saturation and effectively dump the well (reset) repeatedly until saturation no longer occurs.

</comment></comment></comment><comment><USER24> Reminds me of the implementation of the TRNG from yesterday's front page.

</comment><comment><USER25> This was the runner up prize winning paper, what won?

<comment><USER26> [https://twitter.com/ICCP_2015/status/592403545468448768/phot...](https://twitter.com/ICCP_2015/status/592403545468448768/photo/1)

<comment><USER27> That's a picture. Where's the paper?

<comment><USER28> Here's the paper link: [http://www1.cs.columbia.edu/CAVE/publications/pdfs/Nayar_ICC...](http://www1.cs.columbia.edu/CAVE/publications/pdfs/Nayar_ICCP15.pdf)

</comment></comment></comment></comment><comment><USER29> A related, but quite different technology I worked with are so-called Dynamic Vision Sensors (DVS, [1]): This is a CCD that was developed to mimic a biological retina and only reports _changes_ in brightness, asynchronously for every pixel. Essentialy, you get a stream of short messages saying "Pixel XY just got a little brighter at time T".

While such a thing is not very useful for taking pictures (pointing the camera at a static scene will generate no output at all) or videos (you don't get discrete frames, you get a continuous stream of differentiated pixels), it has a lot of potential for computer-vision tasks:

For one, as the camera only reports changes, only the interesting information is transmitted which greatly reduces computational load (eg. no need for "yes, that white wall is still there"-style calculations for every frame).

Secondly, because these changes are reported independently per pixel, they are very fast: Microsecond accuracy with a dozen or so uS delay are easily achievable. For comparison, a fast camera with 120 FPS (which will produce _a lot_ more data to process) has an accuracy and latency of 1/120s = 8333uS. This also implicates that motion blur is basically nonexistent.

And thirdly, as absolute intensity doesn't matter, you don't have any problems with high dynamic range either.

The only downside is, that you don't really get a picture and most of the traditional computer-vision approaches are unusable ;)

But still, such a camera is very neat, even if you just track the movement of your mice or want to balance a pencil on it's head[2].

The real deal however is full vision based 3D-SLAM, which would allow for very fast and robust movement without any external help from motion capturing systems or expensive (in money, weight and power) sensors like laser scanners. AFAIK, we're not there yet (see [3] for some work in that direction), but that would bring pizza delivery with a drone directly to your desk quite a bit closer to reality...

\--

[1] [http://www.inilabs.com/products/davis](http://www.inilabs.com/products/davis)

[2] [http://www.ini.ch/~conradt/projects/PencilBalancer/](http://www.ini.ch/~conradt/projects/PencilBalancer/)

[3] [http://rpg.ifi.uzh.ch/research_dvs.html](http://rpg.ifi.uzh.ch/research_dvs.html), also [https://www.doc.ic.ac.uk/~ajd/Publications/kim_etal_bmvc2014...](https://www.doc.ic.ac.uk/~ajd/Publications/kim_etal_bmvc2014.pdf)

</comment><comment><USER30> Title changed from "Beginning of the End for Oversaturated Images"

</comment><comment><USER31> Instagram and the like will ensure the future proliferation of shitty images, no matter the technology.</comment>


Rails and Merb Merge: Performance - <AUTHOR> http://www.engineyard.com/blog/2009/rails-and-merb-merge-performance-part-2-of-6/ <comment><USER2> It's really great to see 2 projects come together like this. Throwing up your hands in frustration and just designing a new web framework seems to be the way things are done these days. Actually working together to improve something that is already deployed and popular is harder, but the pay off is going to be great from the look of it. Major kudos to everyone involved.

<comment><USER3> I really like how mature rails is these days, there's so much good stuff around for rails, and it keeps on getting better.

Interesting with ruby 1.9 performance, I've been thinking about making the switch. I doubt that the pay-as you go services will switch anytime soon, if it will half their winnings in the short run.</comment></comment>


Google Plans New Mirror For Cheaper Solar Power  - <AUTHOR> http://www.wired.com/epicenter/2009/09/google-solar-power-mirror/ <comment><USER2> I wonder when we are going to hear more about the green car that Google is working on (seriously). These panels may be adaptable for that use as well.

<comment><USER3> I wasn't aware that Google was working on a car but I doubt it will benefit directly from this project. Thermal solar is generally only used on very large scale projects as you need a surface area sufficient to heat a working fluid well over 100 degC. A car roof just isn't going to work.</comment></comment>


Ask HN: What do you do when you are bored outside work? - <AUTHOR> I have a decent job. I have fun at work. It is after the working hours that I can't bear. I am bored constantly. I don't like to engage in mindless crap like Netflix or anything on internet TBH. And I don't like to engage in anything too intellectually exhausting like reading novels.<p>The long term effects of this are showing up. I go to bed unrelaxed, so don't have a great sleep. What do you folks do which is enriching and relaxing at the same time to kill off boredom? <comment> a-saleh I used to go indoor bouldering. Now too tired unfortunately. I have been climbing a bit (indoor as well) and if I could spare 3 hours two times a week, it would have been awesome hoby :) Right ammount of strength, endurance and puzzle-solving :P And many places have support for solo climibng as well.

These days I often just drink a pint of beer and play a simple boardame with my wife, after we managed to get our daughter to sleep :)

</comment><comment><USER2> Long walks in nature. Long enough to get you physically tired. The green surroundings are scientifically proven to have calming and soothing effect (no music/podcasts on the go though!). However, in my climate it's viable for maybe 6 months in a year. The other six months suck - that's when I get sad and gain weight.

</comment><comment><USER3> In a world inwhich the gap between reading a book and watching tv is the difference between mindless and exhausting your options are pretty limited.

Maybe weight lifting / other fitness related activity? If nothing else you should sleep well if you're getting physical activity in.

</comment><comment><USER4> I do some bike riding (Mountain biking, road biking, and/or BMX), and lift weights. I also like to hang out at the local hackerspace occasionally and just talk to people there, see what projects other people are working on, etc.

Mostly I work though. Aside from the 40'ish hours a week I put in at the day- job, I put in probably around another 40 hours a week working on my side project. So I don't really have a lot of idle time. I do try to get some reading in though... usually for 45 minutes or so before I fall asleep at night, or ever now and then I'll take a long, hot, bath and read in the tub.

</comment><comment><USER5> _" KILLING TIME!" roared the dog—so furiously that his alarm went off. "It's bad enough wasting time without killing it." And he shuddered at the thought._

 _Norton Juster, The Phantom Tollbooth_

Have you found anything that strikes a good balance between intellectual stimulation and relaxation?

I've found a number of hobbies that help with this. Two that come to mind that work for different reasons are exercise and drawing. Exercise lets my mind wander, builds dexterity, and tires me out (among many other benefits), and I find that drawing is a great way to relax and think in a different mode than my day job.

</comment><comment><USER6> Honestly, if you find "reading novels" intellectually exhausting, you're setting the bar pretty low :) Maybe some sport?

Personally I like to build little aircraft models, read, or play board games with my wife.

<comment><USER7> Board games are a good one. I recently started picking them up again after not playing since childhood.

You get to socialize, get a varying level of mental strategy in there, and it's fun. Depending on how tired or what mood you are in, you can pick a different game. Also, like you mentioned, a great bonding experience with your SO and/or friends.

</comment></comment><comment><USER8> Yoga, meditation, music production, writing, high CBD cannabis.

</comment><comment><USER9> I haven't been to work in 2 years...</comment>


Show HN: "Remind to Read" button on your website - <AUTHOR> http://remindto.app <comment><AUTHOR> Explainer video: [https://youtu.be/HYPGbGXXzkU](https://youtu.be/HYPGbGXXzkU)

I believe that there is a missing button on most social share toolbars to send stuff to yourself, later. I made this and want to know what you think!

This works by providing you a JavaScript file that you can put on your page. The file looks for a predefined element class, then turns those elements into a "Remind To Read" button.

When clicked, the button accepts an email address. After input, the button defaults to sending the user a reminder email in 4 hours. The users can also manually set the delay period.

The email itself is meant to be designed by the site owner. The email can be used to promote other content, call-to-action functionality, etc. By default, the email also contains "snooze" buttons, to trigger another delayed email.

<comment><USER2> This is a great idea. I use Send to Kindle for this. As I go around, I find articles I want to read but don't have time now. So I use Send to Kindle to send it to my Kindle. And then later I have many articles on my Kindle to read.

<comment><AUTHOR> Glad you like the idea! I just noticed that the site is in a redirect loop. : p

Edit: Fixed the loop

</comment></comment></comment><comment><USER3> No pricing options that I can see. Makes me think I either have to have a conversation with a sales-weasel or that your pricing model is going to be a pain to work with for a small site.

<comment><AUTHOR> Ah-

No sales weasel. Just me : ).

The model I was thinking was that it is free under a cap. I dont think most people would actually hit the cap.

Should not be hard to implement for small website.

Email me and I can give better directions: firstname.lastname@example.com

<comment><USER3> I don't _want_ to email you. I just want to see some upfront pricing and then I'll decide if it's the service for me.

I don't want to negotiate, enter into a relationship, sign up to a newsletter, or - if I'm honest - talk to you.

Sorry for being a bit blunt - it looks like a decent service, but I can't really be bothered waiting to see what your caps are. Just put it on the site. Please :-)

</comment></comment></comment><comment><USER4> Two more thoughts:

The button should be very visible at the top. Because it does not make sense to read the article first and then find this button at the end...

If possible add a number like '243 read me laters' just like the sharing options normally do. Maybe that is more encouraging.

And final thought: this should actually be part of the normal sharing options. Next to the Facebook, Twitter and email ;-) buttons. Partner up with services like 'AddThis'.

<comment><AUTHOR> I love your points.

Im bullish on making it a part of the the social buttons.

The data I've seen from working at a publication company for the past two years is the following: Desktop users will start an article, then scroll to the bottom before leaving; The average bounce point for users is after the "first page; Most users dont click share buttons.

</comment></comment><comment><USER4> I understand this looking from the content provider (the website). However, I am very curious for visitors using this: leaving your email to all websites whenever a title seems interesting (even more incentive for click baiting ?)

I normally leave 'read later' opened in new tabs. If I still like it after a while, I add to Pocket. Seems to me most 'structured' readers use a service like Pocket for this.

<comment><AUTHOR> I lean toward having this work on trusted publishers.

The pocket/new tab method is good, except when you have too much stuff. There is a breaking point for both of those systems, in that you have too many "saved" pieces. When you get to that point, adding new pieces is meaningless.

The defined future reminder prevents this accumulation of delayed content to happen.

<comment><USER4> > The pocket/new tab method is good, except when you have too much stuff

So your alternative is leaving your email everywhere and every time ? Hmmm. Not my idea. Sorry. I prefer one external (general) service / solution. Like emailing to myself, saving in a new tab or saving to pocket (if I think its really worth to make time to read).

But still, that is just me. Curious how the general public will react. For example, I am not much of sharing stuff that I read with everybody. If (sometimes) I share its with argumentation to specific friends. Not very common nowadays it seems ;-)

<comment><AUTHOR> Really good point.

This is definitely meant to serve users who have a loyal association to a brand/blog.

I imagine it as a middle ground between email newsletter.

</comment></comment></comment></comment><comment><USER5> I built a tool ([https://github.com/apeeyush/coffee](https://github.com/apeeyush/coffee)) that takes an atom/xml feed and sends contents from it over mail periodically. Using it to complete some feeds (interview prep, startup lectures etc.).

This might work well with "Remind to Read" if it could create an xml feed for each user.

Hoping to receive HN community feedback on it since it is one of the few end- to-end systems I have built completely :)

</comment><comment><USER6> Great idea! Also check out [https://www.wallabag.org](https://www.wallabag.org), a self hostable application for saving web pages.

</comment><comment><USER7> That's really cool, and perfect for people like me who do everything in email (as opposed to having offline reader apps)!

<comment><AUTHOR> Thats how it started! I do the same thing.

I was considering to temporarily make this a browser extension.

Do you think you would use it if it was?

</comment></comment><comment><USER8> This looks great! I use bitly for this now, to an extent...save the link, and then when I remember, go back and read whatever is at the top of my list from the last little while.

I can't wait to use it -- especially if you add a "digest" function that sends me one email at a particular time of the week, with links to everything I saved...

</comment><comment><USER9> Great idea, wish I could just try it out without booking a demo/emailing someone/etc. That would really convince that it may even be something to pay for. Publically visible info on the cap or a pricing tier would go a long way.

<comment><AUTHOR> Since first making this, I have put together those two things!

The pricing scale is meant to help the service pay for itself. You can see it here: [http://remindtoread.com/pricing](http://remindtoread.com/pricing)

You can now sign up for your own account and set up.

</comment></comment><comment><USER10> Cool!

There's a typo.

> RemindToRead enables seamless user expereinces from visit to return and > beyond.

Should be: RemindToRead enables seamless user experiences from visit to return and beyond.

<comment><AUTHOR> Thanks!</comment></comment>


The Incredible Click Rate of Nothing - <AUTHOR> http://adage.com/article/digital/incredible-click-rate/236233/ <comment><USER2> I'm astonished at the low CTRs the "big" advertisers are satisfied with. Most of the direct-response people I know (including me, although I'm a comparative novice) tend to junk anything getting below 0.1% clickthrough rate out of hand, and aim for .2% - .5% or higher.

<comment><USER3> I remember reading in passing something about companies being able to do funny tax stuff with their advertising budget. Maybe that is the motivation?

<comment><USER4> It wouldn't surprise me.

<comment><USER3> I guess it doesn't count as "funny stuff", but all advertising expenses are tax deductible.

<http://www.irs.gov/publications/p535/ch11.html> [ctrl-F "advertising expenses"]

</comment></comment></comment></comment><comment><USER5> I would want to see how this stacks up with things like deliberately un- interesting and generic ads that at a glance still look like a normal product, or even ads designed to look like part of the page's background.

For all we know, they got a bunch of extra clicks just for looking different. (Remember the story about the banner ad made in MS-paint?)

<comment><USER6> Half of them were just curious, according to the survey the ad linked to.

<comment><USER7> Which brings "mistaken" back down to the average CTR for an ad of that type, instead of double the average.

</comment></comment></comment><comment><USER8> They seem to have missed the most important thing about accidental clicks: the position of the ad matters more than anything else.

If your ad is next to an important button you will get a higher CTR. If you advertise on a site that gets a lot of mobile visitors _and_ your ad is next to an important button you will get a very high CTR.

</comment><comment><USER9> Quote from article: "When I want to make quick money on clicks," he said, "I just buy late-night impressions on women's gaming sites. I guess the users are tired. They click like crazy. I make a lot of money."

I don't know that much about online ads. How do you make money buying "impressions" like this? How does this work?

<comment><USER10> Ad guy here:

So this guy is probably talking about affiliate marketing.

My best guess:

1\. He has access to lots of CPA (cost per action) offers from various CPA networks. Example: "We'll pay you $3 for every person who fills out this info request form about our product."

As an affiliate marketer, he's always hunting for offers where the payout seems high or the offer seems attractive, basically an arbitrage mismatch.

2\. He has found some gaming offers that he thinks pay out pretty well and convert nicely. Good landing pages, good product, etc.

3\. He buys ads on these womens gaming sites late at night because they are click happy and the impressions cost less due to it being night time. This sends people to the gaming site where they convert at a profitable rate.

Affiliate stuff is all about arbitrage.

<comment><USER11> I'm curious: On which platforms can I buy links targeted to "late at night"?

<comment><USER12> Most DSPs offer so-called "time parting" functionality, where you set your ads to run only during specific hours (and/or days). For example our product <http://www.direct-ads.com/> or our competitor <http://rtb.sitescout.com/> offer this.

</comment></comment></comment></comment><comment><USER13> That's neat. So, out of the people who took the survey, 1/2 were curious and 1/2 mis-clicked. How many even bothered to take the survey? What's neat is that 0.08%, the reported CTR, is higher than on some regular ads.

<comment><USER14> I think the curious ones should be discounted. You would be surprised at how tempting a vague ad might be to naturally curious humans. The 0.04% figure of mistakes is interesting to me as 'background noise' for ad clicks.

This would probably be an interesting area for more academic research. How do you measure accidental clicks? Do some non-ads receive higher accidental clicks than others? What if it was a blank black ad? What if you mimicked actual ads but with the 'why did you click' question? There are lots of ways this phenomenon could be further explored, and I agree with the author that for a multi-billion dollar industry this exploration is warranted.

</comment></comment><comment><USER15> So a while back I wanted to make some ads for my web comic. I drew some pictures of the female protagonists and made an animgif cycling between them, because, well, sexy girls get clicks.

Then I looked at it without the text, and there was… something there.

So I did a poll on my blog as to which version people felt they'd click on. Things were split very slightly in favor of the one with the text, but I wasn't convinced. So I dumped 'em both into the same Project Wonderful campaign, and told PW to do the thing it does where it displays them at random, and starts changing the percentages based on which one gets more click-through.

A couple days later, the one with the text was almost never being displayed.

Of course, if everyone starts doing this then eventually people will get sick of ads with "important" information missing. Maybe I'm glad I got in before the rush.

</comment><comment><USER16> Ha - I used to work with Ted in my P&G digital analytics days. Nice to see him shaking things up in this industry.

</comment><comment><USER17> 0.02-0.04%? That seems higher than Facebook's usual CTR of 0.015%. Maybe Facebook should use blank ads, too, and see their ad revenue double overnight.

<comment><USER18> Where do you get that 0.015% is a usual CTR for FB? That's actually quite low, even for them.

<comment><USER17> From 2 articles that appeared on HN a while ago, that tested Facebook advertising campaigns.

</comment></comment></comment><comment><USER19> This experiment probably means this - most of the AD designs are Awful, with a big letter "A". They are so bad that they actually decrease CTR of AD campaign even compared to the blank rectangle image.</comment>


Iran unblocks Twitter and Facebook, first time since 2009 - <AUTHOR> http://arabcrunch.com/2013/09/iran-unblocks-twitter-and-facebook-first-time-since-2009.html

<comment><AUTHOR> the bad news is that blocking is restored again</comment>


ShowHN:Introducing Feedbacker-lite: Free feedback widget for your website - <AUTHOR> http://feedbacker.bakarbox.com/

<comment><AUTHOR> An old method of feedback but still an effective one. Please provide your valuable feedback on this. Ideas for next version and so on..</comment>


Google Now Seeing 2% IPv6 Traffic - <AUTHOR> http://www.internetsociety.org/deploy360/blog/2013/09/google-now-seeing-2-ipv6-traffic-the-internet-is-changing/

<comment><USER2> Interesting to note that the Google IPv6 usage spikes on the weekend (and Friday to a lesser extent).

This suggests work systems are _less_ likely to be IPv6. My guess is that it isn't home which is IPv6 but 4G mobile, which has been deployed entirely within the IPv6 era.

<comment><USER3> My Verizon phone started showing an IPv6 number a few weeks ago.

<comment><USER4> Are you sure it just happened? Verizon has been running IPv6 on LTE for at least 2.5 years.</comment></comment></comment>


Ask HN: What are some good books on creating abstractions? - <AUTHOR> Does anyone have any recommendations for books or journals/papers to read to improve my ability to write useful and maintainable abstractions? Ideally I'd like to find a more formalized treatment of "abstracting" in the vein of the GoF's Design Patterns or a survey of the field like the excellent Designing Data Intensive Applications but I'm guessing that's kind of like asking for a map to the Holy Grail. <comment><USER2> Those are the holy grail:

1) [https://www.amazon.com/Object-Oriented-Modeling-Design- Rumba...](https://www.amazon.com/Object-Oriented-Modeling-Design- Rumbaugh/dp/8120310462)

2) [https://www.amazon.com/OMT-Insights-Perspective-Object- Orien...](https://www.amazon.com/OMT-Insights-Perspective-Object-Oriented- Programming/dp/0138469652)

1) [https://www.amazon.com/Executable-UML-Foundation-Model- Drive...](https://www.amazon.com/Executable-UML-Foundation-Model-Driven- Architecture/dp/0201748045)

And the work of daniel Jackson from MIT :

[http://people.csail.mit.edu/dnj/](http://people.csail.mit.edu/dnj/)

Look at this course, at the videos at the bottom:

[https://stellar.mit.edu/S/course/6/fa18/6.170/materials.html](https://stellar.mit.edu/S/course/6/fa18/6.170/materials.html)

Jackson is also behind Alloy:

[https://mitpress.mit.edu/books/software-abstractions- revised...](https://mitpress.mit.edu/books/software-abstractions-revised- edition)

</comment><comment><USER3> > Ideally I'd like to find a more formalized treatment of "abstracting" in the > vein of the GoF's Design Patterns.

Well [1] that book you're referring to, has changed my perspective on abstractions and how to communicate them to other people. There's probably no _" Holy Grail"_ of abstraction guides better than that IMHO.

Designing and implementing useful and maintainable abstractions comes from experience in both consuming and designing abstractions for API's. Having empathy for both the consumers and future developer's of the API gives you a good perspective on how to structure the abstraction.

The best abstractions are from people who have used _bad abstractions_ , and are usually incrementally developed over time...

[1] [https://www.amazon.com.au/Design-Patterns-Elements- Reusable-...](https://www.amazon.com.au/Design-Patterns-Elements-Reusable- Object-Oriented/dp/0201633612)

</comment><comment><USER4> Here are mine:

* XML Schema - [https://www.amazon.com/Definitive-XML-Schema-Priscilla-Walms...](https://www.amazon.com/Definitive-XML-Schema-Priscilla-Walmsley/dp/0132886723/ref=mp_s_a_1_1?dchild=1&keywords=xml+schema&qid=1586680576&sr=8-1)

* DOM - [https://www.amazon.com/DOM-Scripting-Design-JavaScript-Docum...](https://www.amazon.com/DOM-Scripting-Design-JavaScript-Document/dp/1430233893/ref=mp_s_a_1_2?dchild=1&keywords=document+object+model&qid=1586680658&sr=8-2)

* I don't have a book for this, but learn data structures instead of algorithms. If you can learn to think in data structures the concepts of algorithms will come to you naturally like dreaming or thinking about driving directions.

* I also don't have a book for this but the relationships between data is more important than the data itself. This is realized by how you express your abstraction.

</comment><comment><USER5> A Philosophy of Software Design by John Osterhout: [https://www.amazon.co.uk/dp/B07N1XLQ7D/ref=dp-kindle- redirec...](https://www.amazon.co.uk/dp/B07N1XLQ7D/ref=dp-kindle- redirect?_encoding=UTF8&btkr=1)

Concise, readable, and highly applicable.</comment>


Simple Testing Can Prevent Most Critical Failures [pdf] - <AUTHOR> http://www.eecg.toronto.edu/~yuan/papers/failure_analysis_osdi14.pdf <comment><USER2> Error handling on signals are such and easy thing to put off and "do later." Even though the signals often will tell you something about how to error correct.

In one way I feel like the title for the paper is not correct, in the conclusion, they state that testing all these signals is not straight forward. But in my experience, a lot of critical failures _could_ be prevented with very simple automated testing.

<comment><AUTHOR> Agree with you totally.</comment></comment>


Rich Californians are hiring private firefighters to protect their homes - <AUTHOR> https://nypost.com/2019/10/26/rich-californians-are-hiring-private-firefighters-to-protect-their-homes/ <comment><USER2> [https://www.npr.org/2019/06/27/736715592/the-private- firefig...](https://www.npr.org/2019/06/27/736715592/the-private-firefighter- industry)

</comment><comment><AUTHOR> > The practice, while not new, can be problematic, and not merely because of > the income inequality issues it raises

How is this income inequality any more than the fact that someone who has more income can do many things that someone with less income can't? It's not like the city is decided to protect expensive homes vs. poor areas (they might be but my point is that might be 'inequality' but a private citizen paying for something (or their insurer) is not 'inequality').</comment>


Pros and cons of releasing Perl 5.20.0 as Perl 7.0.0 - <AUTHOR> http://blogs.perl.org/users/ovid/2013/02/perl-7.html

<comment><USER2> I recently took a few years off full-time development to attend grad school, and whenever I worried about my skills getting out of date I'd tell myself, "I'll know I've stayed too long if I'm still here when Perl 6 ships." As it turns out I've been back in full-time development for the last two years, and it still isn't ready.

Perl was my "first love," but I think almost all developers who would have adopted Perl 6 have already moved on to Python or Ruby.

<comment><USER3> Or stayed with Perl 5. The last couple of years has seen a lot of development on the core of Perl 5, and there are a ton of libraries on CPAN to make up for some of the language deficiencies that would require severely backwards- incompatible changes to the language.

</comment></comment><comment><USER4> Recently, I watched someone code in Mojolicious (a remarkable Perl framework). It was simple, brilliant, elegant and yet felt incredibly lightweight as well - lots of wow-factor.

But sad to say, most will never see such beautiful things, merely because of the version number. That's life, I guess.

</comment><comment><USER5> "Perl 5" is a programming language. So is "Perl 6". They're sister languages, not competitors.

This release will be "Perl 5" version 20.

As the guy who was responsible for 5.12 and 5.14, I think this is a horrible idea. It'd lead to incredible amounts of user confusion and break all sorts of shit for pretty much no upside other than a version number pissing match with Perl 6.

<comment><USER4> And yet, it pains me to say (ouch!), mindshare is a function of version number. User confusion? It's already out there, in the form of misinformation.

</comment></comment><comment><USER6> Perl 6 is a perfect example of both Fred Brooks' Second System Effect and Joel Spolsky's Things You Should Never Do.

</comment><comment><USER7> I love the idea, it's time to move on.

Perl5 is God. Perl6 is Jesus who will never ever return to Earth no matter how much we pray. Perl6, R.I.P.

I care so much more about the existing modules on CPAN, written for Perl5, than the [insert feature] of Perl6, or any other copy cat languages.

<comment><USER8> What does that make Perl 7, the Holy Ghost?

</comment></comment><comment><USER9> I've long since stopped using Perl so forgive my ignorance.. Is Perl 6 widely understood in that community to be a different language and not the evolution of Perl? That's what the discussion on this blog indicates. Is the Perl 6 language a dead end or are people enthusiastically working on using it for production systems? I truly don't mean this question as flamebait, I am curious what the consensus is in the Perl community.

<comment><USER10> _Is Perl 6 widely understood in that community to be a different language and not the evolution of Perl?_

Yes, in part because it's taken so long and delivered so little and in part because Perl 5's core development picked back up again a few years ago (and the CPAN never stopped improving).

 _Is the Perl 6 language a dead end or are people enthusiastically working on using it for production systems?_

The intent of the people working on it is to produce something which will eventually be usable for serious projects, but no one can give a good prediction as to when that will happen.

<comment><USER11> Given that specifications such as Unicode, Security and a Standard Library are examples of the Synopses still "TBD" after all these years, many Perl users will have retired from programming entirely before Camelia/Perl 6 is "of use." The fact that major Synopses such as these are left to the end is not necessarily reassuring either.

<http://perlcabal.org/syn/>

</comment></comment></comment><comment><USER12> I really think such a move would be overly confusing

* Perl 7 coming out before Perl 6

* Perl 7 being compatible with 5

* Perl 6 being compatible with neither 5 nor 7

<comment><USER13> But this kind of version skip has some precedents. At least the Winamp "we messed up 3 so badly that we're going to skip a version" 5, comes to my mind.

<comment><USER14> Is perl 6 messed up? I haven't had the time to look at it, but it doesn't seem to.

<comment><USER15> It would have to get substantially less vapor-y to even qualify as "messed up".

</comment></comment></comment></comment><comment><USER16> After backporting all of Perl 6's new features into Perl 5, rename it Perl 11 because 5 + 6 = 11.

<comment><USER17> What does this-here open-source outfit look like to you -- WinAMP?

</comment></comment><comment><USER18> I think that going with Perl 7 would be good for the Perl community as a whole.

The Perl 6 crew has had over a decade to get something useful put together. While Rakudo is mildly interesting, it isn't practical in the same sense that Perl 5 is. Given Perl 6's lack of traction, I think it's reasonable to consider it a dead effort at this point.

Perl 7, on the other hand, would be very usable right away. It would immediately reflect the changes that we've seen with modern Perl, but without the stigma associated with Perl 6.

At the very least, it would show that the Perl community is again moving in the right directly, with the emphasis on a language that is usable today, rather than on one that has floundered for many years now.

<comment><USER19> I strongly agree. I don't follow Perl, but I have long thought "I'll have a look when Perl 6 gets stable, not a lit off point looking at Perl 5, it's old and going to disappear soon anyway."

At this point, I suspect the gap which would be filled by Perl for me is already filled by python. But if I had a firm feeling that Perl 5/7 was not going to be eclipsed by Perl 6, I would be tempted to give it a try, mainly because I have found python is not a good replacement for grep/awk/find/xargs, and I suspect Perl might fit that niche better.

What is the best way to learn "modern Perl"? Or am I better off learning "old Perl"?

<comment><USER10> _What is the best way to learn "modern Perl"?_

I wrote a book called Modern Perl. It's freely available in electronic formats:

<http://onyxneon.com/books/modern_perl>

<comment><USER20> Going through the online version now. Very pragmatic writing style and wastes no time in getting to the point (Kernigan/Ritchie influence is seen).

Very nice. Thank you for sharing it with one and all.

</comment></comment></comment></comment><comment><USER21> The consensus forming in the comments to the post seemed to be around the idea of switching to a year-based versioning system, so Perl 2013. That sounds like a great idea to me.

<comment><USER22> Ugh, that seems terrible. It smacks of compromise, when what the perl community needs is a fresh set of ideas.

They need to name Perl 6 something else fix the image of Perl 5. Perl 6 should never have been named Perl anyway, it's a brand new language.

<comment> alex-g I think it was not clear, for a long time, just how divergent Perl 6 would turn out to be. If you look back (way back) at the original RFC process, most people were proposing fairly minor changes to the language; and it was billed as an opportunity to clean up a lot of cruft at a one-time compatibility cost. Rather like Python 3, in fact. But then it bit off more than it could chew, and as you say it is now envisaged as a new language sharing some Perl heritage.

<comment><USER22> That's true, however it's been clear for at least 4-5 years now that Perl 6 was a boondoggle.

From the outside the Perl community looks like its barely holding together.

<comment><USER3> From what I understand a lot of the Perl community mostly ignores Perl 6, and is focused on the Perl 5 base (as shown by the up-tick in development/changes on the core of Perl 5).

</comment></comment></comment></comment></comment><comment><USER23> why not have even numbered perls be the big language experiments and odd numbered perls be actual production ones with some of the goodness from the experiments baked in?</comment>


GPL/MIT licence, my software, and I'm not a lawyer... - <AUTHOR>

I'm entirely confused by how GPLv1,2,3, MIT, Apache and other licences impact my software. It's not that I haven't read them, like MIT's
>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so
But what if I'm using jQuery/jQueryUI plugins where they say "Oh we're under MIT and GPL," where jQuery's website says that I can simply pick the one I want.
I don't want to have to take my entire code base and have to release it because I goofed somewhere and something was under a licence.
My product essentially a CRM tool with a suite of additional tools for use in the industry, which will be packed as a LAMP server and sold as a subscription. It's not an open framework for doing cool things, but I'm using things like jQuery because it works really well. I'm using Ubuntu because it's solid, I'm running apache/mysql... Again, I'm not a lawyer, and you probably are not one either, but I have no experience with launched products with open source licences, and my fear that my entire product needs to be released to the world for people to modify scares me.
edit: Thanks for helping to clear this up everyone :) <comment><USER2> MIT/Apache/BSD can all be used in 'commercial/proprietary' code, and do not force you to released to the world or anyone else. You may have to say that you utilize their code, but you certainly don't have to release it to the world unless you want to.

The GPL has some requirements, and you need to be more careful with it.

<comment><AUTHOR> Any advice on how I should consider dual-licences? For example, I use the DataTables jQuery plugin. I would be willing to pay for a licence but I have no idea how to interpret their disclaimer:

>DataTables is dual licensed under the GPL v2 license or a BSD (3-point) license.

Does this mean I pick one to use? I'm having a hard time accepting/realizing that there is one product with my choice in licences.

<comment><USER3> Yes, you get to pick one. And no, you don't have to notify anyone, or do anything else than that. You pick the license of your choice, and use the plugin according to that license.

</comment></comment></comment><comment><USER3> jQuery is dual-licensed under the MIT and GPL licenses - you can choose whichever you want. If you want your code to be closed source, you want the MIT license.

You do not have to do anything about that - you can safely use it without any further thought.

What you need to pay attention to, is that while you CAN bundle GPL'd code with closed source code, you cannot use or derive from GPL'd code, unless your code is under the GPL too.

Thus, as long as you stick to MIT/Apache/BSD/LGPL libraries, you're safe. You can bundle GPL'd programs with your system, but you can't use and extend those sources, unless you release those parts under the GPL too.

<comment><AUTHOR> This makes sense now. Okay so just to confirm I'm on the same page...

If I write my own code from scratch, but I'm using the library from Jquery, it's running on apache, it connects to mysql, it does whatever, that's fine I'm using that software as part of the box I wish to re-sell because I didn't modify and re-sell that software, I'm selling the configuration of the server and my code?

<comment><USER3> That's pretty much correct.

I'm not a lawyer, either, mind you, but that has been my understanding =)</comment></comment></comment>


Rust 1.17 - <AUTHOR> https://blog.rust-lang.org/2017/04/27/Rust-1.17.html <comment><USER2> Hey, folks! I have never used Rust but all the buzz around it made me curious, so I may ask you to forgive my ignorance on the matter. I have a few honest questions about it and I'm pretty sure these questions were answered before, so feel free to point me to this resources, I'd appreciate very much.

First of all what's the point of Rust? OK, it's a systems language, but what does that even mean? You can write a system in any language right? Python is a scripting language and lots of people use it everyday to write systems. What problems is it trying to solve? Also how does it compare to Go? (I haven't used either one or another). It seems to me that both Go and Rust are mainly used by C/C++ folks that want a new shiny language that somehow resemble the syntax or structure or funcionality of the former and at the same time add some modern features (I might be totally wrong by presuming this).

From the perspective of other languages I know a little bit such as Ruby, Python or JS its syntax seems really bloated to me with all those specials symbols. Do you feel more productive writing software in it than in let's say JS? Please keep in mind that I really don't know Rust (nor I've never tried a statically-typed language) and I don't mean to offend anyone.

Thank you guys!

<comment><USER3> Because you can build things like:

* A faster grep ( [https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep) )

* A GPU accelerated terminal emulator ( [https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty) )

* A web browser ( [https://servo.org/](https://servo.org/) )

* A containerization system ( [https://github.com/tailhook/vagga](https://github.com/tailhook/vagga) )

* An operating system ( [https://github.com/redox-os/](https://github.com/redox-os/) )

* An extremely fast text editor ( [https://github.com/google/xi-editor](https://github.com/google/xi-editor) )

And be faster and safer than C/C++.

<comment><USER4> Is there a reason why all the above software cannot perform as "fast" or "safe" as Rust when written in other programming languages? After all, every program compiles down to machine code/assembly.

<comment><USER5> As soon as you need to be able to access low-level pointers for performance, you run into a problem: you can easily end up holding onto a reference to memory that's been cleared, or otherwise invalidated, by some other piece of code. This type of bug is insidious, and can easily be missed by the most stringent unit tests and even fuzzing. Of course you can try to get around this with abstractions on top, as every higher-level language does, and as you can do in C++ if you're willing to build reference-counted pointers around _absolutely_ everything... but these are not _zero-cost_ abstractions.

What Rust does is track reference lifetimes at compile time, giving you certainty about who can safely "own" or "borrow" memory in every single line of code, without any runtime pointer indirections or other slowdowns. The language is built around this feature at every level, with "lifetimes" being a syntactic construct at the level of type and mutability.

Imagine if you wanted to safely parse user-submitted JSON, maybe cache derived products from that JSON, and then make sure that when the input buffer is released, you weren't holding any handles into strings inside it. The only safe way to do that in any other language is to proactively copy the strings, or rigorously reference-count the input buffer. But Rust has your back here. If you use zero-copy deserialization from Serde ( [https://github.com/serde- rs/serde/releases/tag/v1.0.0](https://github.com/serde- rs/serde/releases/tag/v1.0.0) ) then the compiler will refuse to compile if you are using any of that data longer than the lifetime of the original buffer, and do so without needing to add any runtime bookkeeping.

Yes, it's an annoying language to learn because of that "fight with the borrow checker." I LOVE that the language designers and steering committee are so open to quality-of-life improvements for newbies, like that string warning. The language will only get easier to learn over time. It may never be what you use to make your next app, but if you're doing systems programming, it's the wave of the future.

<comment><USER6> So, I recently saw a study claiming that memory management-related issues constituted 25% of attacks, the rest was other vectors. I may be misremembering, but in any case, simply getting rid of memory faults does not get rid of all attack vectors.

Given this, I wonder if the (seemingly) added complexity of Rust could result in more attack surfaces of other kinds.

I don't know anything about Rust mind you.

</comment></comment></comment></comment></comment><comment><USER7> Hard to believe that this is the 17th minor release since Rust 1.0. :) Lots of good ergonomic improvements in this one, but for those of you who are itching for incremental compilation, a beta is now available for testing using the CARGO_INCREMENTAL environment variable: [https://internals.rust- lang.org/t/incremental-compilation-be...](https://internals.rust- lang.org/t/incremental-compilation-beta/4721)

<comment><USER8> Why is it so hard to believe? Don't they release a new version every month like clockwork?

<comment><USER7> It's every six weeks rather than every month, and the fact that it's like clockwork is what's so impressive! I've actually implored the Rust devs before to slow the release cycle for their own sake, it seems to be quite brutal. They must be masochists, because at least some of them have told me they enjoy it. :)

<comment><USER9> There's a lot of "not finished so wasn't included in this release" in the release notes.

With, say, a 12 week cycle instead of 6 weeks, I'm waiting 3 months for My feature to land in the next release, and I feel a lot more pressure to get it done _now_ than I would with a 6-week cycle where missing a release isn't a big deal.

Assuming the team has the release process we'll automated and cutting a release doesn't add a lot of work, then there's not much to lose with this cycle.

<comment><USER10> Missing a release should never be a worry. People can always wait.

having stable release with no regression > releasing fast

<comment><USER11> "should" is a nice ideal, but people will feel pressure, especially for tooling like a compiler that other teams depend on, where slipping schedule means slipping their schedule too. Shipping more often lessens this, by meaning a missed release costs much less time.

Empirically, Rust has done a pretty good job of shipping fast and not releasing regressions, so it seems like this isn't mutually exclusive.

<comment><USER12> I think that those few people who rely on the newest-possible features in the compiler will be compiling with a nightly build anyway (possibly pinning to a known-good version until the next release).

That's actually somewhat a meme within Rust, at least as far as my impression from the outside goes. There apparently were times where most interesting crates required some unfinished feature and thus a fairly recent nightly build of the compiler and/or Cargo. I believe that problem has decreased in the meantime, but as I said, I'm looking into Rust from the outside only and don't have much own experience.

<comment><USER11> According to the developer survey last year, most of the community is using a stable compiler in some form[0]. I can only imagine that the ratio has improved since then, especially with custom derives in 1.15. Additionally, I semiregularly see people say that they don't use nightly in production, even if they're using it for preview/experiments/testing.

[0]: [https://blog.rust-lang.org/2016/06/30/State-of-Rust- Survey-2...](https://blog.rust-lang.org/2016/06/30/State-of-Rust- Survey-2016.html#using-rust)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > String concatenation appends the string on the right to the string on the > left and may require reallocation.

I don't really know Rust, but isn't that weird? In most languages I know, I would expect for example Vector3(1, 2, 3) + Vector3(2, 3, 4) to return a brand new Vector3(3, 5, 7), with Vector3(1, 2, 3) unmodified? Unless I do vector1 += Vector3(2, 3,4), at which point I expect vector1 to be modified without creating a new vector?

Why doesn't rust create a new String and concatenates using this new owned String? I guess that's why beginners get it wrong - I would

<comment><AUTHOR> So I should preface this by saying that the Add impl was generally controversial and almost not even implemented, but ended up happening.

In a systems language, allocations matter. As such, people are generally really against hidden allocations in Rust, moreso than in other languages. This totally could have been done, but by requiring a String on the left, you are already in "this is heap allocated" land, and that is much more palpatable for Rust's audience.

<comment><USER14> >palpatable

=palpable + palatable. Pedantry aside though, I like the word. Maybe it describes something can be palpably palatable.

<comment><AUTHOR> Ha! Nice catch. Good thing I'm not like, a person who's paid to write words or anything...

<comment><USER15> You wrote a word! A _new_ word!

</comment></comment></comment></comment></comment><comment><USER16> I was interested in learning Rust as a safer alternative to C a few years back, and have been observing its progress from afar. I'm much less optimistic about it now, though I only have a layman's understanding of it. The language seems to be more cumbersome to write than many other languages due to its design choices. It may be safer, but not as "ergonomic" subjectively, which ultimately affects productivity. It's hard to think of a good reason to use it, other than the safety features.

<comment><USER17> I agree 100%. The Rust syntax is so different from C, C++, Go and Java that it's very difficult for me to use. I love the idea of Rust, but I wish the syntax was more similar to traditional languages. If it were, I think it would be a very easy transition for many of us.

<comment><USER18> A lot of the compromises made in Rust syntax were to make it much, much easier for the compiler to reduce passes to compile into a syntax tree.

There are certainly some things that should just be obvious now, though. Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol, using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) And the syntax for lifetimes is horrible, with the 'a and the fact that in practice its about as significant as naming parameters in a C++ function definition in a header (ie, pointless - the words are discarded by the compiler every time).

And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam.

Given all that, Rust is still, IMO, the best programming language we have right now for native performance, period. We can criticize what we don't like but we should at least agree its the best we have.

<comment><USER19> > Using the C++ namespace separator of :: is just ludicrously obtuse for an > extremely common symbol

Obtuse? It's sort of common. Multiple languages use it. Personally I like the namespace separator being distinct from the object/struct element accessor. At least they didn't copy PHP in using backspace...

> using the & for refs is archaic (I mean... you could have just called it a > ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to > foo.)

Please, let's not have more cases where things look like functions but aren't. Functions should look like functions. Operators should look like operators. You might have to learn a small set of operators for a new language. This is front-loading some confusion and learning pain for ease of use later. It may make the language harder to read _for people that don 't know the language_, but anyone reading the source code with the aim to make some changes should probably know the operators at least. I'm not sure giving it a slightly more expressive name but making it look like something else actually makes life easier for those people.

> And I certainly would have argued for whitespace significance, at least as > an option, instead of classic semicolon spam.

 _Optional_ whitespace significance? That sounds like a recipe for disaster, IMO. I can see a case for one or the other, but mixing of modes like that when it deals with something that is by nature somewhat invisible (or meta), seems prone to problems.

Also, examining why Python has had problems with functional style workhorses like map might shed some light on the negative aspects of whitespace dependent syntax.

<comment><USER18> Commonality doesn't make a shift-accessible character twice in a row less obtuse. It is like if < and > were the bitwise shifts and >> and << were the logical - it would make no sense because the more common behavior was using more characters.

Of all the glyphs used in the language, :: is probably in the top 5 for frequency of use (probably higher than even * in Rust, considering the infrequency of pointer usage and that multiplication isn't _that_ common an operation in general code) but uses two glyphs instead of one.

It would have required different design constraints starting out to figure which glyph would be best suited instead of ::, but :: is still really ugly in all the languages that use it when its such a common symbol. I wouldn't argue overloading . is right, but I'm having a hard time seeing why a single colon doesn't work - foo:bar:baz. Maybe the parser finds scoping and explicit type names on definitions (ie let foo: i64 or in function definitions) require too many passes to distinguish?

<comment><USER19> Valid points. A single colon would suffice, but I suspect in C++ they wanted something a bit more distinct from the semicolon. For Rust, I imagine at least part of the reasoning was keeping with what was familiar wit h C++, and after that the type names probably did make it complex, if not intractable (without reserving specific names).

</comment></comment></comment></comment></comment></comment><comment><USER20> Tried some programs that used to work:

First program:

        src/main.rs:65:11: 65:19 error: no method named `join` found for type `collections::vec::Vec<&str>` in the current scope
        src/main.rs:65     sline.join("")                              // return string

OK, what happened to ".join", and who had the great idea of taking it out?

Second program:

        $ cargo build
        An unknown error occurred

        To learn more, run the command again with --verbose.

OK, must rerun because of useless message.

        $ cargo --verbose build
        Invalid arguments.

        Usage:
            cargo <command> [<args>...]
            cargo [options]

Note that the "Usage" message doesn't say where to put the options if there's a commmand. So we have to guess:

        $ cargo build --verbose
        Failed to parse registry's information for: chrono

        Caused by:
          the given version requirement is invalid

The version requirement in the cargo.toml file under [dependencies] is

        chrono="*"

which, according to this manual [1] is valid.

I used to like Rust, but after years of stuff breaking with each new release, I don't use it for anything serious.

[1] [http://doc.crates.io/specifying- dependencies.html](http://doc.crates.io/specifying-dependencies.html)

<comment><USER21> Rust has not removed an API since 1.0. Your code is extremely old and predates stability.

Yes, star dependencies were removed like a year ago, for semver issues. They went through multiple release cycles of warnings.

<comment><USER20> _Rust has not removed an API since 1.0. Your code is extremely old and predates stability._

That code worked through at least Rust 1.2. So, yes, Rust _has_ removed an API since 1.0. That code was compiling in December 2016.

 _Yes, star dependencies were removed like a year ago, for semver issues. They went through multiple release cycles of warnings._

From the Cargo manual [1]:

        Wildcard requirements

        Wildcard requirements allow for any version where the wildcard is positioned.

        *, 1.* and 1.2.* are examples of wildcard requirements.

        * := >=0.0.0
        1.* := >=1.0.0 <2.0.0
        1.2.* := >=1.2.0 <1.3.0

Apparently, nobody bothered to update the manual after removing the feature.

[1] [http://doc.crates.io/specifying- dependencies.html](http://doc.crates.io/specifying-dependencies.html)

<comment><AUTHOR> To be clear, you can use star dependencies locally, but pushing a new crate to `crates.io` will reject crates that have star dependencies. So in some senses this is still accurate, but it's missing the crates.io interaction.

This means I don't understand how you got your error. For example:

      > cat .\Cargo.toml
      [package]
      name = "star"
      version = "0.1.0"
      authors = ["steveklabnik <firstname.lastname@example.com>"]

      [dependencies]
      semver="*"
      > cargo build
          Updating registry `https://github.com/rust-lang/crates.io-index`
         Compiling semver-parser v0.7.0
         Compiling semver v0.6.0
         Compiling star v0.1.0 (file:///C:/Users/steve/tmp/star)
          Finished dev [unoptimized + debuginfo] target(s) in 5.24 secs

I've filed [https://github.com/rust- lang/cargo/issues/3971](https://github.com/rust-lang/cargo/issues/3971)

I'm also not sure how you got your `join` error,

        let sline: Vec<&str> = vec![];
        sline.join("");

seems to compile just fine for me. Hard to tell without seeing your other code, I guess...

<comment><USER20> The Cargo problem turns out to be a known incompatibility between the version of Cargo which ships with Ubuntu 16.04 LTS and later version of Rust.[1][2][3] "Old versions of cargo cannot install any version of a crate that has a version with a prelease string". It's not the user's .toml file that's the problem; it's an internal dependency within the crate that's breaking Cargo.

It's necessary to run Rust's version of Cargo, not Ubuntu's, when using Rust. Due to a path problem, I was using Ubuntu's older versions of Rust and Cargo, but with libraries from the new Rust installation.

[1] [https://users.rust-lang.org/t/crates-io-compatibility- with-o...](https://users.rust-lang.org/t/crates-io-compatibility-with-old- cargo/9127/19) [2] [https://github.com/rust- lang/crates.io/issues/584](https://github.com/rust-lang/crates.io/issues/584) [3] [https://github.com/rust-lang/cargo/issues/3763](https://github.com/rust- lang/cargo/issues/3763)

<comment><AUTHOR> Ah yes. This one is indirectly my fault, as I maintain the semver parsing library, and that included the bug. Sorry about that :(

</comment></comment></comment></comment></comment></comment><comment><USER22> What's the Rust IDE story looking like these days? For a language like Rust (or almost any language really) the best way I've generally found to learn them is to get a good auto-completing IDE which solves for "what's the standard library and what can I do?" and let's me focus on getting the syntax and design methodology right.

Till now Rust hasn't had that. Is there a decent stack?

<comment><USER23> IntelliJ with the Rust plugin. Pretty awesome, and always improving.

The maintainers are great, and welcome contributions.

</comment></comment><comment><USER24> I wish they include language service in the stable branch soon.

<comment><USER25> You mean the autocompletion server?

<comment><USER24> I think they call it officially language service.

<comment><AUTHOR> Yes. It will happen; it was ready to land on nightly just before the branch, but was held off so that we could have the full, usual, "spends six weeks in nightly, then beta, then stable" situation rather than almost immediately jumping into beta. This means it'll hit stable in two releases, 1.19, as long as nothing goes wrong.

<comment><USER7> And note that if you're using rustup to manage your toolchain, you can now use it to install and manage RLS for you as well: [http://www.jonathanturner.org/2017/04/rls-now-in- nightly.md....](http://www.jonathanturner.org/2017/04/rls-now-in- nightly.md.html)

<comment><USER26> rustup is really great. First I was a little bit curious if the updates every 6 weeks would ruin my dev environment since I need to update every time. but rustup makes that a breeze. `rustup update`. that's what to do when there is a new version, nothing more I don't know that any other compilers/interpreter that has the same ease of use. except maybe sbt, but that can't self update. (P.S.: Awesome talk about rust on scaladays: [https://www.youtube.com/watch?v=C6dNx9pY7p8&index=2&list=PLL...](https://www.youtube.com/watch?v=C6dNx9pY7p8&index=2&list=PLLMLOC3WM2r5Ei2mnSHCD- ZD04AXovttL))

</comment></comment></comment></comment></comment></comment><comment><USER27> I still get excited every time there is a new Rust release :D

> When using Cargo's build scripts, you must set the location of the script in > your Cargo.toml. However, the vast majority of people wrote build = > "build.rs", using a build.rs file in the root of their project. This > convention is now encoded into Cargo, and will be assumed if build.rs > exists.

This is what I love about Rust's development. Rather than the developers just using their own ideas about how the Rust ecosystem will use a system, they instead wait for the ecosystem to come up with its own conventions. Once those conventions are organically established, they fold them into the official Rust tools.

It's the equivalent of finding product market fit. More times than not our ideas about what the market (in this case, Rust users) wants will be wrong. Better to just adapt to the market.

That's enough praise for now, so ... how about something not so great about Rust? I started building a password manager in Rust, because I'm not satisfied with the current options for password managers. This will be my first Rust project with a GUI and ... so far it's been very painful.

I've looked at GUI in Rust in the past but never tinkered because there were never any good libraries available. It's now Rust 1.17 and there are still no good options. For this project I landed on gtk-rs, but it's a nightmare of Rc's, RefCells, and borrow_mut just to get even the simplest UI working.

I'm not sure yet if this is an issue endemic to gtk-rs, or if Rc's and RefCells are a necessary evil in Rust whenever GUIs are involved. It's a bit hard to reason about ownership in this case, where your callbacks can be called at any time, and if they modify the UI that may trigger another, now nested callback, which may trigger yet another callback, etc. So it requires a lot of brain power to think about every borrow and what the lifetime should be.

Without thinking too much about it, I feel like things could be better. If Rust was driving the UI loop, and if the callbacks didn't have 'static lifetimes, then it might be possible shove the UI into an isolated struct and not have to deal with too many ownership and lifetime issues. But again, I haven't tried to think it through and it's irrelevant because there's no mature GUI library in Rust that would allow that.

Of course, none of that reflects on Rust itself, nor on the Rust developers. This is a third-party issue; it boils down to a lack of good GUI libraries. That's hardly surprising given how new Rust is.

For now, I'm blundering forward and just hacking together whatever mess of code works. The critical parts of the password manager are in a separate Rust library with unit tests, and the password database will have history/versioning on every entry. So I ultimately don't care if the UI code is ugly and hacked together. It's just more time consuming than it probably has to be.

<comment><AUTHOR> You will be happy to hear that there was a GNOME Hackfest in Mexico recently, attended by several Rust team members. Some productive plans were sketched out for the future; as the GNOME project adopts Rust more and more, I expect this to get easier and easier.

You also might like [https://github.com/antoyo/relm](https://github.com/antoyo/relm)

<comment><USER27> Thank you for the update. Relm looks promising!

By the way, I love that Rust devs stalk HN and read my rants :P

</comment></comment></comment><comment><USER28> This thread convinced me that my next language to learn will be Rust (coming from a C/C++/Python career path).

Can somebody point out a list of resources to start on Rust? Do we already have a good IDE with proper autocomplete support?

Thank you!

<comment><USER29> The canonical source to learn is The Book: [https://doc.rust- lang.org/book/](https://doc.rust-lang.org/book/)

However, a second edition of the book is in the works and a lot of people have said good things about it. I think enough of it is filled out to be a good starting point: [https://doc.rust-lang.org/nightly/book/second- edition/](https://doc.rust-lang.org/nightly/book/second-edition/)

<comment><USER28> Thanks! I'll burn my sushi to this!

</comment></comment></comment><comment><USER30> "If you want to understand Rust replace all occurrences of 'Rust' with 'The Thing'"

<comment><USER31> Was your joke any deeper than a superficial reading of it? I also can't tell if it was lighthearted or deeply malicious.

<comment><USER30> Unreserved malice and nigh-fathomless depth. I'd say more but I'm in the midst of designing a language which can precisely and safely express both concepts.

<comment><USER31> A shame everyone is downvoting this comment. But you are honest then your first comment deserves as many downvotes as possible.

Since you are in charge of this new language I won't be using it. The Rust community has largely figured out how to get work done with minimal malice and a language that actually exists.

<comment><USER30> In my language, it will be possible to express an impossible number of downvotes, correcting what is perhaps the most glaring design flaw of Arc.</comment></comment></comment></comment></comment>


Mobile video making finally democratized by new video app MV - <AUTHOR> http://www.mv.com

<comment><AUTHOR> If you were embarrassed posting boring video selfies to Instagram or Vine, you should really reshoot it with MV. It's now in Beta on mv.com.

</comment><comment><USER2> What a magic app! I really love it!

</comment><comment><USER3> can't think anything higher, really awesome app

</comment><comment><USER4> Really amazing app!

</comment><comment><USER5> cool!

</comment><comment><USER6> cool

</comment><comment><USER7> cool</comment>


Rwanda just released the first smartphone made entirely in Africa - <AUTHOR> https://www.fastcompany.com/90414915/rwandas-mara-x-z-are-1st-smartphones-made-fully-in-africa <comment><USER2> I was in Rwanda this time last year. After visiting ~30 African countries by that point I can say that it's an extremely refreshing change.

There is a bustling tech sector in Kigali - they're making iPhone apps, designing and building hardware, etc. etc. There is a huge community of entrepreneurial younger people. People are extremely well educated, friendly and kind. I never saw a single piece of trash in the entire country.

I felt as safe riding moto taxis around in the dark in Kigali as I do in any Canadian city.

<comment><USER3> FYI for those unaware, grecy is the guy who recently completed a >50000 mile Africa expedition[1]. This guy knows Africa. It's nice to hear that Rwanda is doing well.

[1] [http://theroadchoseme.com](http://theroadchoseme.com)

<comment><USER4> Wow. The coastline of Africa is 18,950 miles (30,500 km), so That's like looping around the content nearly 3 times.

Here's what I found on that site:

> _I'm doing an "Ask Me Anything" on Reddit right now. Come on over to > Reddit.com and ask me any question you have about my three year, 54,000 mile > and 35 country expedition around Africa._

 _It's all on the table – safety, money, health, budget, visas, route, people, animals, the Jeep._

[https://www.reddit.com/r/IAmA/comments/brhbst/i_drove_my_jee...](https://www.reddit.com/r/IAmA/comments/brhbst/i_drove_my_jeep_around_africa_reddit_said_i_would/)

<comment><USER5> Or he just looped around the coastline once at a tighter resolution than your source of 30,500 km

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

(Also thanks for the AMA link)

<comment><USER6> The coastline paradox is cute, but any route using coastal roads will be shorter than any reasonable coastline estimate, for obvious reasons.

<comment><USER7> Plus the "resolution" of the coast is limited by the size of humans.

The coastline paradox is much more of a measurement problem then a physical one.

</comment></comment></comment></comment></comment></comment><comment><USER8> They say they don't do just assembly but I guess they don't make their own chips either so what is the difference vs assembly?

<comment><USER9> To be honest, I think China is the only country that can fit the strict definition of "entirely" made in".

So I'm happy enough to give credit to rwanda for assembling the motherboard component by component.

<comment><USER10> If we're talking about smartphones, I think South Korea and Taiwan would fit the bill.

</comment></comment></comment><comment><USER11> That logo looks so nice. I literally want one just for how nice their brand looks. Why can't other electronics brands look that nice?

<comment><USER12> Not sure what you're talking about, the Apple logo is pretty great, and has multiple meanings.

<comment><USER11> Maybe, but it doesn't look good. It's just an apple with a bite taken out of it. It's whitewashed and bland. No character to it.

</comment></comment></comment><comment><USER13> The phones look good (at least from the parts pictured). I wonder if they can bring a higher price than Chinese competitors with a design advantage.

<comment><USER14> IMHO The image looks rendered..

<comment><USER15> According to the website, you can order one now with a 3-5 day delivery (presumably more if destination is outside of Rwanda).

[https://maraphones.com/product/mara-x/](https://maraphones.com/product/mara-x/)

<comment><USER16> I just bought one and am promised delivery to the Midwest by 10/15 (~$25 shipping.)

<comment><USER17> Site must be getting hammered. I can't get it to come up.

</comment></comment></comment></comment></comment><comment><USER18> After my deep dive into reading about the Zipline Drone company (who first deployed at-scale in Rwanda and now serve virtually the entire country with rapid, fully electric airborne blood and medical product delivery), I learned just how well Rwanda is doing economically. Very vibrant, indeed.

They are led by a paternalistic figure who helped stop the genocide and has high support in the population. It's not as democratic as I would like, and the Rwandan meddling in Congo isn't exactly clean, but trajectory of Rwanda to middle income country status is commendable. I worry about Kagame's admiration for the Chinese model of development, though. I guess an advantage of Africa versus China is the nations are more numerous and so power is more disperse (possible exception: Nigeria by the end of the century). I hope a gradual trajectory toward prosperity for all, freedom, and peace take place on this continent.

<comment><USER19> He has support because if you voice against him you end up in prison, jail or exile.

I'm not saying he didn't do great things to stop the genocide in 94, but the country is the way it is because he rules with an iron fist.

</comment></comment><comment><USER20> Do they have modern semiconductor fabrication capabilities at all?

<comment><USER21> I'm pretty sure they're importing the semiconductors, but manufacturing the PCBs

</comment></comment><comment><USER22> Made ENTIRELY in Africa except SoC, memory modules, display and pretty much any other component...

Only continent where they make ENTIRELY phones is Asia.

</comment><comment><USER23> Largely PR, on the ground things are different, Rwanda is like china</comment>


Poorsplaining: What It's Really Like to Be Poor in America - <AUTHOR> http://www.businessweek.com/articles/2014-10-02/what-being-poor-is-really-like-linda-tirados-hand-to-mouth

<comment><AUTHOR> Also this original essay on huff post [http://www.huffingtonpost.com/linda- tirado/why-poor-peoples-...](http://www.huffingtonpost.com/linda-tirado/why- poor-peoples-bad-decisions-make-perfect-sense_b_4326233.html)

And the book (Hand to Mouth) on Amazon: [http://www.amazon.com/Hand-Mouth- Living-Bootstrap-America/dp...](http://www.amazon.com/Hand-Mouth-Living- Bootstrap-America/dp/B00JPR5JA0/)</comment>


US suspects listening devices in Washington - <AUTHOR> https://www.apnews.com/d716aac4ad744b4cae3c6b13dce12d7e <comment><USER2> These are taking advantage of poor overall security in the cell phone network infrastructure; if phones cryptographically authenticated their base stations, it would be difficult or impossible. It's not entirely clear why more effort hasn't been put into securing this, but a likely hypothesis is that certain law enforcement agencies want it to be insecure, so that they can use it for domestic investigations. Now that the US finds itself on unfriendly terms with foreign spy agencies, this has become a serious problem.

</comment><comment><USER3> That is a good thing. Either US makes GSM networks secure for everyone or they'll have to let other countries spy on their citizens too.</comment>


Proposing a new funding model for open source - <AUTHOR> https://vriad.com/essays/a-new-funding-model-for-open-source <comment><USER2> This makes alot of sense. I would be surprised if it didn't happen at some point considering how impactful patreon style funding has been for other small projects.

I do worry some that this might create an incentive for businesspeople to agressively and unnecessarily fork popular projects in hopes of skimming money from the actual developers. So far app spam hasn't been a big problem because there hasn't been any money in it.

</comment><comment><USER3> This was something npm was actually thinking about: [https://twitter.com/izs/status/755802779432562688](https://twitter.com/izs/status/755802779432562688)

</comment><comment><USER4> ongoing comments, [https://news.ycombinator.com/item?id=23981563](https://news.ycombinator.com/item?id=23981563)</comment>


Functional Programming? Don't Even Bother, It's a Silly Toy - <AUTHOR> https://medium.com/@ilyasz/fp-toy-7f52ea0a947e <comment><USER2> The author is often found bashing OOP and praising FP. It's his hobby horse. Every time he needs a few clicks on his blog, up comes the 'OOP is a disaster!'.

It's a wonder the world has managed to survive with the billions of lines of OOP out in the wild, running the world!

<comment><USER3> Yeah, if it was FP it would be millions instead of billions.

The point being, there is nothing special about oops or any other new concept which resembles poorly defined real world semantics. Math, patterns are the masters here. And everything should be amenable to computation ie things like reflection should be part of the language and not treated like a carefully handled baby. As soon as that is met, everything naturally collapses into repeating patterns. And we can apply powerful theorems of math we have accumulated over centuries to the work at hand

</comment></comment><comment><USER4> >The so-called "functional" programming has no proper mechanisms of abstraction since it is based on mathematics (which obviously is inferior and has no applications in the real world apart from the academia).

Amazingly, this article appears to be serious.

<comment><USER5> It's not.

> Declarative code, on the other hand, is too concise, and erroneously makes > the developers focus on the less important things, like business logic.

\-----

>It takes at least 20–30 years to get good with OOP, even then most people with 30 years of OOP experience haven't truly mastered it. The learning path is rough, filled with uncertainty. A lifetime of learning awaits the OOP developer, how exciting is that!

> What about the poor functional programmers? Unfortunately, there's not much > to learn. I personally have taught a few junior developers functional > programming in JavaScript, and they became really good at it in about half a > year. They simply had to understand a few basic concepts and then learned to > apply them pretty quickly. Where's the thrill of lifetime learning? I > wouldn't envy them.

<comment><USER4> Off to check the batteries in my satire meter.</comment></comment></comment>


From Failure to Fehler - <AUTHOR> https://boats.gitlab.io/blog/post/failure-to-fehler/ <comment><USER2> > In general, for most libraries I would recommend just manually creating > error types and implementing the Error trait for them. If this is too > complicated, consider why your API is throwing so many different kinds of > errors, and whether your library is doing too many things.

It may not be obvious but this is a highly contrarian take at the moment. It's also probably the right approach in many cases.</comment>