Ways to do load balancing wrong - <AUTHOR> http://queue.acm.org/detail.cfm?id=3028689 <comment><USER2> As someone who has worked at high scale (1,000+ load balanced servers), this is a nice "primer" I'd share with a new(er) engineer, or someone who has not worked in a horizontally scaled environment.

A few things I'll point out in addition to this article:

[1] I've found I greatly prefer databases that handle the resiliency and horizontal scalability natively (or natively in their respective client libraries). DBs natively scaling has been one of the greatest advancements in web technologies during my career, and I'd really recommend taking a look at the technologies like Riak & Cassandra for inspiration.

[2] When scaling horizontally with load balancing, connection pooling becomes something to always pay attention to. If you have 1,000 servers, and 100 database instances, you likely don't want 100,000 active connections. Focusing on things like intra-zone preferences for servers (Server A prefers all DBs in its own rack, "zone", or "region") can be a real headache saver as you scale up.

[3] Capacity planning is always key. What are you trying to plan for? Do you want to survive an entire AWS zone outage? Do you want to be able to survive a region outage? Do you worry about single servers going down, and if something "bigger" happens you'll just eat the downtime? Make sure you and your business stakeholders agree on what "resiliency" looks like to your business. It'll help you balance cost and downtime appropriately.

[4] Remember when you're looking at spare capacity that you take into account the situation where a cache layer suffers an outage. If you have to fall back to the primary source of data, and it potentially is also suffering from degradation of service, what sort of capacity will you have?

<comment><USER3> There needs to be more publications covering this, because I don't see this becoming common knowledge or practiced very often.

Then there's the modern design decisions that make some of these subjects taboo, like "you should never cache anything" and "a single node can handle a million concurrent connections so why worry" and "let's make all our machines use 99% of their capacity with containers because it's more efficient and hope we can deploy standbys before the database queues too much and blows the entire stack up". With the emergence of the pseudo-Devops cargo cult, people who like using JavaScript for server backend code are designing infrastructure they've never administered before. (sorry for the rant)

There was a really great paper published a few years ago that was basically an Everything You Need To Know To Run Large Scale Enterprise Systems type paper. I can never find it when these types of threads come up, but it was dozens of pages long and really in-depth.

