Why Pencils Are Yellow (2017) - <AUTHOR> https://www.artsy.net/article/artsy-editorial-little-known-reason-pencils-yellow <comment><USER2> So the story is, as it is for nearly every physical artifact in my life, "Because people are easily lured by bright objects and catchy marketing into associating quality with anything but the quality of the goods."

I'm reminded of User Testing at Powerset. When we did unbranded search testing of Wikipedia, late-stage Powerset usually won most search comparisons by users. But if we branded the search results against Google, we lost. At first we thought this was an artifact of the test data, but then we ran an experiment where we randomly assigned a brand to our search results and asked users to rank them. Same GvP comparison. The Google branding won. We took it a step further: sometimes random recall searches crept in (there aas essentially no logic to what we put in front of the users other than keyword match). If those got branded "Google", sometimes they still won just by the power of brand association, even against Powerset's sophisticated NL-powered search.

<comment><USER3> > So the story is, as it is for nearly every physical artifact in my life, > "Because people are easily lured by bright objects and catchy marketing into > associating quality with anything but the quality of the goods."

Bright? According to the article, the pencils were painted yellow to symbolize China, because their graphite was sourced from Siberia. (Seems like a stretch, but that's what it says...)

What does brightness have to do with it?

<comment><USER2> It's an adjective. An adjective not uncommonly associated with the hues in question. It's also not uncommon as a turn of phrase in english to say, "people are distracted by the newest bright and shiny object." So I took the opportunity.

Is this... a real question? This seems like a fake question.

<comment><USER4> It's not a fake question, it's question your assertion (which comes with no citation) regarding the origin of the colour yellow used in pencils, which contradicts the origin story described in the article.

<comment><USER2> I'm sorry, but which part of calling the color yellow "bright" conflicts with the article's presented content in any way?

</comment></comment></comment></comment></comment><comment><USER5> Growing up in India, all the pencils I used were red and black striped made by Nataraj. I remember seeing yellow pencils in western movies though.

[https://cwpencils.com/collections/nataraj/products/621-hb- pe...](https://cwpencils.com/collections/nataraj/products/621-hb-pencil)

<comment><USER6> Probably the most common colour in New Zealand is that red and black stripe as well, but usually made by Staedtler[0]. Some other brands also copy the same style[1].

Seems like we need another article on Why Pencils Are Red And Black.

[0] [https://i.imgur.com/AMbEQzT.jpg](https://i.imgur.com/AMbEQzT.jpg)

[1] e.g. [https://i.imgur.com/mmN943m.jpg](https://i.imgur.com/mmN943m.jpg)

<comment><USER7> Yep same in Australia

</comment></comment></comment><comment><USER8> Almost all the pencils in my childhood were red. The manufacturer was Berol.

Of course, my schools didn't necessarily buy the highest quality pencils for the children, and they probably all came from the same supplier.

The high-quality ones, which a relative who was a draughtsman used, were dark green [1]

[1] [https://www.ebay.ie/itm/12-x-Berol-Venus-H-Fine-Quality- Writ...](https://www.ebay.ie/itm/12-x-Berol-Venus-H-Fine-Quality-Writing- Drawing-Pencils-Vintage-White-Tip/123380819314)

<comment><USER9> Across the water in Scotland, the most common pencils in school were black and yellow striped -- the Staedtler Noris, back then made in Wales and stamped "Made in Great Britain". These were the ones the school provided and also the ones parents bought. Still a great pencil today, but no longer made in the UK.

High-quality ones, used by a couple of artists and a draughtsman my parents knew, were blue: Staedtler Mars Lumographs, again made then in the UK, but now only made in Germany. Still an even better pencil than the Noris.

I remember Berol "Handwriting" pens, red with a white nib that produced blue ink, but never liked them or used them much. Berol had colouring pencils sewn up when I was in school.

<comment><USER10> Across yet another pond, in Norway, my childhood school pencils were Norises in primary whereas in secondary we got Lumographs.

I still can vividly recall the sense of awe whenever I entered the storage room in which the school kept all consumables - box upon box of pencils, erasers, rulers, notebooks...

Somewhat of a writing fetishist to this day - I have a box of Lumographs in the office for field notes, whereas meeting notes and such are mostly done with a fountain pen.

</comment></comment></comment><comment><USER11> In my mind, Faber-Castell will forever be the ultimate pencil. I think yellow pencils are a staple of American culture but in my mind pencils are green...

[http://www.fabercastell.com/products/pencils/GraphitepencilC...](http://www.fabercastell.com/products/pencils/GraphitepencilCastell9000Perfectpencilsparepencil/119038)

<comment><USER12> How is this particular item a "spare" pencil? > Spare pencil for the Castell 9000 perfect pencil

Surely any time you buy a new pencil it is a spare or replacement for the pencil you already have?

<comment><USER13> I could be wrong, but I think it means 'spare' as in 'singular' or 'loose', not as in 'replacement' or 'extra'.

<comment><USER14> No it's spare as in replacement. It's a replacement pencil for a pencil holder. That's why it's so short.

</comment></comment></comment></comment><comment><USER15> The article can as well be "Why Pencils are XYZ" where XYZ depends on the country. Once a product is successfull, the original manufacturer and their competitors just continue to copy the attributes of the sucessful product until people can no longer imagine the same product with very different attributes. That is why "Why pencils are yellow" makes sense only in the US, while people living elsewhere are saying: nope, not where I live.

</comment><comment><USER16> Explains my confusion with early internet "cliparts" and icons being always in yellow. I am sure most non westerns might be equally confused.

Pencil meant black and red for us in India - Natraj FTW

<comment><USER17> It's not even Western, from my experience it's just the US. In Australia, I don't think I'd ever seen a yellow pencil, other than one that came in a set of coloured pencils for art. I hadn't realised it was the norm in the US until relatively recently.

We have these, just for example:

[https://www.faber- castell.com/products/GraphitepencilGoldfab...](https://www.faber- castell.com/products/GraphitepencilGoldfaber1221HB/112500)

[https://www.staedtler.com.au/en/products/pencils- accessories...](https://www.staedtler.com.au/en/products/pencils- accessories/pencils/tradition-110-pencil/)

<comment><USER18> Definitely not just US. I'm from Lithuania and these were the pencils we all used [0]. That was around 1992 and later, so could have been a relic from Soviets.

Only in later years green ones appeared and yellow with black stripes.

[0] - [https://thumbs.dreamstime.com/z/lead-pencil-isolated- white-b...](https://thumbs.dreamstime.com/z/lead-pencil-isolated-white- background-51944149.jpg)

<comment><USER19> I distinctly recall yellow pencils in the USSR. Not that it was the only color, but it was definitely a popular one.

Looking it up, apparently this has something to do with pencils being manufactured in early (1920s) USSR by an American entrepreneur:

[https://en.wikipedia.org/wiki/Armand_Hammer#Career](https://en.wikipedia.org/wiki/Armand_Hammer#Career)

[https://i.imgur.com/vpObXqU.jpg](https://i.imgur.com/vpObXqU.jpg)

Eventually the Soviet government bought the entire operation from him, and thenceforth it became this:

[https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE...](https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%B0%D0%B2%D0%BE%D0%B4_%D0%BF%D0%B8%D1%88%D1%83%D1%89%D0%B8%D1%85_%D0%BF%D1%80%D0%B8%D0%BD%D0%B0%D0%B4%D0%BB%D0%B5%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9_%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8_%D0%A1%D0%B0%D0%BA%D0%BA%D0%BE_%D0%B8_%D0%92%D0%B0%D0%BD%D1%86%D0%B5%D1%82%D1%82%D0%B8)

And they probably just continued to use yellow, because why not?

</comment></comment></comment></comment><comment><USER20> I remember all the pencils being yellow in school (in California), some at home being red and maybe also some blue ones, and then in Germany of course a lot of green.

These days the general-purpose pencils I occasionally use are no "color" at all:

[https://www.leadfast.org/blog/2017/8/11/generals-cedar- point...](https://www.leadfast.org/blog/2017/8/11/generals-cedar-pointe- pencil-review)

</comment><comment><USER21> Yes, yellow were the pencils of my childhood. But finally I learned what Koh- i-noor stands for, never bothered to Czech. Pun intended :) CZ citizen here.

<comment><USER22> The article doesn't mention that "Koh-i-Noor" is Persian for "Mountain of Light" [[https://en.wikipedia.org/wiki/Koh-i- Noor](https://en.wikipedia.org/wiki/Koh-i-Noor)]

</comment></comment><comment><USER23> I associate it with these actually: [https://hobbyklei.nl/1816-large_default/bic-potlood- gilbert-...](https://hobbyklei.nl/1816-large_default/bic-potlood-gilbert- blister-van-2-stuks.jpg)

Maybe a Belgian / Netherlands thing? Or perhaps just me :)

<comment><USER24> We did have yellow pens in Germany, but thinking back on it, the forest green of Faber-Castell [0] was the color I would associate with pencils the most.

[0] [https://www.faber- castell.com/products/GraphitepencilCastell...](https://www.faber- castell.com/products/GraphitepencilCastell9000JumboHB/119300)

<comment><USER25> Also blue. Staedler was blue, with a black top.

<comment><USER26> Our school Staedler HB pencils were all yellow and black such as these: [https://www.glsed.co.uk/product/stationery/pencils/blacklead...](https://www.glsed.co.uk/product/stationery/pencils/blacklead/staedtler- hb-graphite-noris-pencils-pack-of-72/g290387)

The occassional ones were red and black, I think those were more likely to be 'B' or '2B' ones, but it's been longer than I can remeber since I used such a pencil.

</comment></comment></comment></comment><comment><USER27> ... except when they aren't.

This reminds me of the famous "why manhole covers are round" question. They aren't, as a quick look at the Wikipedia page can confirm:

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

</comment><comment><USER28> They aren't. Nice bit of local history for Americans though!

</comment><comment><USER29> I think this needs more detail:

 _In China, yellow had long been tied to royalty... Eventually, the shade came to represent happiness, glory, and wisdom._

Was this true outside of China too? Did buyers in the western world really associate the color with Chinese Royalty? Or did they just like the bright color?

<comment><USER30> Disclaimer: pure speculation follows. Ignorance abounds.

In that era, I believe there was an obsessive interest in all things "Oriental". China and Japan were both still very mysterious, with Japan having been forced to open up in the 2nd half of the 19th century, and China similarly unwillingly thrust onto the world stage by the Opium Wars in the same timeframe.

So, it wouldn't surprise me that a company would be able to leverage the interest in China via marketing. Maybe people didn't know of the association with yellow before the marketing, but I'd bet they did after.

</comment></comment><comment><USER31> I was raised in Europe, my pencils were always blue like those:

[https://upload.wikimedia.org/wikipedia/commons/0/08/Pencils_...](https://upload.wikimedia.org/wikipedia/commons/0/08/Pencils_hb.jpg) [http://4.bp.blogspot.com/-2r0Y8HUTeMI/UQVsbzQceKI/AAAAAAAAB5...](http://4.bp.blogspot.com/-2r0Y8HUTeMI/UQVsbzQceKI/AAAAAAAAB5g/PF_Q4SXiQ1k/s1600/staedtlernorica1.JPG)

I was surprised the first time I saw a yellow pencil, like the IKEA ones.

<comment><USER32> Yellow IKEA pencils - in what country? I've only seen unpainted ones (in the UK, and also the US from what I remember, circa 2004-5), with IKEA printed in black on the side.

</comment></comment><comment><USER33> Red and Black stripes. I don't think i've ever held a yellow pencil.

</comment><comment><USER34> article appears to be down, pastebin of google cache: [https://pastebin.com/W7ZXM6Vy](https://pastebin.com/W7ZXM6Vy)

<comment><USER35> easier to read -- [https://telegra.ph/The-Little-Known-Reason-Pencils-Are- Yello...](https://telegra.ph/The-Little-Known-Reason-Pencils-Are-Yellow-10-31)

</comment></comment><comment><USER36> My reading skills are going down. I was expecting a punchline delivery to the reason why pencils are mostly yellow: "Essentially, because of marketing". Just wasted 5 minutes of my life.

</comment><comment><USER37> I'm Czech and never heard about this story. I knew about Hardmuth and why Koh- I-Noor was used, but the story of the color was new to me, thanks!

</comment><comment><USER38> At the time, many yellow paints had lead in them. I wonder of that was the true then... makes me think about chewed-upon pencils.

<comment><USER39> Or cadmium is also a yellow pigment. I do remember chewing on my pencils. Maybe I should get a lead blood test. Or maybe I shouldn't cause it's too late anyway...

<comment><USER40> It may be tough to detect vs the background noise in the United States these days, [https://www.google.com/amp/s/mobile.reuters.com/article/amp/...](https://www.google.com/amp/s/mobile.reuters.com/article/amp/idUSKBN1DE1H2)

</comment></comment></comment><comment><USER41> Because you're a parochial American?

</comment><comment><USER42> My pencils have been plastic and steel as far back as I can remember, with 0.5 mm HB rods in the good ones, and 0.7mm HB in the disposables.

During some tests, some teachers just couldn't believe that HB and #2 were the same thing, so that's about the only time I wrote with painted wood.

<comment><USER43> Fark yeah. I'd give real money to get my 9th grade book bag back! HP 11C scientific calculator, drafting supplies including a bunch of mechanical pencils and fancy erasers, and a copy of the HHGTTG. Pure nostalgia right there.

<comment><USER30> A few years back HP manufactured a few new HP-15C calculators as a limited edition. I was lucky enough to hear about it early and buy one.

I see they're now on Amazon for crazy high prices, so I assume they're no longer in production.

</comment></comment></comment><comment><USER44> Borrowdale is only seven miles from Derwent. Were there other English pencil makers in the area?

</comment><comment><USER45> I'm pretty sure "natural polished" pencils could make a major comeback. Dare I say for the hipsters? Could add an environmental spin on it as well.

</comment><comment><USER46> All my pencils growing up were either red/black or yellow/black, depending on how hard they were.

I miss Staedtler pencils.

</comment><comment><USER47> So it has its origins in bullshit. Great.

</comment><comment><USER48> Koh-I-Noor still makes high quality art supplies, btw.

</comment><comment><USER49> I thought this is because School busss color is Yellow so everything yellow identifies things which has to do with students.

</comment><comment><USER50> "Hardtmuth settled on yellow to communicate the graphite's geographical origins", China because "yellow had long been tied to royalty."

Please stop clickbait.

<comment><USER51> Without the clickbait title, you might have missed the beautiful pop-up that obscures the entire window requesting a subscription.

Nowadays, every page seems to have one of those or the cookie disclaimer. Advertisers and idiotic laws are close to reaching their goal of definitely ruining web experience.

</comment></comment><comment><USER52> I stopped reading and mentally discarded the article as trash upon encountering the phrase "diamonds are graphite".</comment>


Motivate Sharing: A Look at Non-Financial Reward Structures - <AUTHOR> http://blog.getambassador.com/motivate-sharing-look-non-financial-reward-structures/

<comment><USER2> There can never be too much free swag. It's how a startup says to you "don't worry about shopping for clothes this year, I got you covered."</comment>


Dallas data center raided by the FBI based on false claims by former employee - <AUTHOR> http://uwwwb.com/FBIRaid.html

<comment><USER2> I think the problem is the lack of accountability on the govenrment's part. If the leaders of FBI field offices routinely went to jail for raiding data centers unnecessarily (etc.), you can bet that they'd be more careful. But since there is no punishment for ruining someone's life, they are just going to continue to ruin lives. The false negative rate doesn't matter, as long as they occasionally stop a real crime, everyone gets promotions.

(That's my understanding anyway.)

Also, it is unacceptable that nobody will represent this guy in court. As far as I know, the Constitution guarantees a trial and representation at that trial. If he can't get either, then his civil rights are being illegally violated. (Judges may not understand the Internet, but they do understand the Constitution. Well, except for a few people on the SCOTUS that really need to learn how to read...)

</comment><comment><USER3> I think a _lot_ of people will be moving their hosting out of the US because of this.

Unbelievable abuse of power and a total lack of understanding of the nature of this business.

To do this much damage without a shred of evidence is absolutely unforgivable.

The fact that the guy basically assumes that he'll go to prison because he refuses to admit guilt to stuff that he didn't do is quite telling. So much for justice.

This reminds me of the Steve Jackson Games raid.

<comment><USER4> If your servers are hosted overseas, the FBI can probably ask local law enforcement (via some treaty) to seize everything.

<http://www.eff.org/cases/indymedia-server-takedown/>

<comment><USER5> Depends on _where_ you are hosted overseas. I'm sure a host in Iran wouldn't be so eager to comply with the FBI.

<comment><USER6> Are you saying your data would be safer in Iran?

<comment><USER7> Seems like a bit of a toss-up, really.

<comment><USER6> Hacker News is really not the right place for a serious conversation on this topic, and jokes would only lead to a flame war, so I will rather abstain.

</comment></comment></comment></comment></comment></comment><comment><USER8> If you own an apartment building and you are suspected of committing crimes, the government cannot search or sieze the entire building without a warrant for each individual apartment. Each renter has 4th amendment protection and the courts have consistently ruled this way. So if I'm a renter, and you're the police or FBI, you can't get a warrant to seize my property from a judge until you can convince a him that you have probable cause to believe I am involved in a crime (the fact that another renter in the building or the property owner is a suspect is not justification). This same premise applies to storage lockers and other rented space. You can't simply seize an entire rental property. Co-location data centers should function the same way. Our servers are in locked cabinets at our co-lo. We have an SLA and a contract lease with the host. The property in that space is legally ours. Let's hope we never have to convince a court of that.

</comment><comment><USER9> Lesson: The US Government can and will completely fuck you over for any arbitrary reason at any time with no possibility of recourse. I'm sure that's exactly what the founding fathers had in mind.

<comment><USER10> Lesson: Do not live in the US. Just Don't Do It.

<comment><USER11> Agreed. That story sucks.. :-(

</comment></comment></comment><comment><USER12> It sounds like the FBI "acted stupidly" but the guy was no saint. In this thread he gives customer service that actually makes AT&T look good:

[http://voip.yuku.com/reply/421/t/Re-premiervoice-net-aka- pvo...](http://voip.yuku.com/reply/421/t/Re-premiervoice-net-aka-pvoip-net- FRAUD.html)

<comment><USER2> I don't think his post is that bad. Not _nice_ , but sometimes you need to fire your bad customers.

</comment></comment><comment><USER13> If this is a clear cut case of an innocent victim why not call the eff this seems like it is right up their ally?

</comment><comment><USER14> His story is, sadly, very plausible. Has anyone made a serious case that he's lying?

<comment><USER15> Some of the (extensive) reddit comments on the story cast a reasonably amount of doubt on his claims. Unfortunately there's just too many of them for me to be able to quickly summarise the various bits and pieces.

On a side note, I only stopped by to see if reddit had reached digg parity - not there yet, but I'm increasingly glad that I left.

(I nearly used "e-migrated" instead of "left" - and that's just from 5-10 minutes of exposure)

<comment><USER16> "e-migration" is a form of migration done over data lines, right?

Sorry. Couldn't resist.

<comment><USER11> No, its a form of migration done when high on E.

</comment></comment></comment></comment><comment><USER17> It'd be nice to see the "other side" of the story first. Perhaps that is just the cynic in me :)

It does seem an extreme approach!

</comment><comment><USER18> This was on Wired last April:

<http://www.wired.com/threatlevel/2009/04/data-centers-ra/></comment>


Foxxconn opens a hardware accelerator in hopes of finding the next Big Thing - <AUTHOR> http://www.cnet.com/uk/news/inside-innoconn-foxconn-hardware-startup-incubator/

<comment><AUTHOR> Has anyone tried applying? Or was anyone accepted to this program? Would be great to get some insights</comment>


Google Season of Docs – Connecting technical writers with open source projects - <AUTHOR> https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html <comment><USER2> This is wonderful. Most OOS have broken documentation. This will really help alot of people out there.</comment>


Elon Musk's Resume of Failures proves that your failures aren't big enough - <AUTHOR> https://blog.kickresume.com/2017/04/18/elon-musks-resume-of-failures/ <comment><USER2> This article's point is a giant instance of survival bias. How many people went bankrupt when they were ousted as CEO of their own company, and because of that couldn't financially start second, third, fourth companies?

There's also this quote from the article:

> Elon Musk's story proves that once you've mastered the art of failing, > success becomes the only way you can go.

That seems like the "post hoc ergo propter hoc" fallacy: "after this, therefore because of this". Perhaps he got incredibly lucky after failing for a while. Perhaps he was incredibly unlucky while failing?

<comment><USER3> To truly master the art of failing, you'd have to end up dead

<comment><USER4> He's said he wants to die on Mars. He's working towards it; give him time.

</comment></comment></comment><comment><USER5> He may have been ousted from PayPal, but that didn't change the fact that he was a primary share-holder and made hundreds of millions of dollars when it was sold out. Besides the money it also opened up the door for him to move on to bigger and better things. I doubt there are may people aside from Elon Musk who would consider that "failure".

<comment><USER4> Are you saying that either the author of the infographic, or Musk considers the sale of PayPal a failure?

</comment></comment><comment><USER6> If I had millions of dollars to land on in the event of failure, sure I'd take bigger risks.

If the consequences of failure is being homeless, well no, I think I may take the safer route.

</comment><comment><USER7> Yes, clearly all of the poor, homeless people without healthcare just haven't failed enough yet. Why don't they just try harder? It's so easy to be a billionaire!

</comment><comment><USER8> How do you get a McLaren from a failed job-interview at netscape? You need money to be able to affort failure..

<comment><USER9> This article should be taken as motivation one. That even greatest Elon had "bad" times. But those bad times weren't that bad comparing to regular people failures, as he maintained millions on his bank account even at those times. Once he was close to lose almost all, when Tesla needed investment and there was literally nobody who wanted to invest into it. So Elon gambled almost all his fortune to save Tesla. This means only one thing, he don't care about pilling money that much. He is driven by something else.

</comment></comment><comment><USER10> obligatory xkcd [https://xkcd.com/1827/](https://xkcd.com/1827/)

Not talking specifically about Elon Musk, but if you have enough coin to put in the arcade machine, eventually you will win, and you will be able to say "look, you just have to practice again and again" [and to have the financial mean to have an other "continue" at the entrepreneurship game]

</comment><comment><USER11> low quality content designed to be scanned in 23 seconds while waiting for the elevator.</comment>


America's Cities Could House Everyone If They Chose To - <AUTHOR> https://www.nytimes.com/2020/05/15/opinion/sunday/homeless-crisis-affordable-housing-cities.html <comment><USER2> You mean if the government forced people to house each other.</comment>


SimilarTech Technologies Market Share Comparison - <AUTHOR> https://www.similartech.com/compare/angular-js-vs-backbone.js

<comment><AUTHOR> We at SimilarTech are analyzing technologies usage across websites. We've just recently launched new comparison pages, which I'm sharing since I believe they can provide some interesting insights. Please drop your feedback / suggestions.

Some other comparisons -

[https://www.similartech.com/compare/optimizely-vs-visual- web...](https://www.similartech.com/compare/optimizely-vs-visual-website- optimizer) [https://www.similartech.com/compare/facebook-like-button- vs-...](https://www.similartech.com/compare/facebook-like-button-vs-twitter- button) [https://www.similartech.com/compare/weebly-vs- wix](https://www.similartech.com/compare/weebly-vs-wix) [https://www.similartech.com/compare/apache-vs- nginx](https://www.similartech.com/compare/apache-vs-nginx) [https://www.similartech.com/compare/paypal-vs- stripe](https://www.similartech.com/compare/paypal-vs-stripe) [https://www.similartech.com/compare/asp.net-vs- php](https://www.similartech.com/compare/asp.net-vs-php) [https://www.similartech.com/compare/drupal-vs- joomla](https://www.similartech.com/compare/drupal-vs-joomla) [https://www.similartech.com/compare/olark-vs- zopim](https://www.similartech.com/compare/olark-vs-zopim) [https://www.similartech.com/compare/outbrain-vs- taboola](https://www.similartech.com/compare/outbrain-vs-taboola) [https://www.similartech.com/compare/adroll-vs- criteo](https://www.similartech.com/compare/adroll-vs-criteo) [https://www.similartech.com/compare/magento-vs- woocommerce](https://www.similartech.com/compare/magento-vs-woocommerce) [https://www.similartech.com/compare/clicktale-vs-crazy- egg](https://www.similartech.com/compare/clicktale-vs-crazy-egg) [https://www.similartech.com/compare/angular-js-vs- backbone.j...](https://www.similartech.com/compare/angular-js-vs-backbone.js)

And other technologies data can be explored from this page - [https://www.similartech.com/categories](https://www.similartech.com/categories)

Thanks, Eyal. Co-Founder of SimilarTech.</comment>


Ask HN: What does self-hosting mean? - <AUTHOR> Out of curiosity, I went to the wikipedia page https://en.wikipedia.org/wiki/Self-hosting to read up on self-hosting. I run several web services on my own server and was pretty much sure the term means that, but how come the wikipedia article does not even mention this with a single word?
Searching here reveals apparently both use-cases for the term. There is a subreddit /r/selfhosted which in contrast to the wikipedia article only deals with hosting server software.
I wonder if I miss something entirely and what the connection between the two use-cases is, or is there none at all? <comment><USER2> Self-hosting is often used to describe running SaaS products (software as a service) on one's own hardware rather than on the SaaS vendor's servers.

Self-hosting is often important for companies with significant privacy, confidentiality, and security risks or governed by data protection regulations.

Wikipedia is Wikipedia. It improves over time, but these days more slowly.

</comment><comment><USER3> > Self-hosting is the use of a computer program as part of the toolchain or > operating system [...]

There you have it. The article talks about the term from around compilers, not web services.

By the way, what you mean by "self-hosting" is usually described with the term "on-premises software".

<comment><AUTHOR> Ok that is just quoting the wikipedia article, my question though was if that is actually the only correct usage of the term, since searching on google reveals pretty much only what you refer to as "on-premises software". Somehow this is strange to me that so many people are off, thus my question in the first place.

<comment><USER3> > my question though was if that is actually the only correct usage of the > term

Is the meaning of "server" the only correct usage of the word "host"? Because it's the same situation.

<comment><AUTHOR> At least in those situations wikipedia does not have a single answer, which is what I would have expected for self-hosting as well. Especially given the quite different use-cases of it. That triggered my question.

<comment><USER4> The great thing about Wikipedia is that when it's inaccurate or confusing, you can correct it yourself!

<comment><AUTHOR> Indeed. Thought it would be good to get knowledgeable feedback here about the issue.</comment></comment></comment></comment></comment></comment>


Whither Swift? - <AUTHOR> http://lapcatsoftware.com/articles/whither-swift.html <comment><USER2> This article is the best example I've ever seen of how smart people can convince themselves of anything, no matter how absurd, if they want to believe it enough.

The author likes Objective C and doesn't like Swift. That's fine. But he's let that emotional state override his rationality to the point that it totally colors and distorts his thinking.

None of his arguments hold together. They're all speculation based on supposition based on guesswork, and all under-laid by an almost desperate desire that this fantasy will come true, and that Apple will drop Swift. It's like listening to a broken-hearted man explain how his ex-lover will soon return to him. How this is a test that only make their love stronger in the end, etc.

Apple aren't going to drop Swift. It is the future of iOS and macOS development, and the sooner the author accepts that and moves on with his life, the better.

<comment><USER3> I read the entire thing, and didn't get the impression you got. This arricle is pointing out two clear issues for Swift that need to be overcome. 1) that the default language to have the broadest support is obj-c; I see a lot of companies preferring to ship obj-c when they need to support a framework for both obj-c and Swift. 2) Apple needs to more fully commit to replacing code internally with Swift, by say making the decision to stop building new feature support into obj-c and only target Swift.

This is more of a project management issue. It will be interesting to see what Apple ends up doing, but I agree with the article that long term support of both is not in Apple's best interests. Though my money is on Swift...

<comment><USER4> Why are either of those problems?

1) If some developers still prefer to develop in Obj-C, good for them. Of course Obj-C still has the broadest support, Swift is still in the process of taking it's training wheels off.

2) Why should Apple want to replace any of their Obj-C code? If it's good code and works well and a lot of other code depends on it, replacing it just for the sake of it would be pointless.

Partly all this depends on what you consider to be long term. Swift is coming to 3 years old. To my mind 5 years hence is the immediate future. Long term is like 20 years plus.

<comment><USER5> Apple has totally rewrote the dock , in macOS Sierra in Swift.

<comment><USER4> And presumably they had a reason for wanting to do so other than Swift Rulz.

What I'm arguing against is not the idea that new code or new versions of things shouldn't be in Swift. Maybe they should, maybe they would be better in Obj-C on a case by case basis. I'm arguing against the idea that all the existing Obj-C code is an embarrassing legacy that must be purged as a matter of urgency or else we should all start panicking about it.

Heck, large scads of the OS and the application services frameworks are written in plain old C - HealthKit is plain C. Long may that continue. Same for Obj-C.

<comment><USER5> There is a thread on the old Apple Swift forum that addresses why they like Swift. Its an old post from 2014 called : Why Swift? And why now?. You will need at least a free developer account to be able to log in and see it.

[https://devforums.apple.com/message/986257#986257](https://devforums.apple.com/message/986257#986257)

"13 of the security issues fixed in 10.9.4 could have been prevented or mitigated by Swift (9 buffer overruns, 2 int under/overflows, 2 null derefs). That alone makes it worth it from my point of view.

As for performance, that's a work in progress but is improving rapidly; Swift is already faster than ObjC in some cases."

</comment></comment></comment></comment></comment></comment><comment><USER6> He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation.

If you look at the source code of the Swift standard library, "toll free" bridging code is everywhere. It even affects the language design of both Swift and Objective-C.

Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable.

So I think the plan is very clear: Don't force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future.

There is a ton of evidence that they are in this dual mode for the long haul.

I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services.

My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs.

The pressure to make a clean break with Cocoa will grow because some un- idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone.

So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.

<comment><USER7> I agree with you, but just to play devil's advocate, don't forget that Apple spent a lot of time and effort on toll-free bridging between Objective-C and Java back in the day.

Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since.

I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).

<comment><USER6> Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap.

Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.

<comment><USER7> Yeah, the point I was trying to make is just that Apple could easily decide to ditch Objective-C in the relatively near future.

From our point of view as developers, there are good reasons not to, like maintaining backwards compatibility and keeping developers happy, but Apple generally seems to ignore those issues. Not that they actually want developers to be unhappy, they just expect and require them to fall in line.

(Or they could ditch Swift too and go with something entirely new and crazy, but that seems too unlikely even for me)

 _Edit to clarify:_ I think what they _do_ care about is technical issues, and giving themselves the tools to make the slick products they want to make. And their technical strategy is generally pretty sound -- look at their balanced CPU+GPU designs on iOS, for example, both faster and more power-efficient than the ludicrous octo-cores and oversized screens you get on "flagship" Android devices.

To me, making Swift and Objective-C interoperable was a smart decision to give themselves (and coincidentally their developers) a smooth migration path. They also think that reference-counting is _better_ than tracing GC for the types of applications they care about (and I think they're correct). But nothing in that says they care about keeping Objective-C around indefinitely.

</comment></comment></comment></comment><comment><USER8> The author says "Objective-C and Swift cannot continue to coexist indefinitely." but their only supporting argument is that a multi-lingual platform is bad because nobody will know what language to choose.

This is the same charge that has been leveled against Microsoft since they don't use .NET to produce every single piece of Microsoft software. Has that somehow stopped .NET from continuing to grow? No, it has not.

Off-topic: Learned a new word reading this. Lacuna ~ _an unfilled space or interval; a gap._ Thanks!

<comment><USER9> Or JVM...

Java, Groovy, Scala, Closure

Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.

<comment><USER10> Quick spelling correction I think you mean Clojure. You got me searching for a new programming language that has a namespace conflict with a programming concept :) .

<comment><USER11> it's also a way to minify js [https://developers.google.com/closure/compiler/](https://developers.google.com/closure/compiler/)

</comment></comment></comment></comment><comment><USER12> Chris Lattner talked about some of these issues on the Accidental Tech Podcast a few weeks ago: [http://atp.fm/205-chris-lattner-interview- transcript/](http://atp.fm/205-chris-lattner-interview-transcript/)

It was a great episode and is worth the listen for those interested.

On Swift adoption at Apple:

 _" The Swift team itself has specific goals they need to achieve before there can be truly, across-the-board adoption at Apple. ABI stability is the number- one thing [35:30] that prevents framework developers, for example, from adopting Swift. That's a really important thing. That's one of the reasons it's always a really high priority. Swift has been adopted by application developers and other things. The Dock is public. Swift Playgrounds app is public. The Music app in iOS is publicly known. So there are definitely some big adopters.

More broadly though, the big problem is that I think, I won't speak for everybody but many, many people doing [36:00] Objective-C development at Apple are chomping at the bit. They want to be using Swift. It's really just a matter of getting the technology problems solved and checking off the things that are holding people back. It's not about people dragging their feet and not wanting to use it."_

On whether to adopt Swift now:

 _" I don't [1:14:30] think Objective-C is going to go away anytime soon. Apple still supports C and C++ and there's no obvious benefit of dropping Objective-C, and obviously they have a ton of Objective-C code themselves."_

He also described Apple's approach to some of the strategic questions that arose early on, such as whether to just invest in making Objective-C better instead of introducing Swift, and the various trade-offs involved.

</comment><comment><USER13> > Apple could convert its entire Objective-C code base to Swift if they > wanted. They certainly have the resources. The amount of liquid assets they > own is staggering, of a size unprecedented in history. Nevertheless, their > current corporate culture suggests they cannot or will not perform this > conversion.

But _why_? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to. Bloomberg still has 25m lines of FORTRAN [0] — there's no need to rewrite code when it works fine already.

[0] [https://etrading.wordpress.com/2006/06/01/25-million- lines-o...](https://etrading.wordpress.com/2006/06/01/25-million-lines-of- fortran/)

<comment><USER14> _> But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to._

The functional mDNSResponder was rewritten and replaced with discoveryd, causing networking issues for millions of users. The popular Final Cut Pro was rewritten with FCPX, shedding many of its features and most of its userbase. The powerful and flexible QuickTime application and framework were rewritten and replaced with QTX, losing almost all of their functionality in the process. syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.

Throwing away working code and rewriting it, of late most often for the worse, is something of a habit at Apple.

<comment><USER15> > syslog(1) was deprecated and replaced with log(1), a more verbose and > difficult to use tool, for no discernible reason.

The new log store contains (or tries to) every old file in /var/log and every log-level flag in the system, so you can search them all in one timeline. It also improves privacy because all the %@ formats can be censored after a short time.

</comment></comment></comment><comment><USER16> His whole argument is that if Apple had to pick one language today, it would be Objective C because internally they have largely stuck with Objective C up to now.

Well, Apple isn't going to pick one language today. They might deprecate Objective C in 5 or 10 years, but in the near term nothing should change. They're infamous for dropping "legacy" so I wouldn't rule out Objective C having a finite lifespan.

The author is right that the developer community has really embraced Swift. It is a much nicer language, with a lot less visual noise, for example.

As a quick aside, I've been working on a Cookbook for the Swift:

[http://www.h4labs.com/dev/ios/swift_cookbook.html](http://www.h4labs.com/dev/ios/swift_cookbook.html)

And I've been adding to a Github repo with lots of little examples:

[https://github.com/melling/ios_topics/blob/master/README.org](https://github.com/melling/ios_topics/blob/master/README.org)

Finally, the Stanford CS193 course has start for Swift and iOS 10:

[https://itunes.apple.com/us/course/developing-ios-10-apps- sw...](https://itunes.apple.com/us/course/developing-ios-10-apps- swift/id1198467120)

</comment><comment><USER17> Apple uses many languages internally. And swift & objective-c are very close in programming models in many ways. It's pretty natural for an ObjC dev to learn swift and vice versa I would imagine. If apple is having a hard time find new objective-c dev, but has swift devs, it will just train them.

A lot of code is in C++ at apple, like most of their graphics, UX & networking. Drivers in C. A lot of apps are non-ARC objective-C still and so on.

Also swift is not a solid enough language yet. Debuggers, compiling & indexing are too slow & unstable and there are things like ABI stability that are not delivered yet. I would give swift ~4+ years before it would be something to consider replacing Objective-C completely.

</comment><comment><USER18> Microsoft has managed to keep VB and C# alive and well supported even though its major codebases are in C++.

I don't think it's as big of a problem as the author seem to think it is.

<comment><USER19> Actually even though C++ has first class support on UWP, I have noticed that the language focus at Microsoft developer presentations is showing it more for lower layers of the OS and games, with C# and VB being targeted for apps development, with F# getting the data science part.

<comment><USER20> F# isn't really aimed at data science, thats a common misconception ( I believe MS has ceased describing it that way). It's basically just a general purpose, functionally oriented language.

<comment><USER19> When they finally support it the same way as VB and C#, including the GUI tools, UWP, and some of the MSDN documentation about .NET, and above all when the F# community stops doing presentations about type providers as the single killer feature, then it will be a general purpose, functionally oriented language.

Currently I cannot use F# on UWP until .NET Core 2.0 gets released, cannot use the same workflows with Blend and Visual Studio as I do for C#, and while type providers are cool, I have zero uses for them.

<comment><USER20> Yeah, I have no arguments here. If you're goal is a friction-less integration with Microsoft tooling and projects, F# is not the way to go (definitely C#). F# practitioners would do better to position themselves as just a language in it's own right, not necessarily an 'alternative to C#'.

Sort of like Elixir compared to Erlang.

</comment></comment></comment></comment></comment><comment><USER21> I think the plan has always been that Swift is the future, but Objective C will be around for a long time. Think a 30-year horizon.

<comment><USER22> I would agree with this. I'm imagining Obj-C to eventually be Apple's COBOL. Even presently, a lot more job postings regarding iOS development are expecting Swift experience than even a year ago.

</comment></comment><comment><USER23> The piece is really well written and makes some good points (especially about Apples code base, the costs of rewrites, etc.)

I'm still perplexed by the argument that there are boxes like "Objective-C programmer" or "C++ programmer" and that this categorization is a good abstraction for thinking about these problems. In earnest, nobody working as a developer can expect to use the same tools in 5-10 years that they are using today, especially in fields like mobile.

It's not that hard to learn a new programming language if the paradigms are known from another language. Swift is not that different from other imperative languages that there would be a particularly bad learning curve.

</comment><comment><USER7> This is nothing but inconclusive speculation. It mostly focuses on whether and when Obj-C will be retired, so the title should really be "whither Objective-C?"

</comment><comment><USER24> What I dislike about this situation is that Apple wants me to make software that only works, or works best, on their device. I want to make software that is as portable as possible. I don't want my next programming language to come from someone who wants to lock me in. This makes me uncomfortable with Swift.

<comment><USER25> Like Objective-C is a realistic choice anywhere but on OSX...

If you play with Apple, you can only ask how high you have to jump. They will certainly not help you write cross-platform code, if they can avoid it. They practice lock-in very aggressively at all levels.

<comment><USER26> Yeah, it really was sneaky of Apple to convince NeXT to write their development framework in Objective-C a decade before they acquired them.

<comment><USER19> NeXT had a portable version of NeXTStep for Solaris and Windows, called OpenStep.

</comment></comment></comment></comment><comment><USER27> First off, I was always a huge obj-c fan, but I can tell you from first hand development of what is most certainly the largest and most complex pure Swift source tree that Swift has many serious advantages over obj-c. I am convinced we could not have such a stable product so quickly without it. It has immensely improved productivity. It has some shortcomings still and sometimes you do miss obj-c's dynamic dispatch, but on the whole Swift is far more than an evolution. I think Apple is definitely on the right track and you will see obj-c getting deprecated within the next 5 years or so. As others have mentioned, ABI stability is the number one issue preventing Apple from rewriting frameworks in Swift.

<comment><USER28> How can our apps be stable when compiler is not stable.

</comment></comment><comment><USER29> As far as I know all of Apple's framework code is in Objective-C, and there are two big problems standing in the way of converting it to Swift: AppKit and the like still has to support 32-bit apps (and it's apparently challenging to back-port that support to Swift) and Swift doesn't yet have ABI stability. (source: the SWIFT ADOPTION AT APPLE section here: [http://atp.fm/205-chris- lattner-interview-transcript/](http://atp.fm/205-chris-lattner-interview- transcript/))

<comment><USER30> There are a lot more challenges than just ABI and 32 bit. Swift is not dynamic, lacks many of the features the ObjC runtime provides - so most of Apple's frameworks cannot actually be implemented in the same way with Swift. Basic stuff like KVC, KVO, responder chain, etc. go out of the window. And many of Apple engineers are not convinced throwing these technologies out of the window for some imaginary benefit from Swift is the right direction.

</comment></comment><comment><USER31> This author has also forgotten about the annotations that Apple has provided to make interoperability between Swift and Objective-C quite a bit easier. See "Swift API Design Guidelines" from WWDC 2016.

Moving on ... "If Apple had to deprecate one of the two languages today, which would they deprecate?" Why is that even a question? I don't understand the motivation here. What if Apple had to decide between mobile hardware and desktop hardware? I guess they'd drop everything that wasn't the biggest revenue generator...

<comment><USER4> Well exactly. Apple is opening a lot of stores in China with employees all speaking Chinese. Were all told 'China is the future'. Suppose Apple decided to standardise on one language for all their store. What would it be, English or Chinese? Equally daft.

If we take this perfectly sensible option, for which there is no obstacle to Apple pursuing it and which is Apple's stated intent off the table, which of these remaining bone headed options do you think Apple will choose? Er, who cares?

</comment></comment><comment><USER32> >* If 2 was the plan, I really wish Apple had been more forthcoming about it. The message from Lattner would have been misleading at best. If Swift is the future, why not be absolutely clear with developers about that, and let us plan accordingly*

Because it's nowhere near a short or even mid term thing? It will take a decade or more to be able to move to Swift 100%, and even then, it will came with ample warnings years ahead to port your Obj-C code over.

</comment><comment><USER33> > And of course Lattner has now left Apple, so he won't be there to take the > criticism if his claim turns out to be false.

IIRC he said that he's going to still be on the core team of the language. I don't remember the email (and I can't find it right now) but I had the impression that for me, as a user, very little actually changed.

<comment><USER34> "This decision wasn't made lightly, and I want you all to know that I'm still completely committed to Swift. I plan to remain an active member of the Swift Core Team, as well as a contributor to the swift-evolution mailing list."

[https://lists.swift.org/pipermail/swift-evolution/Week-of- Mo...](https://lists.swift.org/pipermail/swift-evolution/Week-of- Mon-20170109/030063.html)

</comment></comment><comment><USER35> It's in Apple's best interest to continue supporting both. Why? Let's just remove the POV of app developers and simply look inside Apple.

The article mentioned a very important point. Apple itself has not adopted Swift as fast as the developer community. This is because (I don't know this for a fact, but am quite sure), a large portion of hw/sw engineers know how to write C, C++, and Obj-C. They don't just know how to write it, I bet a lot of them are damn good at it and if not, top in the industry. Why convert? As many mentioned in the comments, it would be a huge overhaul and what about Apple's internal engineers? Would they put themselves out of a job?...Not likely.

Maybe in 20 years (if there still is an Apple...), there will mostly be Swift engineers. I just don't see them shooting themselves in the foot by removing obj-c in the near future (as in 5-10 yrs).

</comment><comment><USER36> This is a bad argument. Just because there's a lot of chatter about Swift, doesn't mean there's more Swift code than ObjC out there. Of the 31 apps I have installed on my jailbroken phone, 9 contain libswift libraries. Of course, that doesn't even mean the entire apps are written in Swift; most of the uses I see are for app extensions probably because they're a more recent addition. Worse on my Mac – 7 out of 94 non-Apple apps installed.

You don't throw away good code just because "eh, I like Swift better". Couldn't imagine having to justify rewriting good code to my employer. If it works, you keep shipping it till it breaks, then when it does break you spend a while fixing it and continue shipping it. Only when that becomes unviable do you consider rewriting it, and depending on the developer/project situation that may very well be in Swift.

Microsoft fell into the trap of rewriting good code with the failed Windows Longhorn project – for what was meant to be a minor release, they burned a heap of time rewriting large portions of Explorer (taskbar, start menu, folder windows) in C#. Explorer in all beta releases since the rewrite began were very unstable. They scrapped it and kept the existing C++ codebase. Fast forward now, Explorer still runs great in Windows 10 with the same C++ code, right? See also the Joel on Software article everyone usually links when this topic comes up: [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

Music, Calculator, and a minor part of the new Messages app were rewritten in Swift in iOS 10. Dock was supposedly rewritten in Swift in macOS Sierra, ditto Notification Center. Plenty of Touch Bar code is Swift. I think the fact that they've _started_ to use Swift with new non-framework code is pretty important. But I'm certain there will still be ObjC in service for way longer than Apple removes its last line of it from the codebase. It can't just be phased out like Rosetta or Carbon, especially when 3rd party apps are what keep iPhone sales up.

</comment><comment><USER37> Eventually most of the open source libraries will be Swift based, therein lies the answer, for the developers and for Apple. Apple doesn't need to drop Objective-C, the community will. I work with both, and like them both, although Swift is far better language.

</comment><comment><USER38> First off, this is very well written. Secondly, I'd like to state that I think that Objective-C and Cocoa were _really_ good. I disagree with most of the design paradigms _today_ , but I think the Objective-C/Cocoa ecosystem represented something approaching a local maxima in the mutable programming space. Maybe not even a maxima, as I was actually really happy with the direction it was going pre-Swift (KVO was starting to get good in NSTreeNode, the language additions were welcome, etc.)

All this to say: I think the Swift transition was really misguided, and I was incredibly surprised that that wasn't the general take at the time. Everything about it seemed not well-planned out: the fact that no one at Apple had heard of it (you have the world's best ObjC programmers in-house and don't bother to get internal buy-in first!), the fact that it was really a response to C++ not Objective-C (this is so clear when listening to Lattner, who incidentally, did most his programming in C++ it seems), the fact that they sold it as good for everything from scripting to systems programming (huge red flag), and on and on.

But the real concern here was the opportunity cost. What was the problem they were trying to solve with Swift? That square brackets were off-putting? That a group that until that point were totally bought into dynamic dispatch should switch gears completely to a strict typed language? If you ask me, the only goal that _should_ have mattered was making _development_ easier and expanding the scope of people that could approach the platform. And, for the record, I am sure they believe they attacked this problem, I clearly disagree however.

I think the real areas ripe for improvement were the tools. Look no further than Facebook, with React Native and the no-recompile workflows where you change the UI and see it instantly on your device. _This_ would have been game changers in making development easier, not adding Maybes (and this is coming from someone who does immutable development now). Objective-C could have been _evolved_ into the language they wanted. It would have probably taken just as long as however long this "transition" is going to take, and it would have given everyone immediate actionable benefits instead of being a binary switch that comes along with the pain of having to ship the runtime.

Instead, we have discussions about whether _Foundation_ is going to be rewritten in Swift. This seems like such an incredible misprioritization. Essentially creating a situation for yourself where you _have to_ burn everything down and start from scratch, all while in the meanwhile have the head-scratching platform where the base libraries are written in a dynamic language and user land code is a strict systems language.

The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Rust guy, and he WILL tell you the reason to use Rust. Talk to a Haskell person and they'll do the same. The sole reason for Swift seems to be "to take over the world". It is decidedly not a very opinionated language in that regard. In the ATP interview, Lattner even said that dynamic dispatch may be added later to Swift so no one should worry about it, it seems like such a kitchen sink. (I loved the bit where he said that if they add in multiline string literals they can probably "win" the scripting space). Not a lot of passion there.

<comment><USER39> > The last thing I'll mention is the worrying lack of "purpose" for Swift. > Talk to a Haskell person and they'll do the same.

Really? Real type safety and no null pointer exceptions unless you really want it are not a purpose? A compact syntax that is still as descriptive as Objective-C's syntax?

My programs are _much_ more stable in a lot of regards since I started using Swift.

<comment><USER38> I do not believe stability was the problem in iOS land (from my personal _user perspective_ ). The problems with iOS apps I experience most frequently come from a lack of handling asynchronous events and state management. I can frequently get programs into weird states due to clearly not handling edge cases in the way animations finish, or things loading before something else is ready, etc. I think attacking asynchronous flow management (the way countless other languages like JavaScript and Python and C# have with async/await for example) would have really demonstrated and understanding of the key space this language was going to be initially used for. Instead, async primitives are going to be missing for at least another version of the language, and programmers will remain using very primitive synchronous tools for managing increasingly complex asynchronous states demanded from ever more animation- heavy and internet-talking apps. I believe investing in asynchronous language additions for Objective-C would have lead to much more stability from a user perspective. And they aren't even mutually exclusive, Objective-C was already moving in the direction of more type safety and could have continued down that path.

Separately, I think people that have used languages like elm or Haskell would argue that Swift does not present a particularly strong example of "real type safety". Both from a language perspective (yes certainly stricter than some languages, but not as strong as others), but also from a culture perspective. Haskell/elm people I think have a true culture of correctness in code (and arguably Rust as well from the type-for-ownership-safety perspective), which Swift does not particularly share as far as I can tell. Don't get me wrong, it is in fact "stronger" than Objective-C, but I don't think its the slam dunk go-to language for mission critical software, or guaranteed to be safe software either mind you. Again, I think an _indicator_ of this is the fact that the creator is convinced it could rock both systems programming AND scripting. I think most other languages, if asked the big "why?", would tell you THE raison d'être for its existence. Aside for "the standard language for iOS apps" default answer, I don't get a strong sense of that from Swift, if I did, I think there would be a lot of work in "Swift is for X, we don't want to be distracted by Y right now" (I think many people want to write server code in elm, but they staunchly want to NAIL UI programming, Rust wants to NAIL systems programming with safety, etc.) With Swift its always "oh once we add this feature, then it'll be perfect for that too".

<comment><USER40> > I do not believe stability was the problem in iOS land (from my personal > user perspective)

This. (And the parent). Almost everything that's an improvement in Swift rated at best a "nice to have" in my experience with development pain points.

And what's really surprising is that, due to the flexibility of Objective-C, we actually _had_ some fairly good ideas of where those pain points were: all the places runtime-dynamicism/metaprogramming was used to "extend" the language.

So address these points, and better yet, create better metasystems that allow users of the language to tackle these issues with less hackery.

Instead, pretty much _crickets_ on all of these fronts, and at best grudging incorporation of minimal bridges to those same hacks. Wut?

Instead a "playground" for the compiler to show how incredibly smart it is.

</comment></comment></comment></comment><comment><USER39> Objective-C(++) are not going anywhere. I would start a new project in one of both languages without hesitation. It works, it's stable, there's tons of software out there and last but not least it's compatible with Swift.

</comment><comment><USER41> I don't see any reason that Obj-C can't stick around for a long, long time, even if Swift is the "preferred" language.

Also, rumors of first-class support for Swift as a .NET family language are very interesting and would make the language much more realistic for cross- platform work. That could even lead to Unity support which would make me sooo happy. But I'm not the typical use case for sure.

</comment><comment><USER42> > The application development environment for C was not Cocoa but rather > Carbon, and Carbon has been largely deprecated.

This might be the template for the transition from Objective-C to Swift. I would be interested in the author's thoughts on that -- how is it similar or different? One could see a situation where Objective-C is still there, like C, just not of interest to most app developers.

</comment><comment><USER43> Conversion to Swift is not something that must be done 100% at once (due to reuse of the Objective-C back-end), nor is it wise to change quickly (due to source _and_ binary incompatibilities that have been very clearly documented for the first few Swift versions). Slow-moving engineering teams, even within Apple, are just being wise; they can still be firmly behind the move to Swift.

</comment><comment><USER44> Does Swift support Windows and Linux?

If not, Swift will be doomed to be an Apple-specific language.

<comment><USER45> Swift officially supports Linux, and there is unofficial Windows support (and I remember them saying they planned to support Windows officially, though I don't know if that's still a goal).

<comment><USER46> The Swift support on Linux is the bare minimum required to say "Swift supports Linux". I seriously doubt that Swift will ever be any more "portable" than Objective-C. That is, Swift, like Objective-C, is portable in theory, but nobody uses it for anything except to write programs for Apple's iOS/macOS platform.

<comment><USER47> Ibm has extensive support for swift on linux, and seem to be pushing it as a first class solutikn for thier linux based develooment.

[https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura...](https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura_a_swift_web_server_framework_for_linux/)</comment></comment></comment></comment>


Firefox 73 Adds Support for Site Specific Browser (Web App) Mode - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=1602168 <comment><AUTHOR> Works in Firefox 73. To enable it add "browser.ssb.enabled" preference with boolean value of true. Restart Firefox and in "Page actions" (three dots in URL bar) new menu item "Launch Site Specific Browser" will appear.

Nice to see PWA support finally (though slowly) coming to Firefox.</comment>


Apache Spark 1.0.0 - <AUTHOR> http://spark.apache.org/releases/spark-release-1-0-0.html

<comment><USER2> For new entrants, here's an email I sent out to some colleagues of mine just getting into ML. I'm wrapping up a project that's using Mahout, and am getting into Spark & MLlib now. I've regurgitated this on reddit already.

I've been following Apache Spark [0], a new-ish Apache project created by UC Berkeley to replace Hadoop MapReduce [1], for about a month now; and, I finally got around to spending some time with it last night and earllllllly this morning.

Added into the Spark mix about a year ago was a strong Machine Learning library (MLlib) [2] similar to Mahout [3] that promises much better performance (comparable/better than Matlab [4]/Vowpal Wabbit [5])

MLlib is a lower level library, which offers a lot of control/power for developers. However, Berkeley's Amplab has also created a higher level abstraction layer for end users called MLI [6]. It's still being actively developed, and although updates are in the works, they haven't been made available to the public repository for a while [7]

Check out an introduction to the MLlib on youtube here: [https://www.youtube.com/watch?v=IxDnF_X4M-8](https://www.youtube.com/watch?v=IxDnF_X4M-8)

Getting up to speed with Spark itself is really pain-free compared to some tools like Mahout etc. There's a quick-start guide for Scala [8], a getting started guide for Spark [9], and lots of other learning/community resources available for Spark [10] [11]

[0] [http://spark.apache.org/](http://spark.apache.org/)

[1] [http://hadoop.apache.org/](http://hadoop.apache.org/)

[2] [http://spark.apache.org/mllib/](http://spark.apache.org/mllib/)

[3] [https://mahout.apache.org/](https://mahout.apache.org/)

[4] [http://www.mathworks.com/products/matlab/](http://www.mathworks.com/products/matlab/)

[5] [https://github.com/JohnLangford/vowpal_wabbit/wiki](https://github.com/JohnLangford/vowpal_wabbit/wiki)

[6] [http://www.mlbase.org/](http://www.mlbase.org/)

[7] [http://apache-spark-user- list.1001560.n3.nabble.com/Status-o...](http://apache-spark-user- list.1001560.n3.nabble.com/Status-of-MLI-td3610.html)

[8] www.artima.com/scalazine/articles/steps.html

[9] [http://spark.apache.org/docs/latest/quick- start.html](http://spark.apache.org/docs/latest/quick-start.html)

[10] [http://ampcamp.berkeley.edu/4/exercises/](http://ampcamp.berkeley.edu/4/exercises/)

[11] [https://spark.apache.org/community.html](https://spark.apache.org/community.html)

</comment><comment><USER3> Note that Spark 1.0.0 makes it possible to trivially submit spark jobs to an existing Hadoop cluster.

It leverages HDFS to distribute archives (e.g. your app JAR) and store results / state / logs, and YARN to schedule itself and acquire compute resources.

It's pretty amazing to see how you use Spark's API to write functional applications that are then distributed across multiple executors (e.g. when you use Spark's "filter" or a "map" operations, then the operation potentially gets distributed and distributed on totally different nodes).

Great tool — exciting to see it reach 1.0.0!

<comment><USER4> Do you mean SIMR or something another ?

</comment></comment><comment><AUTHOR> I gave a 30-minute overview of Spark yesterday at StampedeCon. Spark is generating a lot of excitement in the big data community:

[https://speakerdeck.com/stevendborrelli/introduction-to- apac...](https://speakerdeck.com/stevendborrelli/introduction-to-apache-spark)

</comment><comment><USER5> I wonder if anyone with experience with Spark can comment / rebut this post: [http://blog.explainmydata.com/2014/05/spark-should-be- better...](http://blog.explainmydata.com/2014/05/spark-should-be-better-than- mapreduce.html)

<comment><USER6> I use spark a lot and my experience has been quite the opposite. The queries I run against spark are billions of events and results are sub-second.

I could only speculate as to what this users issues were. One difference between hadoop and spark is that it is more sensitive in that you sometimes need to tell it how many tasks to use. In practice it is no big deal at all.

Perhaps the user was running into this- the data for a task in spark runs all in memory, whereas hadoop will load and spill to disk within a task. So if you give a single hadoop reducer 1TB of data, it will complete after a very long time. In spark if you did this you would need to have 1TB of memory on the executor. I wouldn't give an executor/JVM anything over 10GB. So if you have lots of memory, just be sure to balance it with cores and executors.

I have seen spark use up all the inodes on systems before. A job with 1000 map and 1000 reduce tasks would create 1M spill files on disk. However that was on an earlier version of spark and I was using ext3. I think this has since been improved.

For me spark runs circles around hadoop.

<comment><USER7> >The queries I run against spark are billions of events and results are sub- second.

This is interesting, I haven't gotten Spark to do anything at all in less than a second. How big is this dataset (what does each event consist of)? How is the data stored? How many machines / cores are running across? What sort of queries are you running?

>I could only speculate as to what this users issues were.

I'm the author of the above post and unfortunately I can also "only speculate" what my issues were. Maybe Spark doesn't like 100x growth in the size of an RDD using flatMap? Maybe large-scale joins don't work well? Who knows. The problem, however, definitely doesn't seem to be anything from the tuning guide(s).

<comment><USER6> > How big is this dataset (what does each event consist of)?

Standard clickstream data, maybe 50-ish parameters per event.

> What sort of queries are you running? > How is the data stored?

Depends on the use-case. For sub-second adhoc queries we go against bitmap indexes. Other queries we uses RDD.cache() after a group/cogroup and answer queries directly from that. For other queries we go hit ORC files. Spark is very memory sensitive compared to hadoop, so using a columnar store and only pulling out the data that you absolutely need goes a very long way. Minimizing cross-communication and shuffling is key to achieving sub-second. It's impossible to achieve that if you're waiting for TB of data to shuffle around =)

> How many machines / cores are running across?

Depends on the use case. Clusters are 10-30 machines, some we run virtual on open stack. We will grow our 30 node cluster in 6mo.

> Maybe Spark doesn't like 100x growth in the size of an RDD using flatMap

You may actually just need to proportionally scale the number of partitions for that particular task by the same amount. Also when possible use mapPartitions, it is very memory efficient compared to map/flatMap.

> Maybe large-scale joins don't work well

Keep in mind that what ever happens per task happens all in memory. For large joins I created a "bloom join" implementation (not currently open source =( ) that does this efficiently. It takes two passes at the data, but minimizes what is shuffled.

<comment><USER7> > For sub-second adhoc queries we go against bitmap indexes.

Did you implement the index yourself? How many events survive the initial filtering?

</comment></comment></comment></comment></comment><comment><USER8> Spark is an interesting technology, from what I've heard it doesn't actually have traction in industry yet though.

Anyone here actually using it in production? I know it's blazing fast etc, and I like it as a map reduce replacement. It has all the makings of a great distributed system, I'm still waiting to see a major deployment yet..

<comment><USER6> May be of relevance: [https://cwiki.apache.org/confluence/display/SPARK/Powered+By...](https://cwiki.apache.org/confluence/display/SPARK/Powered+By+Spark)

I don't know what you would count as major deployment, but I've deployed a 30-node cluster on HW for running sub-second real-time adhoc queries. I've also run many smaller 10-20 node virtual clusters on open stack. It is a rock solid platform. Our hosted ops loves it because it just works.

The amazing thing about spark is how insanely expressive and hackable it is. The best way I can describe it is this:

* Hadoop: You spend all of your time telling it how to do what you want (it is the assembly language of bigdata)

* Spark: you spend your time telling it what you want, and it just does it

<comment><USER8> This does help actually. And yes: it doesn't have to be a 1000 node cluster or anything crazy. I've just talked to a lot of people at bigger companies and they've all said it falls over yet.

Great to hear success stories!

</comment></comment></comment><comment><USER9> Any active Clojure bindings?

clj-spark seems to be abandoned (last commit was a year ago)...

<comment><USER10> I'm curious about this too--clj-spark didn't work for me so I'm currently prototyping a job using the Java bindings in Clojure. If I end up wrapping the Java bindings in a useful way I would consider putting together some kind of release if there's community interest in that.

<comment><USER11> Me too.

However, shouldn't there be a much more flexible approach where you just send your functions to an execution server (just like an agent)? You might want to define some keywords to refer to previously used functions or data.

Then again, such an agent would be pretty much a REPL, so you might just want to ssh to a REPL that does load balancing and has sub-repls (on other machines) that fail over.

Thoughts on that?

</comment></comment></comment><comment><USER12> Great to see Spark hitting 1.0.0. You can actually run Spark on Elastic MapReduce pretty easily - check out our tutorial project for how: [https://github.com/snowplow/spark-example- project](https://github.com/snowplow/spark-example-project)

</comment><comment><USER13> Great...new era of distributed computing</comment>