<comment><USER4> The SRE Book ([http://shop.oreilly.com/product/0636920041528.do](http://shop.oreilly.com/product/0636920041528.do)) has a number of chapters on load balancing that are well worth reading.

One thing that the book covers that I think this article glossed over was the fact that in sufficiently large systems there's never a single "load balancer" \- instead there's many layers of load balancing systems at different levels of the stack. E.g.:

DNS load balancing -> high capacity network-level load balancing -> shared reverse HTTP proxy -> application server -> database (with a "load balancer" internal to the application server load balancing among DB replicas).

<comment><USER5> They mention there are different applications for load balancers, and then use one or two examples. But their main points are the most important ones: if you don't know what you're using it for, it might be worthless.

The SRE book seems to only have a couple sub-chapters on it, so I would recommend looking up white papers and best practices for your particular application of load balancing. Safari Books has over 17,000 matches for "load balancing" in its library, for example, and F5 has 12 white papers on it just for their products.

</comment></comment></comment></comment><comment><USER6> Is the discussion of "load balancers for resilience vs scale" even relevant in a cloud-enabled world? Just use an AWS Elastic Load Balancer with an Auto Scale Group, plus Cloudwatch alarms for monitoring and you get the best of all worlds... :-)

</comment><comment><USER7> Load balancing strategies are also important. For a service that receives requests that take different amounts of effort to fulfill, weighted least conns is almost certainly better than random or round robin.

</comment><comment><USER8> How does something like this end up published by the acm? Is this a special publication that isn't related to research at all?

I don't mean to sound harsh, but there was nothing in this article even close to novel in an academic sense, and none of it is even new field knowledge if you've spent any non-trivial time around load balancers. Perhaps my notions of what the acm publishes are wrong...

Make no mistake, it's a good article for things to look out for if you're getting into load balancing. It's just nothing new if you are already experienced in the field.

<comment><USER9> ACM is 'advancing computing as a science and profession'. It's not just for the Academy. One of the targets of modern ACM is exactly that of closing the gap between research and practice.

<comment><USER8> Doesn't such a vague definition just make it a blog platform for anything CS related? Nothing in this article was even new to practice.

<comment><USER9> Well, yes, ACM itself is quite broad, with many focused groups as well as other, more divulgative, sections.

But ACM Queue it's not "a blog platform", more like a magazine. Something is new, something it's a recap, something is an opinion.</comment></comment></comment></comment>


Contempt Culture - <AUTHOR> https://blog.aurynn.com/2015/12/16-contempt-culture <comment><USER2> There is an interesting theory that I sometimes read about. It states that the more contempt and animosity that a group shows to outsiders, the more cooperative and cohesive the group becomes.

I think that if you really want to overcome the language bias you need to first address and make people aware that initially there may be some instability in group cohesion. It may also be helpful to learn the fine art of self-deprecating humor.</comment>


Ask HN: Experience Using Stripe Atlas to Incorporate - <AUTHOR> <comment><USER2> I haven't used Stripe Atlas personally, but I did see this the other day...[https://news.ycombinator.com/item?id=21952809](https://news.ycombinator.com/item?id=21952809)

One other thing to note is that besides the initial $500 setup fee, they additionally require you to pay $100 a year + $25 a month for bank account maintenance with SVB.

A few other key differences can be found here (side note I own Blook :P) [https://blook.io/stripe-atlas-alternative](https://blook.io/stripe-atlas- alternative)

<comment><USER3> Thanks for doing this, was actually looking to use Stripe Atlas for my side project but I'll support a fellow founder!

Being $400+ less expensive with more options also helps lol

</comment></comment><comment><USER4> Had a great experience. Their GCP credits made all the difference too.

<comment><USER5> how long do they last?/how much do they give you?</comment></comment>


Ask HN: Have tech interviews gotten harder? - <AUTHOR> I just started job searching again for the first time in a few years and it seems like every problem has been "bumped down" one degree. So medium/difficult questions like the classic "most profit buy/sell stock" are now classified as easy, and the "hard" questions are close to impossible to solve within 60 minutes unless you specifically prepped for it.<p>Have tech companies made their tests more rigorous (in response to books and sites dedicated to passing interviews) or am I just out of practice? <comment><USER2> They have gotten harder due to the feedback loop induced by having such a poor proxy for fitness be so ubiquitous.</comment>


Ask HN: Why No Discussion on the Grace Murray Hopper Academy - <AUTHOR> http://gracehopper.com/careers appears in the HN listings but has not links for flags, discussion, and so forth.  Why? <comment><USER2> The listing implies that Grace Murray Hopper Academy is now in YC. Since there is no record of this, I assume they are a YC W15 nonprofit.

<comment><AUTHOR> And YC W15 nonprofits are not to be discussed on Hacker News?

<comment><USER2> Job ads in general have comments disabled. (Since there's no point, really)

</comment></comment></comment><comment><USER3> It's a paid ad.</comment>


Building AdSense & Amazon Website Experiment - <AUTHOR> http://www.kreci.net/web-development/adsense-amazon-site/

<comment><USER2> This model seems pretty common for content/Adsense-based websites. I've always been somewhat skeptical of the actual ability to produce profit in the long run - how much value are you actually adding to the Internet?

I'm definitely interested to see where it goes and how long it takes to generate reasonable Adsense revenues (e.g. $1+ a day).

My only concern is that this isn't really a true experiment if you post it on HN and market it on your blog. Don't you think these websites (e.g. reddit, HN) could cross-contaminate what you're trying to determine?

</comment><comment><USER3> Did you just admit to paying for backlinks? Isn't that a good way to get penalized in search rankings by Google?

</comment><comment><USER4> OK, maybe you should Google "farmer update" and read a bit about that. Then check your backlinks. I could not find those 500 backlinks you bought. All I can see are 59 external links from 3 unique domains. So what have you done with them them when you got them?

</comment><comment><USER5> Yes this is exactly what the world needs. More websites with garbage content. You can build something small _and useful_ , you know.

<comment><USER6> In my -very limited- experience, the best way to make money with AdSense and/or Amazon is by actually making garbage websites. Nothing better to make a visitor click on an ad than a _fugly_ website.

</comment></comment><comment><USER7> Hi kreci, so as I understand it, you are basically build a niche content farm? You would buy rewritten articles for $1.75 and then try to push them to Google using seo techniques so Adsense and Amazon aff links will earn more than the expenses are.

I'd like to ask what are the criteria to find out "a niche that has enough search traffic and earning potential." You just compare the numbers with other websites you own?

</comment><comment><USER8> Hmm. What's nice about this; there are thousands of these kinds of posts online and many without affiliate links hooked up :)

</comment><comment><USER9> awesome idea, nice execution so far - keep us updated on your progress!

<comment><AUTHOR> Thanks. I will post updates once per few weeks.

</comment></comment><comment><USER10> Why does this belong on HN again?

</comment><comment><AUTHOR> Comments are welcome... =)

<comment><USER11> Have you ever considered using ScrapeBox or Xrumer for consistently building backlinks over a period of time? A short burst of backlinks and then nada allegedly looks suspicious to Google.

<comment><USER12> So, comment spam tools? That's deep into the realm of "black-hat SEO".

<comment><USER11> That it is. BH SEO is (unfortunately) extremely effective.

If you're content farming by rewriting other people's content, you're not providing much additional value to the Internet at large and you're, at most, a few steps away from being a black hat as it is.

</comment></comment></comment></comment><comment><USER13> Very clean, attractive design.

This might almost be worth an "Ask HN" but where does a guy starting a lean blog presence find useful attractive (free? cheap?) images that are topical? You seem to have done really well on that: are they from the manufacturer?

In either case: how do you determine (without long legal chase for just one image-use) willingness of original owner to have their product images used?</comment>


The Tinkerings of Robert Noyce (1983) - <AUTHOR> https://www.esquire.com/news-politics/a12149389/robert-noyce-tom-wolfe/ <comment><USER2> I am surprised that there are so few hacker comments here. The story sends me the goosebumps and its a keeper -- Grinnell College in Iowa where the Silicon Valley revolution really began, what really made landing on the moon possible, and this Robert Noyce quote in Wiki:

In his last interview, Noyce was asked what he would do if he were "emperor" of the United States. He said that he would, among other things, "…make sure we are preparing our next generation to flourish in a high-tech age. And that means education of the lowest and the poorest, as well as at the graduate school level."

<comment><USER3> Few comments on the many previous submissions too: [https://hn.algolia.com/?query=The%20Tinkerings%20of%20Robert...](https://hn.algolia.com/?query=The%20Tinkerings%20of%20Robert%20Noyce&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0).

[https://news.ycombinator.com/item?id=8133479](https://news.ycombinator.com/item?id=8133479) has a few, and [https://news.ycombinator.com/item?id=14650795](https://news.ycombinator.com/item?id=14650795) has a good one.

<comment><AUTHOR> Good catch - sorry for the dupe. I searched before submitting but only searched for the URL, not the title, so I only found submissions with no votes or discussion.

<comment><USER3> It's not a dupe because it hasn't had a significant discussion in the last year—or in any year! This is in the FAQ: [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html).

</comment></comment></comment></comment><comment><USER4> This is in general a great BBC documentary from 1978, well worth watching in full. It might be the only time Intel permitted cameras to record the production process of silicon chips?

[https://www.youtube.com/watch?v=HW5Fvk8FNOQ](https://www.youtube.com/watch?v=HW5Fvk8FNOQ)

Anyway it features Robert Noyce at around 9 mins 20 secs in.

Edit: Thanks guiambros for pointing out the stupid region restriction. This link should work for people outside the UK: [https://www.dailymotion.com/video/x64ng4h](https://www.dailymotion.com/video/x64ng4h)

<comment><USER5> Uh? " _This video contains content from Crowley Media, who has blocked it in your country on copyright grounds._ "

Anyone having the same problem? (I'm in NY)

EDIT: ok, I got it. This is from BBC, so likely only available in the UK. I found a copy on their site [1], and the player is more explicit - " _BBC iPlayer only works in the UK. Sorry, it's due to rights issues._ " Need to watch through VPN...

EDIT 2: Here's one that works [2], without VPN.

[1] [https://www.bbc.co.uk/iplayer/episode/p01z4rrj/horizon-19771...](https://www.bbc.co.uk/iplayer/episode/p01z4rrj/horizon-19771978-now- the-chips-are-down)

[2] [https://archive.org/details/BBCHorizon19771978NowTheChipsAre...](https://archive.org/details/BBCHorizon19771978NowTheChipsAreDown)

<comment><USER6> Actually, it's being blocked in these countries

 _' MX','GY','CL','BO','VE','PY','EC','CO','US','CA','UY','BR','PE','GF','AR'_

No idea why those, but that's their policy in YouTube

</comment></comment></comment><comment><USER7> Interestingly, Robert Noyce thought this article was a bit of a tall tale by Tom Wolfe. Here's a quote by him from 1984:

> It's interesting to me to see what an enormous amount of publicity the > microchip has gotten recently including that article of Tom Wolfe's. > Incidentally, on that article of Tom Wolfe's, I do want to point out that > Tom Wolfe is first of all a novelist. And only secondarily is he a historian > but everything that appears in print of course is true as you've all > learned. Particularly if you ever read something that you know something > about.

Source: [https://youtu.be/AfxUq_QrpyY?t=2m20s](https://youtu.be/AfxUq_QrpyY?t=2m20s)

</comment><comment><USER8> A few interesting takeaways from skimming the article:

* Shockley was ahead of his time with peer-ranking and transparent salaries

* Ageism and zero work-life balance has been a feature of the Silicon Valley landscape since its inception

* In the 1950's, the reference point for what a youthful, technically innovative, highly entrepreneurial industry would look like was the automobile industry - which would not at all be obvious to a modern reader who didn't know the early history of automobiles (I know the piece was written in the 80's, but for that part Wolfe is taking the perspective of someone in the burgeoning Silicon Valley of the 50's-60s)

</comment><comment><USER9> The PBS American Experience episode, "Silicon Valley," is an excellent retelling of the Noyce-Fairchild-Intel story, well worth watching. The full episode doesn't appear to be online anymore, but here are the first 16 minutes: [https://www.pbs.org/video/american-experience-silicon- valley...](https://www.pbs.org/video/american-experience-silicon-valley- chapter-1/)

<comment><USER10> Yep, saw this when it first aired, and it remains one of the most enjoyable viewing experiences I've ever had. EDIT: The full episode is available on Amazon Prime for anyone who is interested.

</comment></comment><comment><USER11> If you like this, may I suggest Walter Isaacson's The Innovators. It's an excellent book, Noyce (and Shockley) are prominently featured.</comment>


Ask HN: Can my .org domain name be for profit? - <AUTHOR>

Hi HN,
I've been reading on the topic, but I wanted to check with experienced users.
Can I use a .org domain name for a commercial (for-profit) business?
In both legal, and perhaps ethical terms. For instance is using a .org for profit 'frowned upon' in the web community?
Thanks! <comment><USER2> These people do it:

Failblog [ dot ] org

No pun intended.

As far as I know it doesn't matter in the least but generally if you use .org you should do it for projects that mirror or reflect the use of the domain (unlike the example I posted). It's always best to have the .com .org .net domains. You can then forward to the one you decide to use.

</comment><comment><USER3> Running a .org as a for-profit is fine. For-profit Craigslist is the best example that I can think of; CL is pulling in tens (hunreds?) of millions in revenue. The only real risk I see is possibly confusing your users.

</comment><comment><USER4> It was back in the early 90s, but now TLDs have nothing whatsoever to do with what they're used for. All those .tv sites aren't run out of Tuvalu...</comment>


Show HN: Koi - a programming language that teaches language implementation. - <AUTHOR> http://thingsaaronmade.com/blog/introducing-koi.html

<comment><USER2> Aaron, how did you go about learning about programming languages implementation? I'm mostly interested if you went theory (e.g. reading a PL book) down to implementation (e.g. reading the ruby source code) or the other way around?

<comment><AUTHOR> It was actually a mixture of both. The first 'book' I read was <http://createyourproglang.com/>, which pointed me in the right direction as far as next steps. Personally I think the book is a little light on details, but it's _much_ more approachable than anything else I saw.

Most of my learning was through experimentation and lots of time on Wikipedia. The theory stuff mainly came from Wikipedia, then once I had a handle on basic theory I started having a look at how other people had implemented sections of programming languages, mainly sticking to implementations done in high-level languages where I could.

Strangely one of the things I found most helpful was looking through the instruction sets for Virtual Machines. For some reason seeing the operations broken down into chunks like that just 'clicked' in my head.

It's an absolutely _huge_ field to try to digest, and to be honest I still really don't have a good handle on many aspects of it (I've never written a garbage collector for instance) but the biggest thing for me was just getting past the point where I could understand 50% of it, that was when it stopped feeling like 'voodoo'.

I've started work on writing a book that offers more info on this in as simple and approachable a way as possible, I'd be interested to know if this is something people are interested in...

<comment><USER3> Hey Aaron, glad my book was helpful. What do you feel is missing from it? Now that I think about it, looking at instruction sets made it click for me too, so maybe it's something i should include. And nice work with your language!

<comment><AUTHOR> Hey Marc! I'd have to look over the book again to give you valid feedback, it's been a while since I looked at it.

It definitely pointed me in the right direction though so I appreciate that!

</comment></comment></comment></comment><comment><USER4> Good job Aaron. Must feel great to finally launch!

<comment><AUTHOR> Thanks Marc! Yeah, this has been a while coming now! I've just started writing a book that goes into greater (and more fundamental) detail on the process of simple language design.

Great fun!

</comment></comment><comment><AUTHOR> All feedback is warmly welcomed! If you see any sections of the code or docs that are unclear please let me know and I will fix them!

</comment><comment><USER5> That was quick, Aaron. Good job! :-)

<comment><AUTHOR> Thanks Mahmud! It's definitely nothing advanced, and it's a bit of a dead end as far as languages go, but I think it gets the point across!

</comment></comment><comment><USER6> Great job, thanks for sharing!

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


What we learned from the transcripts of Tony Blair and Bill Clinton's phonecalls - <AUTHOR> http://www.newstatesman.com/world/north-america/2016/01/what-we-learned-transcripts-tony-blair-and-bill-clinton-s-phonecalls <comment><AUTHOR> These excerpts are lifted from here:

[http://clinton.presidentiallibraries.us/files/original/5aa48...](http://clinton.presidentiallibraries.us/files/original/5aa4876f138a60330e869d23b372880d.pdf)

But I thought that the NS article did a reasonable job of cherry picking Clinton's humorous exchanges with Blair.</comment>


Build iOS Apps In Ruby - Available Summer '12 - <AUTHOR> http://mobiruby.org/

<comment><USER2> How is this :

        alert = UIAlertView._alloc \
            ._initWithTitle _S("Hello"),
            :message, _S("I'm MobiRuby"),
            :delegate, nil,
            :cancelButtonTitle, _S("I know!"),
            :otherButtonTitles, nil
        alert._show

supposed to be better than this ?

         alert = [[UIAlertView alloc]
                    initWithTitle:@"Hello"
                    message:@"I'm ObjC"
                    delegate:nil
                    cancelButtonTitle:@"I know!"
                    otherButtonTitles:nil];
         [alert show];

<comment><USER3> Exactly. The problem with this and MacRuby is _you're only really using the Ruby syntax._ The idioms are still mostly the same, which IMO is what makes Ruby shine, not necessarily just the syntax.

<comment><USER4> But you're not STUCK with that. You can write wrappers. Look at HotCocoa: that's Cocoa code that looks like Ruby.

Even outside of that, though, there are a LOT of things that you can do with MacRuby a lot cleaner thanks to it being Ruby over its Objective-C counterpart. Try launching an external process, for example. It's 5-8 lines of code at the very least in Objective-C (and it's not as flexible), whereas it's 1-3 easy to read lines in Ruby, depending on how much control and feedback you want.

I think as it matures, we'll see some wrappers that will make MobiRuby closer to what people are wanting to see from a Ruby-on-iOS solution; it's weird that you guys seem to have no vision for this sort of thing.

</comment></comment></comment><comment><USER5> My previous company shipped mac desktop apps written in Python. It made sense at the time (no sqlalchemy for cocoa) but turned out not to be great for many reasons. The two main ones imho were that the language doesn't fit the framework (argument passing style) and that you have to understand both languages and the bridge to be able to debug well.

My cofounder did a nice talk on our experiences: [http://www.madebysofa.com/archive/blog/pyobjc-and- cocoa/inde...](http://www.madebysofa.com/archive/blog/pyobjc-and- cocoa/index.html)

<comment><USER5> And here too: [http://dirkstoop.posterous.com/why-im-slowly-moving- checkout...](http://dirkstoop.posterous.com/why-im-slowly-moving-checkout- from-pyobjc-to)

</comment></comment><comment><USER6> Experience taught me this:

In the world of OS X/iOS the frameworks are really important. You have to understand them. You have to work with them. It is not uncommon that you need much more time to get familiar with a framework than to get familiar with Objective-C.

Take Core Data for example: Core Data is an extremely cool framework but you need a couple of days to understand the basics, a couple of weeks to understand the advanced concepts and years to really master it.

Objective-C is a pretty easy programming language.

So a a conclusion: Does it really make sense to replace Objective-C with - lets say Ruby? What do you gain? Lets assume you already know Ruby - then it saves you to learn Objective-C. But 90% of the time you will deal with the frameworks - not with the language. In my opinion it does not really make sense to use Ruby instead of Objective-C because you save so little.

<comment><USER7> For code that's just gluing bits of the API together I agree you're not going to do much better than Objective-C and really that kind of code makes up the bulk of most apps.

Obj-C really falls down for more complex algorithms, data structures, and text handling. You can do this kind of thing in Obj-C, of course, but the verbosity really gets in the way. A higher-level language like Ruby would be great for this but maybe the new object literals coming in Obj-C will help close the gap.

<comment><USER8> Still don't see it. Algorithms and data structures are going to be the most performance critical parts. It's the glue code if anything that should be written in a scripting language.

<comment><USER7> Sure, but in a lot of today's apps there are no performance critical parts. They're already well under the ceiling of what the hardware can do all the time or they spent 95% of their CPU in optimized routines in the OS/kernel. Of course, a more expressive but faster language like Mirah or Kotlin or Go something would be ideal here.

The problem with writing glue code in a scripting language is that it doesn't really buy you much unless you can impose a new, higher-level abstraction on the existing UI. As these examples show, you haven't really improved on Cocoa if all you've done is changed the function calling syntax.

</comment></comment></comment></comment><comment><USER9> People of Earth:

This is nonsense.

Objective C is a fantastic language. Appcelerator Titanium, PhoneGap - it's all crap. Customers can feel the difference.

To make a native app, learn a native language.

<comment><USER10> Really wish the Flash devs I worked with thought this way.

"Oh I've been looking into PhoneGap, it's pretty cool"

"Oh I've been learning Android development"

WHY???? When has a client even asked us to make an Android app.

<comment><USER11> While iOS devices are pretty up to date, phonegap/flash/titanium/corona are actually pretty nice on android when you have 15 different operating system versions all seemeingly evenly deployed on the market

</comment></comment></comment><comment><USER12> So, you type out the same obj-c code, but with different syntax.

Doesnt seem to save any time at all.

<comment><USER13> Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore.

MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works.

In Objective-C:

        Person *person = [Person new];
        [person name];
        [person setName:name];
        [person setFirstName:first lastName:last];

and in MacRuby

        person = Person.new
        person.name
        person.setName(name)
        person.setFirstName(first, lastName:last)

As far as I can tell in MobiRuby that'd look something like this:

        person = Person._alloc._init
        person._name
        person._setName _S(name)
        person._setFirstName _S(first), :lastName, _S(last)

<comment><USER14> current method role is tentative. I'll do more improvement.

<comment> grey-area In your example you have:

      alert = UIAlertView._alloc \
        ._initWithTitle _S("Hello"),
        :message, _S("I'm MobiRuby"),
        :delegate, nil,
        :cancelButtonTitle, _S("I know!"),
        :otherButtonTitles, nil
      alert._show

Presumably you don't want to stray from UIKit method names in order to make translation automatic, which is understandable, however translation could be automatic couldn't it - is all that _S necessary? Did you consider a chained, hash syntax something like this:

      alert = UIAlertView.alloc().initWithTitle(:title => 'Hello',
                                                :message => "I'm MobiRuby",
                                                :delegate => nil,
                                                :cancelButtonTitle => "I know!",
                                                :otherButtonTitles => nil).show()

With the syntax above someone could omit nil arguments and still get the right result, if you fill in missing arguments for them.

Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off.

Having looked at your pages further, I see the possibilities of a cross- platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?

</comment></comment></comment></comment><comment><USER7> It's things like this and Corona (Lua) that make me thing that the people that are proclaiming that the emergence of mobile is going to lead to a native code "renaissance" are indulging in some wishful thinking.

Sure, there will always be _some_ apps that will need to be coded close to the metal in C/C++ for maximum performance. But now we're seeing more and more that even on mobile devices we have enough power that we can afford to write most apps primarily or even entirely in "managed" languages like Lua, Java, and (apparently) Ruby.

<comment><USER15> In which languages are you then coding the VM/JIT?

At some level you need native code.

For me, I want something like Ruby that generates native code.

<comment><USER7> Of course you need native code on the foundation. But it doesn't look to me like mobile is really going to change the equation that you only need one native programmer for every 100 higher level programmers.

I'm not optimistic about trying to generate good native code from a language like Ruby. You need much more control over memory layout, just for starters, to get real native speeds.

</comment></comment></comment><comment><USER16> From a first look, MacRuby does a better job of integrating with Objective C/Cocoa.

</comment><comment><USER17> So what does this do? compile ruby code into objective c? or directly into machine code that can be run on iOS?

</comment><comment><USER18> I'm assuming that you will wrap this all up in ruby objects and expose a cleaner syntax? As orta said the Objective-C syntax is currently cleaner.

From an engineering point of view i have to say that this is impressive, very keen to see what tools you come up with to aid the development process, a TextMate bundle to compile and deploy to the sim would be super sweet ;-)

</comment><comment><USER19> I love obj-c, especially after the blocks. Sorry, you guys are too late.

</comment><comment><USER20> Does this project intend to make /all/ of Objective-C available thru Ruby?

<comment><USER14> Yes, MobiRuby aim implement all ObjC capability.

</comment></comment><comment><USER21> If they can pull this off, I'll definitely be on board ... good luck.

</comment><comment><USER22> Will I be able to make a photo-sharing app with this?

</comment><comment><USER23> would it save us from the hell of objective c?

<comment><USER24> Why do you think it's hell? I've been using it for about 2-3 years now and it's really grown on me over that time. I think the most common complaint is that it is too verbose, but that has its advantages too.

<comment><USER21> what's an advantage of being too verbose? extra exercise for your fingers? ;-)

<comment><USER25> With autocomplete you don't get much extra exercise anyway. It helps to strain your brain less however when reading the code.

<comment><USER26> I don't think "arrayByAddingObjectsFromArray:" is particularly clearer than "concat" or "+" unless you're just totally unfamiliar with the language. In fact, for many selectors I find the shorter names easier to read because my brain sees them as a single token while I have to mentally parse Cocoa's behemoths every time I run across them. There is some benefit to clarity, but very often Objective-C's glut of information makes it harder to pick out the details you were looking for. Smalltalk was considered quite readable and in fact was the inspiration for Objective-C and Cocoa, but its selectors were more minimal (for example, the equivalent to the above methods is #addAll:).

(Just to establish that I'm not _completely_ talking out my rear end: I've been programming Objective-C for ten years, Ruby for five.)

<comment><USER13> oh crap, does concat create a new object, or mutate the current one? is it the same as using + or do they handle objects differently....? should I be using << here maybe?

I agree with you that the verbosity of ObjC makes it harder to mentally parse fast, but I also think there is a lot of clarity to it when you read it slow.

Where I see ObjC fall down is more in terms of command verbosity. For example in Ruby,

        File.open("readfile.rb", "r") do |infile|
          while (line = infile.gets)
            puts "#{line}"
          end
        end

...would be ~150 lines of code in ObjC (Dave DeLong: <http://stackoverflow.com/a/3711079/196358>). Which is not really a failing of the language, actually. It's a failing of the libraries that come with the language.

Apple chose to give you a couple ways to read a file. The easy way is `stringWithContentsOfFile:encoding:error:error`, but the next level of control is way to low level. Dave DeLong's solution to reading a file line by line exposes an api that looks like this:

        DDFileReader * reader = [[DDFileReader alloc] initWithFilePath:pathToMyFile];
        [reader enumerateLinesUsingBlock:^(NSString * line, BOOL * stop) {
          NSLog(@"%@", line);
        }];

Not actually much more complex or verbose than the ruby.

</comment></comment></comment></comment></comment></comment><comment><USER27> How about you learn the native language. You will never get the most out of a platform without going native. Apps like instagram, any games, and the most exciting apps in mobile will always be native. Great programmers have the tools to build what needs to build.

<comment><USER28> Totally. That is why I code my web apps in assembly. Frameworks and higher level languages have nothing to offer.

<comment><USER27> Thats not the same because iOS and android are both frameworks. Adding framework onto framework especially on mobile which moves so fast cause more problem than it solves because people start complain that google or apple broke there framework which shouldn't have been there in the first place.</comment></comment></comment>


Amazon has deleted over 900 reviews of Hillary Clinton's new book - <AUTHOR> https://qz.com/1076357/hillary-clintons-what-happened-amazon-just-deleted-over-900-reviews-of-hillary-clintons-new-book/ <comment><USER2> Amazon did _not_ delete 900 reviews of Hillary's book. Amazon deleted 900 comments that weren't book reviews. Amazon reviews are for reviews, not comments.

<comment><USER3> Ok, that makes real question whether they do this as a matter of normal course or if this is a case of a politician "author" (ghostwritten of course) receiving special treatment.

And the answer is, unsurprisingly, that this is definitely not standard Amazon operating procedure.

<comment><USER2> > ghostwritten of course

Proof?

> this is definitely not standard Amazon operating procedure

Proof?

</comment></comment></comment><comment><USER4> Worse than clickbait this belongs in the "fake news" garbage bin.

Not biased at all, the first paragraph starts :

"During the 2016 US presidential election, Donald Trump galvanized a small but powerfully vicious fan base in his campaign against Hillary Clinton. Ten months after Clinton was defeated, things are getting nasty again."

Labeling Donald Trump's fan base as "small" and "vicious" is rather absurd. Apparently so small that he won the election. Absurd drivel. And misleading headline as others here have pointed out.

</comment><comment><USER5> Another terrible clickbaity reddit title. Comments are not reviews. A review requires reading the book!

<comment><USER6> They also deleted reviews by people who purchased it and scored it low.

<comment><USER7> Where did it say that?

</comment></comment></comment><comment><USER7> Zoe Quinn's recent book also had a similar (and predictable) skew between verified purchasers and non-verified. There's probably an amusing 'ethics in Amazon reviewing' joke to be made there but I'll quit halfway.

</comment><comment><USER8> Amazon ought to limit reviews to purchasers.

<comment><USER9> Amazon doesn't _know_ that a given reviewer hasn't obtained the book elsewhere. Do you know of any other books for which they have performed proactive censorship of reviews?

<comment><USER10> Right, that's why those people would, in this system, not be allowed to review it on Amazon. Because Amazon doesn't know whether the reviewer has or hasn't obtained the book at all.

<comment><USER8> And indeed, Amazon isn't really Good Reads. It's an online store. There's no reason why reviews there should cover anything except purchases. Except that it makes Amazon look more of an active community. While that was important years ago, does it really matter now?

</comment></comment></comment></comment><comment><USER11> It happens in many places. Look up Art of the Deal and filter by 1-star reviews, and you'll see many comments that are clearly just opinions of President Trump, as opposed to the book itself.

</comment><comment><USER12> Clickbait title, we can already hear people screaming censorship without reading the article.

</comment><comment><USER13> Even though this is the correct thing to do, I don't like it that this book got a special treatment. Will other books that have received bad reviews from non-verified purchasers have those reviews removed?

<comment><USER14> They won't, except they named Clinton

</comment></comment><comment><USER15> This is very interesting - back when I joined Amazon, one of the new hire on boarding questions was about how to deal with bad reviews and the principle was to just leave them as it is and not delete it - I am not 100% sure about it though - can someone confirm? If so deleting these reviews seems opposite to that

<comment><USER16> The key is whether the reviews are legit. If the review is made by someone who did not buy the product, its not a 'review'. It is then violating Amazon's rules and should be deleted.

<comment><USER17> By a large margin, the ratio of legitimate (verified buyer) to "maybe but probably not legitimate" reviewers is the worst out there at the time of this article's publishing. It's pretty clear these are not valid reviews.

Personally, I think on hot topic items like this, Amazon should simply lock down 100% to verified purchases for like, 2 weeks.

<comment><USER18> The reason they don't do this is that the people with pre-publication access to the book, while mostly the authors friends and family, are the only source of reviews for buyers looking at Amazon on launch day. They don't want to throw away those reviews, and those readers obviously didn't buy on Amazon.

<comment><USER17> They don't need those reviews in these cases. There are PLENTY of real reviewers in a high profile case like this.</comment></comment></comment></comment></comment>


Show HN: Drov.io – plug-and-play user authentication and management platform - <AUTHOR> http://drov.io <comment><USER2> A quick remark: you may want to lose the autofocus on the call to action input field.

On mobile (tablet) it automatically pops up the keyboard, between that and the cookies disclaimer it hides almost the whole page.

<comment><AUTHOR> We target desktop versions so we have designed the site accordingly. We are currently updating it for the mobile version as well! Thanks a lot!!</comment></comment>


How often does Rust change? - <AUTHOR> https://words.steveklabnik.com/how-often-does-rust-change <comment><USER2> It seems weird to think that Rust is changing too much. It's a young language and has a lot of catching up to do to cover all the use cases it's intended for and bring in all the niceties we expect out of modern multi-paradigm programming languages: procedural, functional, and object-oriented techniques.

C++ is from 1985 and standardized in 1998, and it's still changing at a fast clip: C++11, C++17, Concepts will be a big deal when they happen in C++2?.

Rust wasn't announced until 2010 and didn't ship 1.0 until 2015. It's only had 5 years to bake since 1.0, vs the 22 for C++.

<comment><USER3> That's certainly reasonable, but I think it seems harder to keep up with when people compare it to languages like Go (first appeared November 2009) and Kotlin (first appeared July 2011). Those languages both seem really easy to keep up with by comparison. Of course, both of those languages are going along much more well trodden paths.

I think the "Rust is changing too much" feeling comes from people _really_ wanting to use Rust because it has a cool new way of managing memory and zero- cost abstractions, but also feeling like it just keeps moving a little too much on them. Languages like Go and Kotlin just aren't moving much on them.

I think that another part of that feeling comes from the fact that Rust has two different pieces: a) the new way of dealing with memory and abstraction; and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only game in town there. You can't just decide that you need the memory lifetimes and zero-cost abstractions, but don't want to deal with the rest of Rust's evolution.

This might be easier to illustrate by contrast. If I want a statically-typed, garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go, TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust. I can't decide that I don't like the other parts of Rust or don't want to deal with Rust's evolution. If Kotlin were evolving quickly and breaking lots of things, I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go". I can't say "Rust is dumb and I'll use..."

When there aren't easy replacements, you're wedded to the decisions of the community. The easier the replacements, the less loud your complaints will be about a language. I think that Kotlin was pretty great for Java because it was highly compatible with Java and gave Java breathing room to figure out how it would evolve Java. Kotlin gave frustrated people a path; it gave Java breathing room to figure out its evolution; and it gave Java the opportunity to look at what worked well in Kotlin and figure out how it could apply that in Java.

When we look at Go, there are often complaints because Go offers things unavailable elsewhere: fast compile times and to a certain extent its concurrency support. So if you really want fast compile times, you don't have an alternative.

Rust is probably changing more than languages like Go and Kotlin which are similar aged. There's a good reason for that: Rust's brief is a lot more novel and expansive than those two languages. However, if you're sold on Rust's memory management and zero-cost abstractions, it might be annoying that it feels like more of a moving target than a language like Go or Kotlin - and you have no alternative to fill that void.

<comment><USER4> > If I want a language that doesn't need GC while not having memory > leaks...I'm left with Rust.

I never used those languages, in fact I discovered them on previous HN posts, but it seems to me that in this category you can also have Nim and Zig, no?

<comment><USER2> Those are considered niche compared to Rust or C++. Rust has a large ecosystem around it and at least one large sponsor (Mozilla) and used in production by others like Cloudflare, Yelp, and npm.

I think Nim and Zig are both quite interesting and potentially very productive, but they have a long way to catch up to Rust in terms of community support.

<comment><USER5> Not being corporate-driven is a feature, not a bug.

<comment><USER2> Corporate sponsorship is just an example of the level of support that exists for Rust. And it's Mozilla I'm talking about here, not your typical corporation.

Certainly other languages were able to become widespread with large communities and library ecosystems without being directly sponsored by a corporation, such as Python or Ruby. I tend to think of those as associated with an individual, Guido or Yukihiro, though I know in Guido van Rossum's case he's worked for Google and Dropbox, though that was after Python was in wide use at those companies.

Whereas with Rust I think "Mozilla" not "Steve Klabnik", because it was corporate-sponsored from the beginning and worked on by a team.

And if you want your favorite language to grow into its potential, you need funding, and corporations have a lot of funding to put into things like potentially productive new languages.

</comment></comment></comment></comment></comment></comment><comment><USER6> Some thoughts on my short experience with rust for anyone that cares. Probably a yearish ago?(Futures weren't solid yet) I didn't read the original blog post, just the head line and skimmed comments. Though i read this one

I think this post alludes to my issue, the language it self i don't think changes at an unreasonable rate, the ecosystem felt like a problem. There's so much changing, what's the "right" way, the right library, expected syntax seemed overwhelming. maybe this doesn't change a lot, but it is compounded by the new user experience. Other things are out dated resources around the internet. The other thing I think that makes this seem worse is I think the a lot of the community is online and hobbyist work, and the speed communities change on line is just fast, information moves fast, blink and you'll miss something.

I do remember feeling excited about rust, but it felt like there was always something new learn, something around the corner, something better coming then a new feature would come out, i gotta learn that, what is going on in nightly. Supposedly editions fixed that, but even that I gotta go figure out what an edition is and what its implications are.

I haven't gone back to rust, at this point I feel like i need to relearn it to write anything worthwhile. Just basic stuff like how projects are laid out. I have a commit in the rust compiler, but i cant tell you the right way to organize a new project because at some point it changed. To much to keep in my head.

<comment><USER7> You are absolutely right, futures were infamous for having a lot of churn and being really difficult to work with. Rust was very speedy but unergonomic for web stuff. This is why the past year was spent on async/await which dramatically changed it all and now writing web servers is really simple:

[https://github.com/seanmonstar/warp](https://github.com/seanmonstar/warp)

</comment></comment><comment><USER8> For those that assert Rust changes too much, I would submit the simple question "Why?" to them. "Too much" seems to imply that the language breaks their code too often to make it worthwhile writing software, though this has been a thing Rust explicitly avoids since 1.0 happened. Rust 2018 took some liberties at breaking old code, but it only really matters if you explicitly upgrade to 2018, at which point you've already committed yourself to making potentially-significant changes. I imagine a future "big change" like Rust 2021 or whatever would do the same; I likewise hope that all N editions can interoperate no matter how many N editions exist.

> However, maybe there's a better way to surface "these are big changes" vs > "this is a small thing," or something like that. I'm not sure.

It might be as hard, or even harder, to quantify this than even deciding what gets put into the release notes. What might be a big change for one person is absolutely insignificant for another, and vice-versa.

<comment><USER9> I gave up during the switch to the 2018 edition. Today, I still write 2015 code because I couldn't bother to decipher how paths and `extern crate` had changed. The documentation on the differences was too sparse to relearn it (maybe there was enough documentation to start for scratch, I don't know). It was also a busy time with NLL (those changes were simple).

Since then the 2015 edition hasn't stopped either: warnings popped up to use `dyn`, warnings that deprecated `std` functions, new feature gates added and old feature gates were removed. Libraries weren't spared: The minor releases of `rand` are so incompatible that they needs upgrade guides themselves.

For 2018 I may learn it 'sometime', every change further delays. There's Futures, there's async now. I don't have time to decipher the types since I don't need it. However there was and is so much discussion that I'm already tired.

<comment> Ar-Curunir > new feature gates added and old feature gates were removed

This is only a problem on nightly, which is a toolchain which explicitly makes no stability guarantees and is intended for experimentation?

> For 2018 I may learn it 'sometime', every change further delays. There's > Futures, there's async now.

You don't have to interact with things that you don't use, though. For example I've been on Rust 2018 since day one, and I still haven't needed to learn about futures.

<comment><USER10> Reading code matters too. Languages are not just written

<comment><USER11> Sure, but when reading code you didn't write, you have a whole list of things you need to spend extra time on - the style, the way functions are broken up, how data types are organized... if you come across one or two new language features in use as well, stopping to learn enough about them to reason about the code is not a big deal (to me at least).

</comment></comment></comment></comment></comment><comment> as-j This is amazing, and great. "Does a language change too much" is very much use dependent, and it's great to have the data.

For me, an embedded systems developer, this is an order of magnitude too much. Rust is so appealing for my use case in many ways, but I need an environment that a team can easily work in for years. My current code base is 10 years old. Our base system dates from 2017, and it took until 2018 for us to update to that. We were going to do a late 2019 base update, but sadly the project was delayed for other reasons. Our application side updates monthly, a much smaller OTA DFU. (over the air device firmware update)

You can compare it Lua:

[https://www.lua.org/versions.html](https://www.lua.org/versions.html)

The community is much smaller but it's interesting to see even at it's comparatively glacial release schedule there's a large split between 5.1/5.3.

Why do a rapidly evolving language, stdlib, etc matter?

1\. We're going to be year(s) behind. I need everyone to learn and be proficient at the languages we use. They need good consistent doc and manual for our version. And not complain that we're on 1.31.0 but this great feature is in 1.33.1.

2\. Moving base languages is support, not direct project improvement. While we standstill moving the base system/language/tooling forward our customer releases a new feature.

3\. People are always going to google "how to do silly thing" and get code snippets. Heck I do this all the time with Python. =) It's really nice for this be somewhat consistent/right.

Sigh, as an embedded dev I'm so torn on Rust.

<comment><AUTHOR> Have you heard of the Sealed Rust work?

<comment> as-j Nope?

This?

[https://ferrous-systems.com/blog/2019-06-05-sealed-rust- the-...](https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the- pitch.html)

Do you have a short version recap in 1 or 2 sentences? Plus any liensing/costs/etc/etc?

<comment><AUTHOR> Yep!

The short recap is: some folks are trying to get a subset of the language certified. They run an entire consultancy that does a lot of embedded Rust work. I am hoping that this will help to alleviate the issues you're talking about; we'll see how it goes!

<comment> as-j That's awesome thanks! I look forward to it.

</comment></comment></comment></comment></comment><comment><USER12> I hear exactly the same about Python.

Some complains it's moving too fast.

Some that's it's an old language that's stuck in the past.

The balance between stability and keeping up with modernity is hard to reach, and people will never be happy.

<comment><USER13> Comparison with python actually helps to put Rust in a positive light. Compared to the Python 2/3 debacle, Rust managed to introduce a major new version with lots of new language features (edition) while making it: a) entirely opt-in, b) easy to update to with automated tooling, and c) compatible with previous versions.

Compare this to Python 3, which cannot load Python 2 libraries, cannot be converted automatically, and is now effectively required with the sunsetting of Python 2 in January of this year. Python has a lot of strengths, and I think 3 is way better than 2, but the transition was very painful.

Meanwhile, I have a crate I wrote a while back for 2015 nightly, and it took me less than an hour to get it up and running for 2018 stable. But I didn't have to! Everyone using 2018 (nightly) could still use the crate even if I hadn't converted it.

</comment></comment><comment><USER14> Subject matter aside, it's always wonderful to see thought leaders analyze their prior public claims and reach a conclusion that their hypothesis was wrong. Hats off.

</comment><comment><USER15> Something that Steve touched on but didn't dive into is that there's a difference between measuring facts, like the number of changes in a period of time, and measuring the cognitive impact of those changes. I'm sorry in advance for how rambly this post is.

`const fn` is a nice example, because it's a large number, but the cognitive impact could be neatly summarized for the general rust userbase by "neat, but I don't really care". The cognitive impact is directly proportional to how easily we can abstract the changes into a coherent story. Does it matter that there were exactly 138 "this fn is now const" changes in 1.33? No, because you already forgot that there were actually only 125. What's the actual difference between 13 extra `const fn` changes and a list of 13 other completely independent changes? 13 arbitrary library changes sound like a lot when they're not neatly bounded by a pre-existing frame of reference. In this case, "this fn is now const" * X where X is 'a big number' doesn't change in cognitive impact when X is replaced with X * 1.1.

I think that Kubernetes release notes are another interesting example. There's typically a huge number of changes due to the distributed nature of the project's development. The vast vast majority of the changes would have little to no effect on _your_ k8s deployment, but there may be _some_ nugget in there that does have a big impact on you. The problem is that that nugget is different for everyone.

So it seems like the key to communicating change may be to present the change _in conjunction with_ a carefully selected frame of reference that enables the audience to easily conceptualize the bounds of the effects of the change in relation to their own experience, before being inundated with the details of the change that would only be useful to people occupying a different frame of reference. The problem is that everyone's experience is different and the impact a change will have will greatly depend on who's reading.

Maybe release posts need old school newspaper-like front pages where changes are scoped and summarized, and details are hidden unless the user wants more. Or maybe there should be multiple posts from the perspective of different user personas. But these ideas aren't cheap to implement, and the problem seems to approach something like "the fundamental difficulty of communication" which is way beyond my scope of understanding.

<comment><USER16> > The cognitive impact is directly proportional to how easily we can abstract > the changes into a coherent story.

Exactly! This is how language and API changes are usually _designed_ , and announcing them the same way is a great idea.

</comment></comment><comment><USER17> > ... but soundness fixes happened so little it wasn't worth talking about. > There were 7 in those 42 releases.

Are there any similar statistics for other languages? To me this seems high. It's not common that a program that compiles in other languages becomes illegal in a later release.

I mean I understand why the Rust developers make this choice—the language aims to provide strong static guarantees, but I hope they appreciate that users don't like when their programs break after a compiler upgrade.

<comment><AUTHOR> Some of them didn't break any more, they were always broken. Or, some of them were purely additive. We added mitigations against [https://blog.qualys.com/securitylabs/2017/06/19/the-stack- cl...](https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash), that was categorized as one.

</comment></comment><comment><USER18> I'm happy with the changes to rust and their pacing but I want to point out that merely asserting "you don't have to use these features if you don't want to" is disingenuous and particularly so for open source contributors (Steve did NOT say this but it was a common refrain in the discussion that Steve is contributing to). It threw me for a loop the first time that I saw the spread operator in an assignment in a project I was filing a PR for, and I thought I was on top of all the features.

Some changes that stand out to me: the try macro being deprecated was huge, and though the ? Operator is a thousand times nicer, that was a rather radical shift to the ecosystem where you could smell code from yesterday a mile way; I seem to remember try blocks were stabilized then removed but I seem to be mistaken on that count; async of course is a huge change and it absolutely does force you to use it since it's a contagious language feature in pretty much all languages (I'm very disappointed with tokio on this count and have a feature I'll probably file a PR for to help reduce this); the change allowing reusing the same variable name inside a match binding as the variable being assigned to was hugely beneficial but quickly broke backwards compatibility because of how nice it was to give up. I think the changes to std::error are also worth mentioning, they might be backwards compatible but they completely obviated an entire generation of crates and coding styles (I for one do not lament the death of quick error and co).

I feel a better metric for this might be to study the min rustc version to compile libraries, i.e. community adoption of new or breaking changes. If you take the releases from the top 250 crates in the past few years and see how many rustc versions back from whatever was stable at the time of release could compiled the release, that might give you a more data-oriented result.

Also, I think some of the real frustration might be from "core" crate breakage, such as the transition from tokio 0.1 to 0.3 and the ensuing mess or examples like gfx-rs that hundreds of other popular crates built on to get OpenGL support before they completely deprecated it and pivoted altogether such that not all are those crates left based on a dead-ended project but OpenGL users are all SOL ("just a little while longer!") as the community- adopted alternative is wgpu which requires Vulcan/Metal/DirectX until the promised OpenGL support lands there.

I'm not complaining; NIH people generally get off easy with community deprecation of popular crates ;) and OSS developers are absolutely not beholden to anyone. But I imagine for developers plugged into the ecosystem, changes to extremely popular crates and changes to the language or standard library might result in a general annoyance that doesn't distinguish between the two (and that's also fair since the reason rust has a small standard library is so people use crates which can be more easily replaced or deprecated).

<comment><USER19> That something pro-generic people in Golang tend to miss: once you enable a feature it means everyone is going to try to use it. And this has consequences. And people should ponder more often on why Golang is so clean to read.

<comment><USER20> Beware. Exactly the same thing is true for COBOL: Easy to read, very low abstraction, but you need tons of repetitive code for anything. A language that is too simple brings its own trouble.

<comment><USER19> sure, but Golang seems well accepted and widely used in a multitude of different tasks, so it seems to have found the right balance I would say.

<comment><USER20> That is unfortunately exactly as true for Cobol as for Golang.

<comment><USER19> Who uses cobol?

</comment></comment></comment></comment></comment></comment><comment><USER21> Meh. When considering a language for a project one should also consider its maturity.

Stuff like C/C++ basically won't ever change*. Code that you write today will probably compile in ten years. If you're writing in C++17, there will probably be a C++17-mode in 2030, as there are C-99 and C-89 modes today.

Otherwise, if you want the newest shiny language, you shouldn't complain when it changes.

But it's nothing new really: there's no free lunch.

<comment><USER22> Rust has made, and so far kept, this same promise.

But also you're wrong about C/C++, new versions of those compilers often uncover dormant undefined behavior when the compiler slightly changes behavior in certain areas.

<comment><USER23> That's two different things.

If your program does not compile anymore because it was relying on undefined behaviour, it was wrong from the beginning and deserved it.

It is completely different of old sane codebase not compiling anymore due to syntactic sugar change in the language.

<comment><USER24> >> It is completely different of old sane codebase not compiling anymore due to syntactic sugar change in the language.

That is not very common with Rust.

If you just download some project off of Github (or using some dependency) from 2015, it is very very likely to "just work" even with a new compiler, due to how editions work.

A more likely way to encounter issues is by pasting some code from Stackoverflow into a Rust project that is using a different edition. Yes, that can happen, but it's not anywhere close to as big of a problem.

<comment><USER25> And even then, I try to update any SO questions and answers that are still useful to the latest edition, as it's more likely someone who doesn't know about editions will be playing around with 2018.

<comment><USER26> I see your work around Stack Overflow a lot and I'd like to thank you for that: your answers and contributions have helped me significantly, multiple times.

</comment></comment></comment></comment></comment></comment><comment><USER27> Nobody is "in the thick" as Rust core dev or aficionados are.

There is a reason commercially backed language have a mush slower release pace and big release. It is easier to write doc for and prepare _formations_ , _classes_ and _certifications_

For better or worse, in corporate/industrial landscape those are kings. If Rust does not understand that it might stay in the hobbyist category.

With Javascript being the exception. Unless I am completely wrong and it is the new norm.

<comment><USER28> > With Javascript being the exception

And Python. And Ruby. And C++. And Kotlin. And Swift.

</comment></comment><comment><USER29> Answer:

1\. Quite often.

2\. With some breakage of existing programs.

... and this is a fundamental paradigm difference between Rust and C++, for which the answers are:

1\. Every 3 years.

2\. Changes are backwards-compatible [1]

\-----

[1] There are slight specific manageable caveats. Example: The repurposing of the `auto` keyword.

<comment><USER30> Stable Rust has never broken a crate. If you specify a different edition _for your own_ crate, you can still use dependencies of both older and newer versions.

C++ won't let you just (seamlessly) use a C++98 library in a C++20 project, or vice-versa.

<comment><AUTHOR> > Stable Rust has never broken a crate.

This is too strong. We _have_ made some soundness fixes that have broken crates. (We spread the change out with warnings for a long time before actually breaking) We _have_ changed type inference in ways that one or two crates needed to add an annotation.

The vast majority of the time this is correct though.

</comment></comment></comment><comment><USER31> A more relevant experiment would be to take Rust code released 6, 12, 18 and 24 months ago, and try to use it, in particular try to read messages in forums and stack overflow and try to use/fix that code. You'd find it was impossible, because Rust changes so fast that nothing written about it survives 6 months without becoming inaccurate. Which is why I threw up my hands and gave up.

<comment><USER22> I've been working with Rust for over five years now. This does not relate to my experience.

New things come and they make things easier, but anything from 6-24 months ago, still works in the identical fashion as it did at that point.</comment></comment>


Which weight will lift first as the rope is pulled? - <AUTHOR> http://friendfeed.com/rahsheen/b7e00bb3/which-weight-will-lift-first-as-rope-is-pulled <comment><USER3> I loved these pulley problems in statics.

Assume the weights are resting on a surface, the pulleys and rope are massless, the pulleys are frictionless, and the system is maintained in quasi- equilibrium as the rope is pulled (steady state & small accelerations). In this case, the tension T in the rope is constant everywhere. Now, take a horizontal section through the ropes. ("Cut" them and replace the missing portions of the rope with the tension.) Each weight is experiencing an upward force of 2T.

When 2T >= 20, or T = 10, weight A begins to rise. Once a hits a stop, T must be increased to just above 20 to get Weight B to rise. Similarly, T just above 30 causes C to rise after B stops.

The "trick" with these pulley problems is to section the problem through the cables and show the tension, T. Then you've just got free body problems, in this case subject to the floor constraint.

Oh, also, while the first weight is being lifted, the floor beneath weight B experiences 40 - 20 = 20 units of force, and the floor under C experiences 60 - 20 = 40 units of force. Once B is lifted, the floor under C experiences 60 - 40 = 20 units of force. (Presuming that the labels are weights, and not masses.)

<comment><USER4> "When ... T = 10, weight A begins to rise".

No; the Tension the guy is supporting at rest is bigger than 10 (there are 2 other weights) so at T = 10 he would be moving backwards. He needs to apply a bit more than the tension at rest.

(edit: this is for when all 3 weights are in the air, I see now some people see them in a floor that is not drawn)

<comment><AUTHOR> The bottom of each weight is at about the same level as the bottom of the man's feet. A floor is the natural thing to assume. Otherwise it would be difficult to get them into this configuration.

<comment><USER5> A good way to think about this is to replace the man with a fourth weight, fixed to the rope (as opposed to a pulley). Now it should be clear that the weights would not rest in that configuration unless they were supported by a floor.

</comment></comment></comment></comment><comment><USER6> If the system is frictionless, the rope is weightless, and the weights are not supported, then the lighter weight will rise and the heavier weight(s) will fall. Therefore if the rope is pulled very slowly, the lighter weight will rise first.

If the rope really is weightless and the pulleys really are fictionless (and inertialess) then it doesn't matter how hard or fast you pull, the lighter weight will rise first. This is at odds with your intuition simply because you have no (or insufficient) experience with weightless and frictionless environments. This is one reason why space is so bloody dangerous, in addition to the dangers posed by, say, diving, where similarly to space, your equipment has to work perfectly or you die.

In the real world, pulling fast enough will make the closer weight rise first.

The truth lies somewhere in between.

<comment><USER7> >If the rope really is weightless and the pulleys really are fictionless (and inertialess) then it doesn't matter how hard or fast you pull, the lighter weight will rise first.

I'm considering a thought experiments that make me believe that this is not the whole story.

Imagine a two weight system set up similar to the original diagram in which the weights are the same weight, and the gravity is very little. Yanking on the rope I imagine them rising at the same speed. Now, we take a very small flake off of one weight and repeat the experiment. It seems clear that both weights will still rise from the start, just the lighter weight will rise at a faster speed.

I think this should extend to three weights of any positive mass -- if you yank the rope fast enough (and it might be very fast) all three should rise from the start.

<comment><AUTHOR> In your thought experiment you make the weight difference so small that otherwise insignificant factors (e.g. friction) take over. Go the opposite direction and make the weight difference enormous.

<comment><USER7> Assuming no friction and given a fast tug of the rope I still don't think the near equal weight would hold still or sink while the other near equal weight flew up quickly.

With the large weight difference, I think the required speed of pulling the rope to make them both rise just becomes impractically fast.

Imagine the system in space - all the weights would move up, so they all have an upward force applied to them from the rope tugging. It's just a matter of pulling so fast that that upward force overcomes gravity.

</comment></comment></comment></comment><comment><USER8> Well, the diagram is impossible unless the weights are all resting on the floor, so let's assume they are. This system will find a steady state only at a local minimum of potential energy, so the lightest weight will be lifted before the heavier two get off the ground.

<comment><USER9> Assumptions:

      pulleys: idealized, massless, frictionless

      rope: idealized, massless, doesn't stretch

      weights: resting on ground.

As tension is applied to the rope, Weight A will be lifted first, until it is lifted to the ceiling. Then Weight B, and finally Weight A.

It helps to visualize Weight A as being massless. In that case, there would just be extra slack in the rope, and B&C would not move until the slack was taken in.

<comment><USER10> * Then Weight B, and finally Weight A.*

I believe you meant C, correct?

<comment><USER9> Yes, I meant C. Too late to go and fix it now. Good catch

</comment></comment></comment></comment><comment><USER11> This tricks people because it doesn't start out in static equilibrium. For it to look like this, the weights would have to be resting on a table to relieve the tension in the rope.

If the man does nothing, the heaviest weight will fall and the lightest will rise. If it's frictionless and he starts pulling, the same thing will happen, only the lengths will lessen.

<comment><USER12> Could it not be in a meta stable equilibrium like this if the weights were of equal mass? The numbers of the weights are unit-less. We assume they represent the mass, but for all I know the number is the serial number of the weight.

<comment><USER11> For all we know, it could be in space, they could be heavily magnetized, 100m/s wind, .5 CoF in the pulleys, the rope could stretch, and the system could be traveling near the speed of light.

</comment></comment></comment><comment><USER13> I'm with Rider, if you view it as a "classic" physics class problem, ie weightless ropes and pulleys (and hence no angular inertia for the pulleys, and no inertia due to the ropes), and no friction, weight A would rise even without pulling the rope, weight B would remain static, and weight C would drop at the same rate that weight A would go up. If you pulled on the rope you could never make weight C go up faster than weight A until it hit the top and stopped moving. So the pulling bit is a red herring, as weight A would always hit the top before the other two, either pulling or holding it still. Assuming the weights are in kilograms you would have to let the rope go at a rate of 3.13 m/s (11.27 kph, 7 mph) to prevent weight A from rising.

<comment><USER13> If you go with the weights on the floor model, then barrkel's comment a few below is correct.

</comment></comment><comment><USER14> Its not a static system; the question is unfair.

<comment><USER8> Why does that make it unfair?

<comment><USER15> Is the person currently pulling, are the weights on the ground, are the weigths currently moving to get into a stable position? Friction, weight of cord, acceleration, etc. etc. Any combination of the previous?

Depending on your level with maths/physics you'll probably give different answers and make different assumptions.

<comment><USER8> In physics problems things are assumed idealized unless they aren't. Also, velocity doesn't matter here, and no math is required to solve the problem.

<comment><USER15> I didn't know physics problems are assumed to be idealized... When you build a bridge for example, will the physics try to be simplified to the max? (Honest question here).

Velocity would matter -- it seems to me -- if there is friction and probably a few other factors included like elasticity. No?

Personally, I always considered physicists to be applied mathematicians (not the other way around although I've seen physics problems thrown in university level math classes). That's why I put that there, so assuming a high level of math skills, you'd probably change your way of thinking quite a bit.

<comment><USER8> When you build a bridge, that's engineering, not physics. It's a physics convention that unspecified factors are assumed to be unimportant. If they were important, they would be specified.

Anyway, it's implausible that the elasticity of the rope or the friction of the pulleys are going to matter. Unless you have really rusty pulleys, or something.

</comment></comment></comment></comment></comment></comment><comment><USER16> This reminds me of the airplane on the conveyor belt, in that the only confusion comes from the question being insufficiently specified.

      - Friction of the pulleys
      - Mass of the pulleys
      - Moment of inertia of the pulleys
      - Mass of the rope
      - Unit of mass of the weights
      - Is there a surface that the weights are resting on?
      - What's the local gravity like?
      - <USER2>

If we assume the things we're likely supposed to (rope mass, pulley friction, pulley mass and moment of inertia all insignificant, gravity tending down, resting on a surface), it's clear that the lightest weight will rise first. If, on the other hand, we make ridiculous assumptions (weights mass in AMU, in a no-gravity environment, high moment of inertia pulleys), then the "heavy" weight will lift first (because it's easier to lift the weight than to spin the pulleys).

<comment><AUTHOR> The airplane on the conveyor belt is more interesting in this respect, in that different people have different ideas about how the question should be interpreted.

For this question, I think everyone will agree on the likely expected assumptions. Incidentally, the mass of the rope doesn't affect the answer so long as it's uniform, and the mass of the pulleys doesn't matter so long as the pulleys directly attached to the weights all have the same mass. And once you assume the pulleys are frictionless, their moment of inertia doesn't affect the answer either.

<comment><USER16> True. The airplane problem had several things that were ambiguous; this problem only has things that are unspecified.

</comment></comment></comment><comment><USER17> I would love to see a video demonstration of the answer (my intuition was apparently wrong which would make a video that much more entertaining).

</comment><comment><USER18> None. Instead he'll pull the ceiling down as they failed to screw it into the studs. ;-)

<comment><USER19> There's an elephant in the way?

</comment></comment><comment><USER4> The length of the rope is constant. For every weigh with a pulley the weigh moves 1/2 length unit for every length unit it's being pulled. Weights don't matter; C will go up first, then B then A (at a relative 1/2 length ratio).

<comment><USER4> funny the right answer being downvoted without reason

<comment> loup-vaillant You go against the consensus without a solid explanation. For instance, why don't the weights matter? Would they matter if they were respectively 1mg, 1kg, and 1megaton?

<comment><USER4> Fair enough. I gave the summarized version. I'll try to explain better.

I'll only take basic classic mechanics assumptions: that the rope is of constant length (ie is like a cable that doesn't compress or expand). The framework is quasi-static classical mechanics; the results of the guy pulling slowly a little bit can solve the problem or be generalized (I won't consider the situation of the guy jerking quickly the rope etc).

The guy's hand is under a calculable tension Tw that will be 60 units or whatever, it doesn't matter. The problem asks what happens when the guy pulls, so we suppose that he's not the one being pulled but he moves forward to the right. The tension Tg that he applies doesn't matter; as long as it's bigger than the one from the weights (Tg > Tw) he'll move the rope (we discard friction since he moves slowly or if you take into account friction he just needs more force, it doesn't matter). So the distribution of weights or their actual measure don't matter so far. (of course if you have a million tons and you blow the guy away weighs matter).

Now since the cable/rope has constant length (there are no slacks etc since it's moving) when the guy pulls 1mm then than length needs to be taken from somewhere in the pulley systems.

The effect of a pulley is to divide the length of rope you take in two (one has to go to the left vertical part of rope and the other one to the right one); this is why the tension in each side of a pulley is 1/2 of the total tension and you can pull with 1/2T a weight of T with a pulley. So with this we can straightforwardly calculate the tensions everywhere but we don't need that.

So the that 1mm is taken from the system and the more pulleys the rope has to go through the less is taken (because of this 1/2 I explained above), so the weight closer to the guy (with less pulleys) will raise first, then the next one in the middle, then the next one etc; weighs don't matter.

clarification update: poor conclusion wording: if weights are in the air all 3 weights go up at the same time but C will move more than B and B more than A.

<comment><USER8> When a weight is at rest, the tension in the rope must be less then or equal to half the weight. The problem asks which weight will be first to not be at rest. The answer should now be obvious.

<comment><USER4> When a weight is at rest the tension in the rope is _exactly_ half its weight.

Problem asks which weight would be first to _raise_ (not "not be at rest" that could be going down) so that's why I'm supposing the guy can pull the whole thing. I'm also saying the first one is C (closer to guy).

<comment><USER8> The tension in the rope is greater than 30lbs, yet only one weight moves? I give up.

<comment><USER4> sorry; I made an edit with a clarification.

Basically if the weights are at rest on the floor then mkn's answer is the correct one. If they are at rest on the air, then my answer is the correct one.

<comment> loup-vaillant No: <http://news.ycombinator.com/item?id=1659676>

(this comment assumes that the weights are unsupported).

<comment><USER4> I supposed the system was at equilibrium without making the numbers. If it's not (as it seems) then sure, my reasoning is invalid and he's right, no problem.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


CastAR versatile Augmented / Virtual Reality Glasses - <AUTHOR> http://www.kickstarter.com/projects/technicalillusions/castar-the-most-versatile-ar-and-vr-system?ref=live

<comment><AUTHOR> I suspect Jeri can pull this one off, what is interesting to me is the augmented reality aspect, since what I really want is a set of glasses that let me look around the room and high light with a blinking arrow where I left my RFID tagged keys.</comment>