Silicon MacBook could launch on 27 October and cost $800 - <AUTHOR> https://www.macworld.co.uk/news/mac/silicon-macbook-could-launch-on-27-october-cost-800-3793534/ <comment><USER2> Bringing the 12" MacBook back with Apple Silicon for $800 could be huge. First of all, the 12" MacBook was the dream portable machine, especially being fanless. However, the processors where really to slow and the price to high.

I guess, the 12" MacBook was designed on a promise of Intel of delivering processors, they never could deliver due to the issues with their 10nm process. This is where an ARM based design around the iPad processor would be an instant win performance wise.

But it is also great news, if Apple really uses the costs saved by going with their own CPUs to offer the machine at a lower price. Suddenly, it can compete with a lot of branded laptops on the price alone. With the additional speed from the processors, it should be quite a good general purpose laptop. And we know how nice the 12" MacBook was from a design perspective.

For the consumer market, the ability to run iOS apps becomes an additional huge benefit. For more and more people, the smartphone is the default computing platform, especially for younger people, the smartphone might be the device they get into computing at all. So when bying a laptop to go along with your smartphone, the Mac running Apple Silicon has a huge benefit, as it integrates more seamless than ever with your smartphone.

I would expect the Mac market share to get quite a boost as a consequence.

While the MacBook is the obvious machine to equip with Apple Silicon for the reasons listed above, I would also expect Apple to hit the market with a true developer machine just so that developers can not only test their software on Apple Silicon, but that it becomes the development platform right from the start.

<comment><USER3> I still raise an eyebrow whenever Apple pushes running iOS apps on Mac as a big plank of its desktop strategy. SwiftUI is still incomplete, badly documented, and a bit of an arse to work with. A shame, because it has the potential to be really enjoyable to work with. But until they sort that out, this whole strategy of theirs seems half baked.

<comment><USER4> This is the only part of their strategy to me that I don't understand. Running unmodified iOS apps on a Mac is going to be such a terrible experience and there's no way around it. Why? Just because they can?

<comment><USER5> Ipad apps on a mac laptop with touchscreen would be great. And some of the design changes in MacOS 11 look like they are making mac UI elements touch accessible.

<comment><USER6> also a transformer to macbook way thinkpad had their models with keyboard folding to the back also would be nice.

</comment></comment></comment></comment></comment><comment><USER7> Apple Silicon feels like the most exciting 'Apple computer' news since the launch of the Macintosh.

Typing this from a 16-inch MacBook Pro that cost me $5k, I know Apple loves to make money via raw sale price of premium hardware. Imagine what power they'll be able to pack into such a price once they apply Apple Silicon to the MBP. I'm thinking 128 or even 256 GB RAM, extraordinary processing speed options that are orders or magnitude faster than any other laptop (or even desktop), it's major major news.

The big question mark hanging over it is ability to run native Linux. I'm a Linux user, increasingly. We'll have to watch this space.

<comment><USER8> > The big question mark hanging over it is ability to run native Linux.

I wouldn't not be surprised if Apple took every measure possible to make it impossible to run Linux on their new machines.

<comment><USER2> It is not clear to me, why they would care much about it. The selling point of Macs is to a large amount macOS. On the other side, at least for now, it is announced that Apple Silicon hardware only boots into signed operation systems, which currently is only macOS. I would assume, that means there is little chance to run Linux natively on Apple Silicon. On the other side, virtualisation technology is part of macOS, so there should be good support to run Linux inside a virtualized environment. They even showcased Linux during the keynote.

<comment><USER8> we'll see.

for the moment, most people i know complain about poor performances of linux vms in mac os, particularly when running docker (that gets pretty i/o intensive when dealing with images).

> at least for now, it is announced that Apple Silicon hardware only boots > into signed operation systems

this alone already rules out gnu/linux i guess?

<comment> yjftsjthsd-h It really depends. After all, there are UEFI x86 systems using secure boot to boot Linux, but there was also Microsoft's vision of ARM (spec outright prohibits user managed keys, and nobody's shipping with anything but Microsoft keys).

<comment><USER9> > but there was also Microsoft's vision of ARM (spec outright prohibits user > managed keys, and nobody's shipping with anything but Microsoft keys).

Indeed. "Microsoft <3 Linux" they say. Right...

</comment></comment></comment></comment></comment></comment><comment><USER10> A MacBook carved out of a single, atomically perfect crystal of silicon.

Heavy as fsck but oh so pretty.

Just don't drop it.

<comment><USER11> I also found it to be really strange that this article dropped the "Apple" in "Apple Silicon". As if having chips made from silicon is the defining characteristic of these new laptops. Or maybe the whole thing is just a solid block of silicon.

I also find it impressive that Apple managed to get us all saying "Apple Silicon" instead of "processor" or "CPU" in the first place. It does have a much hipper ring to it.

<comment><USER12> > I also find it impressive that Apple managed to get us all saying "Apple > Silicon" instead of "processor" or "CPU" in the first place. It does have a > much hipper ring to it.

Credit where it is due, Apple knows how to name.

Many technology pundits fail to understand (or perhaps more to the point believe) Apple's naming choices, with "iPad" being a notable recent-ish example. [0]

Even many who "get" Apple's product naming can misjudge. I personally was unmoved by the name "iMac" when it was announced in 1998. However, that leading lowercase "i" was a stroke of marketing genius so broad that it is only just now diminishing some twenty years later.

[0] [https://www.cultofmac.com/310020/ipad-haters-5th- anniversary...](https://www.cultofmac.com/310020/ipad-haters-5th-anniversary/)

<comment><USER13> That, and how Apple got nearly everyone (unconsciously?) dropping the indefinite article before their product name (e.g. "On iPad, ..." "...never had this issue with iPhone")

I never fail to notice it--it nearly drives me crazy.

</comment></comment></comment></comment><comment><USER14> The possibility of new AirPort gear is just as exciting as new ARM based laptops, I could use an update to my old AirPort Express units.

The last few Apple laptop I've had for work has been annoying at best, so for home use I wasn't going to replace my old 2013 Macbook Pro with a new Mac, but I am tempted to try an ARM based Macbook.

<comment><USER15> To me it is even more exciting than ARM MacBook.

Airport Extreme was the last Router where I dont have to restart it every few months. It was stable, rock solid. And you only realise how much better it is once you switch to something else.

I wonder if it would still be based on NetBSD? And TimeCapsule?

<comment><USER16> > Airport Extreme was the last Router where I dont have to restart it every > few months.

Give Ubiquiti a try. Mine has been running for several years and I've never had to restart it.

<comment><USER17> Ubiquity is good, but honestly not any faster than the 6 year airport extremes since they both run on 802.11ac.

Things might be different now with Wifi6 but there really hasn't been a single reason to go beyond an AirPort Extreme for 6 solid years.

<comment><USER15> >Things might be different now with Wifi6 but there really hasn't been a single reason to go beyond an AirPort Extreme for 6 solid years.

I was an idiot to want and buy a faster 802.11ac Router, I gave away my AirPort Extreme to my friend and bought an ASUS. It was faster, slightly better coverage / reception. But in the end I discover I value stability over _absolutely_ everything.

I cant remember what problem I had with Ubnt when I had one set up in my friends house.

</comment></comment></comment></comment></comment><comment><USER18> This is just a rumor posted from some random twitter account. Take it with a grain of salt.

</comment><comment> jeppesen-io The MacBook 12 is my favorite laptop of all time. If Apple comes out with same form factor with a little better performance, I'll get it in a heartbeat

</comment><comment><USER19> A price point of $800 needs to be compared with that of the base iPad pro - currently $799. So if no change to the iPad pricing that's (at least) a keyboard and bigger screen for $1. Seems to me that one of these values will need to change.

<comment><USER20> An alternative speculation: after saying effectively that iPad pro can be your laptop, the next iPad pro will be a laptop.

<comment><USER21> I think it's an even money that Apple Silicon will mark the introduction of touch to macOS. In fact with Apple planning to make a big deal out of Silicon Macs natively supporting iOS apps, I'll be surprised if these Macs don't have multi-touch screens.

Apple has always been big on forcing app developers to rewrite UIs to the device, like they did with the iPhone-to-iPad transition. Without touch on Mac, many iOS apps are going to be janky as hell; an incredibly un-Apple thing indeed.

</comment></comment></comment><comment><USER22> If Apple actually sells it at $800 this will be huge. I assume it will ship with some virtualization software and the real question for me is how well that will work. Even if that doesn't work, at $800 it's definitely going to be a better deal than chromebooks or surface laptops assuming it can do things other than surf the web and email.

<comment><USER23> They talked a bit about Rosetta 2 in the presentation a few weeks ago, it's an emulator rather than virtualisation. Their main trick was that it does most of the translation at install time instead of runtime, though I guess it'll depend on app specifics how useful that optimisation is. I'm guessing a browser won't be improved much for example while a native office package would be. Pretty decent write up here: [https://www.theverge.com/21304182/apple-arm- mac-rosetta-2-em...](https://www.theverge.com/21304182/apple-arm-mac- rosetta-2-emulation-app-converter-explainer)

<comment><USER24> It's also hardware-accelerated via special features in Apple silicon.

</comment></comment></comment><comment> tedk-42 I've tried to look for resources around doing any real local development with an ipad pro (a device that's already using apple silicon) and the best advice I've found is basically hacks to get a VM running in digital ocean to do your 'compute'.

Not a huge fan of this. I'm hoping you it's not like the ARM ecosystem with Windows where things are heavily nerfed (Surface Pro X) to the point where you can't do anything that resembles proper development.

Proper MacOS, full full system access, ability to run docker and run golang builds, node runtime, python etc natively and locally on the device are a must. Native terminal app (obviously) is a must with the option of running something like iTerm2 etc. I had a chromebook before with crostini and that was a shitty experience for a fanless dev machine. I hope apple can do it right.

side nitpick: i don't align with the apple haters out there who wanna pick at things like the use of the word 'silicon' by apple.

<comment><USER24> > Proper MacOS, full full system access, ability to run docker and run golang > builds, node runtime, python etc natively and locally on the device are a > must.

You'll get all of that, don't worry.

</comment></comment><comment><USER25> This would be an absolute game changer.

Everyone aspires to own a Macbook but either flat out can't afford one or can't justify the price. (I'm in the second camp)

This changes all of that.

<comment><USER26> This sounds like a bubble effect. None of my friends have ever expressed interest in trading their windows laptops in for a Mac. Some of them actively avoid Apple products with well reasoned justification.

</comment></comment><comment><USER27> Apple are usually careful not to announce new hardware until it's just about ready to ship (with the occasional exception _cough_ AirPower _cough_ ), but in this case (assuming the report is correct) I suspect they'll be making an exception. Four months between announcing Apple Silicon and the first hardware hitting retail seems far too short for developers to properly prepare. So I'm guessing that this will be an announcement well in advance of hardware shipping, maybe early next year, to give developers a clear target to aim for (both a hardware target and a calendar target).

<comment><USER21> I strongly disagree. Apple needs real hardware in stores in order to get Apple Silicon into the hands of the long tail of Mac developer community and to light a fire under developers to get their stuff released.

As for most "normal" customers, these first Apple Silicon devices are going to be perfectly usable on day one—whether they're spending 99% of their time in a web browser or running some outdated finance software through Rosetta. And natively compiled software is going to come thick and fast over the next few months.

As for timing, with the pandemic flattening demand for semiconductors, Apple will have no trouble getting their supply chains running. I'll be shocked if we don't see Apple Silicon Macs in stores by December.

</comment></comment><comment><USER28> I really hope the name Silicon is not used officially.

<comment><USER29> Apple Silicon is the official name for their ARM processors, it was used heavily in the reveal at WWDC by Apple.

<comment><USER4> I think in reporter briefings it's been said that this is a placeholder name.

<comment><USER24> I think they've been mentioning it far too often if it was.

</comment></comment></comment></comment><comment><AUTHOR> It is exciting as a new technology, but from a business standpoint... I suspect specs will be in par with the failed 12inch macbook, with this being a price corrected product, a 1st prototype, and as a strategy improvement parallel to Microsoft's failed ARM launch.

<comment><USER30> A) the first device of any product line is not the one to watch for consumer reactions. It's for developers and early adopters. I would not expect this to be a commercial success.

B) the 12 inch macbook is probably my favorite device, though I really hope they keep the top line of keys. It's so thin, the battery lasts forever, and somehow it performs better than my xps 13 running linux (in interaction latency, not computational throughput).

<comment><USER31> but the first intel macbook was a hit, wasn't it? The 13" sold for 1000$ and worked like a charm, which was surprising.

<comment><USER30> The 13" was a great laptop too. The 12" I have has a single usb-c port and a headphone port, which I suspect is a big reason it didn't take off.

It's soooo light though, I still love it.

Finally, I think the risks here are far more clear than a new laptop form factor.

</comment></comment></comment></comment><comment><USER32> Can they really trademark the name of an element? That seems absurd.

<comment><USER33> I don't see any real suggestion that they'd do so. Apple has referred to their hardware in developer documentation as "Apple Silicon" \-- possibly to avoid trademark issues with ARM? -- but I expect them to use the same naming scheme they use for their iOS application processors (like "Apple A16X") once they have a product ready for market. MacWorld's use of phrases like "Apple's Silicon processor" is likely to just represent confusion on the part of the journalist.

As an aside, I have a very hard time believing that Apple would reenter the networking industry. Consumer wireless access points are a commodity product at this point -- it'd be difficult for Apple to present a compelling premium option, especially when many consumers are satisfied with the one that came built into their cable modem.

<comment><USER34> > possibly to avoid trademark issues with ARM

I suspect it's more of a branding/positioning thing. ARM has an association with low power devices like smartphones, and Apple wants to position this as something new, exciting, and better than x86.

<comment><USER35> Apple Silicon encompasses more than the ARM CPU. It also includes an Apple GPU, Apple Neural Engine, Secure Enclave and more. If you only point to the ARM part you overlook most of the other parts of the chip. The CPU cores are like less than 25% of the layout?

Layout of the A12: [https://cdn.iphoneincanada.ca/wp- content/uploads/2018/10/A12...](https://cdn.iphoneincanada.ca/wp- content/uploads/2018/10/A12_575px.jpg)

<comment><USER36> I mean, by that logic, does calling a modern intel cpu x86 discount the integrated graphics, which are also very significant?

</comment></comment></comment></comment></comment><comment><USER37> Would a device like this be more powerful than my early 2015 MBP?

<comment><USER38> Yes. The A12Z in the ipad pro is already 25% faster is in single core and 50% faster in multicore than the highest end i7 in the 2015 macbook pro according to geekbench 5.

Given that the chip in macbooks will be a lot faster than the A12Z, it could very well offer twice the multicore performance.

<comment><USER39> > geekbench 5

Now try some math workload on A12Z, i.e. real-world stuff and weep. Most of the die space on x64 CPUs is spent on caches and SSE, so if you cut them out to be more power-friendly, you lose performance in high-end applications.

<comment><USER40> What makes you believe Apple doesn't know this or has removed them?

<comment><USER39> A12Z is still using ARM 8.3 instruction set, therefore no 2048-bit SVE2 for math. Their L1 cache is also 2x smaller than on Zen 2 - that gives them a massive power advantage. I'd wait out this generation of ARM-based notebooks and go with their next CPU that should have SVE2 implemented.

It's not like anything faster than Pentium J is needed for Office, browsing or even front-end development, so in that segment their first gen should be good enough and maybe even better than i3/i5.

<comment><USER41> SVE is a niche HPC thing just like AVX512. For most applications NEON (aka AdvSIMD) is more than enough.

</comment></comment></comment></comment></comment></comment><comment><USER19> It will be interesting to see if the MacBooks are first Apple products to use the TSMC 5nm process. Might make sense given the lower volume when compared to iPhones.

</comment><comment><USER42> It better have more than one port. Remember why people didn't buy the 12" MacBook?

<comment><USER2> One main advantage of going to their own silicon is, that Apple is no longer dependant on the decisions of Intel, what kind and number of ports the machine should have. Then designing USB-C/Thunderbolt support, they can add as many ports as they want to the chipset. For the MacBook, 2 ports would be nice, as we have today on the MB Air. However I don't think the ports were the biggest reason that people didn't buy the 12" MB. The Intel CPUs were just too constrained when running in a machine without a fan, the Apple Silicon should improve upon this a lot. The butterfly keyboard didn't help things either.

<comment><USER9> I don't think Intel is the reason for the few ports though... No other intel laptop has such few ports. It's Apple's own minimalism (and their extremely lucrative dongle business)

<comment><USER2> Yes and no. The problem is, the chipsets limit the number of thunderbolt ports you can offer without adding separate interface chips. That is why many other laptops come with one or two thunderbolt ports too. What Apple could have done, is offering plain USB ports etc., which the chipset would support. But as Apple wants all ports to have the same capabilities, they were quite limited by the maximum amount of thunderbolt ports supported.

While I think it would have been very convenient to add at least one USB-A style port and perhaps a dedicated HDMI port to their machines, I quite agree how nice it is, that all USB-C style ports do have the same capabilities.

</comment></comment></comment></comment><comment><USER43> I want a touchscreen too.

</comment><comment><USER44> Who knows if these pricing rumors are real, but what's interesting is that if everyone keeps talking about how these machines are going to be quite a bit cheaper, Apple might be forced to actually make them cheaper than they would have otherwise. If they come out with more expensive ones, it'll be a bad look.

</comment><comment><USER45> There's a reason why Apple hired hundreds of chip designers away from Portland's Intel site and set up a chip designer center in Portland.

</comment><comment><USER46> Awesome. But I want a laptop that costs $2500, has a 4:3 Flexview screen, the old IBM keyboard and does not look like an ugly fashion accessory.

And I don't like LED backlight:

[https://ledstrain.org/d/680-eyestrain-in-macbook- pro-2018](https://ledstrain.org/d/680-eyestrain-in-macbook-pro-2018)

</comment><comment><USER47> The $999 MacBook Air comes with a core i3. Where is the purported $200 cost saving coming from?

Edit:

According to the WSJ $75 to $150 per Mac could be saved.

[https://www.google.com/amp/s/www.wsj.com/amp/articles/apple-...](https://www.google.com/amp/s/www.wsj.com/amp/articles/apple- is-the-newest-chip-giant-in-town-11592910000)

>The new Mac processors will shave $75 to $150 off the cost of building a computer, estimate analysts, who say Apple can pass those savings on to customers and shareholders.

<comment><USER48> Apple silicon.

<comment><USER47> How much is an i3? Surely well under $200.

<comment><USER15> A saving of $100 from BOM would translate to $200 reduction in SRP. Remember this isn't just CPU, but CPU + Chipset and other smaller components.

Apple could easily make that saving and more. You can also look at iPad Pro selling price as reference.

<comment><USER49> This. Also, there is a possibility Apple is willing to forego some profit (make only 70% rather than 100% profit) as a strategy to seed the market in order to give developers an incentive to adopt ARM faster.

<comment><USER50> Their push into services would be helped by having more volume products. I'm suspect this is why the iPhone SE was priced so low.

</comment></comment></comment></comment></comment></comment><comment><USER9> Lol $800. This is Apple we're talking about. Just the logo on the front will cost $800 (just joking). But really, this is way below Apple's normal pricing.

It would cannibalise the iPad Pro very much too, considering the price of those + keyboard stand is much higher.

Unless they deliberately give up some of their huge margins in order to get these in circulation ASAP, I don't see this happening. The first ARM will be a premium product for them. I don't think it will carry a budget price. No MacBook has been this cheap since the MB Air 11" which was a really underpowered 1.4Ghz / 2GB RAM model.

<comment><USER51> Apples Mac margins are in the 15-30% range. They will price to maintain those margins, so if they can build a viable $800 MacBook at those margins they will take the additional market share.

The iPad Air was a $500+ tablet until they were able to build a $299 model at same margins.

<comment><USER9> But 15-30% is huge in the computer market. 10% is normal to consumers and much less to enterprise customers that demand deep discounts.

I doubt they'd keep the same margin if they really offer it at $800. I don't think they'd save that much by cutting intel out, especially if you factor in R&D. Pretty sure they're cutting into their margins at that price, but it would be good for them to get ARM in the hands of consumers so that developers have a reason to work on it.

<comment><USER51> It's huger than you think, the rest of the PC makers are stuck between 1-4% net profit margins.

But their pricing isn't going to be greatly influenced by R&D costs, it's going to be driven by hardware costs. Those R&D costs are ongoing expenses, Apple is always working on new technologies. A rough rule of thumb is retail is twice hardware costs. Most Intel CPUs cost between $200 and $300 each, while Ax processors in iPads and iPhones cost less than $100 each. And another big factor is the SOCs for Apple Silicon will integrate lots of capabilities that require separate cards or coprocessors on current Macs, including high performance GPUs, the T2 security chip, etc.

So it's reasonable to think Apple will be saving $100 to $200 in hardware costs for the Apple Silicon "equivalents" of their current lineup (Equivalents in positioning, but faster, slimmer and longer battery life versions). That directly translates $200-$400 lower retail prices, which Apple will use to drive higher sales volumes. That will spread R&D, Design, Marketing, Sales, Admin, and Support over more units, supporting spending more to promote and sell them and more on design and R&D in the future.</comment></comment></comment></comment>


Discovery of Galileo's lost letter shows he edited his ideas to fool Inquisition - <AUTHOR> https://www.nature.com/articles/d41586-018-06769-4 <comment><USER2> Giordano Bruno should also be remembered as a hero of science. He was _burnt at the stake_ by the Inquisition in Rome because he upheld the heliocentric model and cosmic pluralism, a mere 13 years before Galileo wrote this re- discovered letter.

 __ _[added in response to multiple skeptic comments about Bruno 's heroic role for science]_ __

The Inquisition jailed and tried him for 7 years before burning him; of course they had time to question him about religious, doctrinal issues so they could damn him without referring to any of the philosophical and scientific principles he held. Promoting the Inquisition 's recorded accusations against him, and pretending that he was no friend of science, is not very... inspiring (to be polite). And if you are going to denounce him because of his interests in the magical, what is your opinion of Isaac Newton and his lasting interest in alchemy? scientific genius and admirable hero, or somehow a buffoon not worth a footnote in the epochal battle between science and religion?

Bruno was a proud defender of free-thought, freedom of inquiry, and freedom of expression -- all central keys to the development of modern science. He wrote scientific works arguing for the Copernican model, published in 1584, years before Tycho Brahe for instance. He anticipated some of the arguments of Galilei on the relativity principle, as well as using the example now known as Galileo's ship. He was the first person to grasp that stars are other suns with their own planets.

<comment><USER3> Calling Bruno a scientist, or saying he was killed for doing science, is quite a fantastic stretch. And where this article is concerned, the Galileo affair stretched something like 20 years and his house arrest in the papal apartments, overlooking the Vatican gardens, was largely the result of decades of political intrigue and him having accrued enemies.

Sadly, these Protestant and Enlightenment myths persist to this day. Ignorance at best, bigotry and intellectual laziness at worst.

<comment><USER4> Bruno was killed for freely inquiring into the nature of our universe. In a time such as it was that included religious and philosophical speculation as religious and philosophical ideas formed much of the foundation of how people understood the world. I think it is fair to view him as a hero of science however since he lived in an unscientific time it does not make sense to call him a scientist.

>And where this article is concerned, the Galileo affair stretched something like 20 years and his house arrest in the papal apartments, overlooking the Vatican gardens, was largely the result of decades of political intrigue and him having accrued enemies.

That Galileo's enemies were able to use his scientific views against him is not evidence that he was not persecuted for his scientific views. It is merely evidence that it is possible a more nimble or charismatic political player may have avoided such persecution.

</comment></comment></comment><comment><USER5> Galileo didn't really have to "fool" the Inquisition.

By producing a softer version of the letter and claiming it was the original, Galileo was bowing to the authority of the Church. He knew it, they knew it, and everyone important watching knew it. That was the important thing for the Church, and by accepting the softer version as the original, whether or not they believed it, the Church sent the message to everyone watching in return: don't challenge our authority, and we'll leave you alone.

<comment><USER6> > Galileo didn't really have to "fool" the Inquisition. > .. > producing a > softer version ... Church sent the message we'll leave you alone

No. Because even after he produced the "softer" version and claiming that the other harsher version was "fake" he was in 1633 officially "sentenced to formal imprisonment at the pleasure of the Inquisition." The relevant quote from the very sentence, written addressing Galileo Galilei:

"We order that by a public edict the book of DIALOGUES OF GALILEO GALILEI be prohibited, and We condemn thee to the prison of this Holy Office during Our will and pleasure"

He remained in the house arrest for the next 9 years, until he died in 1642. Yes, he actually died while still being in the house arrest. The book remained officially banned for the next 200 years (the Church published the list of banned books which it regularly updated, but it took that much for his uncensored book to be removed from that list).

And that is after he "bowed." Do investigate what would have happened had he not. So he personally surely _had_ to do "fool" them: the alternative outcome for him was much worse.

Edit: a typo corrected, thanks astine. Also added a quote from the original sentence.

<comment><USER7> Galileo was friends with the pope, but then called him an idiot in one of his books (named a character "the idiot" that used the Pope's arguments). That is why he got imprisoned.

<comment><USER6> > Galileo was friends with the pope, but then called him an idiot in one of > his books (named a character "the idiot" that used the Pope's arguments). > That is why he got imprisoned.

No. That would be just blaming the victim.

1) The character was named "Simplicio" as "simple", but it didn't really represent the pope:

> > [https://en.wikipedia.org/wiki/Dialogue_Concerning_the_Two_Ch...](https://en.wikipedia.org/wiki/Dialogue_Concerning_the_Two_Chief_World_Systems)

"Simplicio is modeled on two contemporary conservative philosophers, Lodovico delle Colombe (1565–1616?), Galileo's opponent, and Cesare Cremonini"

2) Being friend with the Pope earlier just _protected_ him from Inquisition between 1616 and 1632. But even as Galileo was in better relations he was already in danger. In 1632 the trial depended on the statement that Galileo was already "ordered" in 1616, that is, 16 years earlier:

"... to abandon completely... the opinion that the sun stands still at the center of the world and the earth moves, and henceforth not to hold, teach, or defend it in any way whatever, either orally or in writing"

So once Galileo lost the support at the highest level the Church did what it did.

I don't understand why there are even today so much people trying to defend the Catholic Church of these times. The facts are plain and clear. To compare with more modern times, the leader on Nazi Germany also intervened to protect one Jew from Holocaust (Ernest Hess) but it doesn't make any argument that Nazism or the "Leader" were otherwise not mass killing Jews by a clear policy. Or that those who were killed somehow caused it themselves by lacking social skills.

<comment><USER7> How is this defending the church? It was clearly a totalitarian organization where if you pissed off the wrong person they would find an excuse to imprison or torture you.

<comment><USER6> The defending is by these that claim that Galileo apparently wouldn't have any problem without the weakening of his once good relations with the pope.

</comment></comment></comment></comment></comment></comment><comment><USER8> Seems to me that Galileo had a problem of proving 'stellar parallax' to his peers and that our convenient history stories overlook this little detail.

Darwin was also deferential to the church. It does not pay off long term.

<comment><USER9> It's not a "perfect" essay — the author seems to be a bit confused about the nature of parallax — but I think it's quite interesting and helpful nonetheless.

[http://nautil.us/issue/60/searches/the-popular-creation- stor...](http://nautil.us/issue/60/searches/the-popular-creation-story-of- astronomy-is-wrong)

Also helpful:

[https://www.quora.com/Why-did-science-make-little-real- progr...](https://www.quora.com/Why-did-science-make-little-real-progress-in- Europe-in-the-Middle-Ages-3)

<comment><USER8> The Nautilus article is really helpful, seems everything we work out as humans is a discourse between writer and readers, getting there in the end. But we need our heroes and, here as well as with Darwin, there are precedents that don't make it into the history books.

</comment></comment></comment><comment><USER7> You see this all the time. People will write stuff like "Crispr/cas9 is really, really awesome so dont think we're saying its not but we found out its toxic in this new way"

Or "Global warming is a huge problem and we need to do something about it for sure but..."

<comment><USER10> Absolutely. I wonder if we will ever live in a time when these sort of games are not necessary. There's the old saying that _" Science progresses one funeral at a time."_ The problem is that scientists are even more receptive to 'less than popular' ideas than the masses are. And by 'old' that statement was from Max Planck, who died in 1947.

<comment><USER11> If anything I think it's gotten/will get worse. Because people have to specialize so much these days they get VERY wedded to their ideas, and much more resistant to change.

Back when you could know all of science, someone could change one part or another and it was just one more thing - not the core of what you do.

For example say "there is no dark matter" \- every single person who studies dark matter (and nothing else) is going to be virtually impossible to convince - and yet those are EXACTLY the people who have the expertise to verify such a claim.

</comment></comment></comment><comment><USER12> I am very sorry, but not mention or discussion of Galileo on this site is complete without a mention of the great ptolemaic smackdown [1]. If you have about 4 hours worth of your time (even in installments) it is deeply recommended.

1: [http://tofspot.blogspot.com/2013/08/the-great-ptolemaic- smac...](http://tofspot.blogspot.com/2013/08/the-great-ptolemaic- smackdown.html)

<comment><USER6> And this "4 hours" will be wasted. The author of that text intentionally misleads his readers.

The author claims:

"the reaction at the time was "WTF? Which heresy are you talking about here?"

But the exact heresy was explicitly and very clearly stated both in the sentence by the Inquisition:

[http://hti.osu.edu/sites/hti.osu.edu/files/documents_in_the_...](http://hti.osu.edu/sites/hti.osu.edu/files/documents_in_the_case_of_galileo.pdf)

"the above-mentioned Galileo, because of the things deduced in the trial and confessed by you as above, have rendered yourself according to this Holy Office vehemently suspected of heresy, namely of having held and believed a doctrine which is false and contrary to the divine and Holy Scripture: that the sun is the center of the world and does not move from east to west, and the earth moves and is not the center of the world, and that one may hold and defend as probable an opinion after it has been declared and defined contrary to Holy Scripture."

And in Galileo's Abjuration:

[http://www.creatinghistory.com/galileo-galileis- abjuration-2...](http://www.creatinghistory.com/galileo-galileis- abjuration-22-june-1633/)

"after having been judicially instructed with injunction by the Holy Office to abandon completely the false opinion that the sun is the center of the world and does not move and the earth is not the center of the world and moves, and not to hold defend, or teach this false doctrine in any way whatever, orally or in writing; and after having been notified that this doctrine is contrary to Holy Scripture; I wrote and published a book in which I treat of this already condemned doctrine and adduce very effective reasons in its favor, without refuting them in any way."

The premise of the whole "4 hour" series by that author is also wrong, approximately, that because the parallax of the stars wasn't observed until around 1750 Galileo "couldn't prove" in 1633 that the Earth is not standing still, therefore the Church was "right" and it wasn't a matter of faith but "a personal thing." It's obviously a completely invalid argument. Because the reason why Galileo was convinced about the wrongness of the heliocentric theory was the simple fact that he was really _the first human in the world_ who saw the moons around other planet, not accidentally called "Galilean moons":

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

He didn't have to "prove." He was really sentenced only for "having held and believed a doctrine which is false and contrary to the divine and Holy Scripture." It's explicitly stated in the official document.

That something like that is a reason enough for a condemnation by the religious authorities, even in much more recent times, can be obvious to anybody who tried to read the source text of the condemnation to murder of the author "along with all the editors and publishers aware of its content" of the book "The Satanic Verses" in 1989. I won't link to that, intentionally, but there's enough details to... check the original sources!

Additionally, not only Galileo's but the Copernicus' book too remained _banned by the Church for the next 200 years after Galileo was sentenced,_ in spite of all the scientific discoveries in these 200 years that made these texts less unique. And the discoveries... there were many of them. Starting with the publication of Newton's "Principia" in 1687, only 50 years after the sentence. Newton was, of course, out of the reach of the Catholic Church, thanks to the lucky coincidence of him being born in "a political system found on the family values of Henry VIII."

It's always more worth checking the original sources instead of believing in 4 hours of text of somebody who intentionally avoids quoting and discussing these very sources. A lot of false claims can be constructed by omitting the evidence, the original sources and inventing the interpretations of the actual events. It's a very dishonest approach and should not be supported.

</comment></comment><comment><USER13> People make a great deal about these "science martyrs". But, from a more disinterested perspective, one cannot entirely blame the Catholic Church's approach.

None of the martyrs had clear evidence they were correct, and were often pursuing a larger agenda of undermining the Church's authority and the general spiritual worldview.

Was the Church right to imprison and kill these people? Probably not. But, was the Church wrong in its concerns? Considering the untold millions of killings of the past couple centuries that resulted from scientism and naturalism, the Church's concerns about the so called heretical scientists may not have been entirely unfounded.

<comment><USER14> > Considering the untold millions of killings of the past couple centuries > that resulted from scientism and naturalism, the Church's concerns about the > so called heretical scientists may not have been entirely unfounded.

But the Church of the day had no problem with killing - in fact, they were quite enthusiastically into it, when it came to heathens, Muslims and Jews. And eventually Protestants.

I mean, it's only because of scientism and naturalism that mass murder in the name of God is even considered immoral nowadays, much less illegal.

<comment><USER13> There were certainly wars during that time, but is it true the Church engaged in the mass genocides like the atheist regimes of the past couple centuries? I'd like to see proof of this.

<comment><USER14> > but is it true the Church engaged in the mass genocides like the atheist > regimes of the past couple centuries?

Surely, mass murder is mass murder, regardless of the label you apply to it. You're dismissing things like the Crusades and the Church's attempts to convert the New World by force.

One could possibly claim that modern "atheist" regimes were capable of mass murder at a greater scale than the Church due to the effect of industrialization ... certainly the Holocaust might not have been as effective as it was had the Nazis been limited to pen and paper, horseback and swords.

But, I don't see evidence for the implication that non-theocratic governments or societies are inherently more violent than theocratic ones, rather I see a lot of evidence to the contrary, that unchecked religion permits unchecked violence, because you can argue with a secular authority, but if you believe in God, you can't argue with God.

I mean, you _can_ , but if your government claims authority by divine right, then doing so is a threat to the state and it probably won't end well for you.

But my point was that, whatever concerns the Church might have had about the effect of heretical ideas, the possibility of violence was not one of them.

<comment><USER13> They of course did not foresee the French Terror, Communist revolution, Pol Pot's killing fields, Mao's Great Leap Forward, and the Holocaust. But, they did realize the implications of believing man was only matter and that there was no moral order. Christianity was formed in the midst of societies that had very little regard for human life, and stood out for protesting the oppression of their day.

</comment></comment></comment></comment></comment><comment><USER15> Reading about these people who were persecuted and _murdered_ for advancing human knowledge, and seeing the current state of the world where even our leaders still rail against vaccination, climate change, human rights, the moon landing and other facts, is anyone else bemused by what a _self-defeating_ species we are?

If you placed humanity next to other hypothetical species and looked at us from a detached point of view, what would be our defining characteristic?

<comment><USER16> What makes you think those other species would be better?

<comment><USER15> That is very interesting, because I don't think the constraints of natural selection and competition for resources are going to be the same in every environment on every planet. Most of what we are is determined by our biology.

Take ants or bees or termites. They have conflict between different colonies, but cooperation within a colony is guaranteed.

<comment><USER16> One could argue that our _lack_ of cooperation/cohesion has been partly responsible for our scientific, technological, and even social progress.</comment></comment></comment></comment>


Haskell Fan Site - <AUTHOR> http://www-cs-students.stanford.edu/~blynn/haskell/ <comment><USER2> Ben Lynn is a winner of the 26th IOCCC [https://ioccc.org/2019/whowon.html](https://ioccc.org/2019/whowon.html) with a tiny Haskell Compiler. We will be releasing the code in early July.

<comment><USER3> He's also the L in BLS Signatures and is currently at DFINITY building their system using both BLS and Haskell.

[https://dfinity.org/team/](https://dfinity.org/team/)

</comment></comment><comment><USER4> From my experience Haskellers spend more time talking about how perfect and pure Haskell is than building real-world applications.

<comment><AUTHOR> We need more startup to use Haskell in production, like Dfinity.

<comment><USER4> Has Dfinity launched yet?

<comment><USER4> No

</comment></comment></comment></comment><comment><USER5> > Programs should be easy to express.

in my experience, languages that make it easy to express small programs tend to be counterproductive for large systems with many modules, many people working on the system and the desire for fine-grained control.

<comment><USER6> Sounds like you perhaps have experience of dynamically-typed languages? Haskell is statically typed, compiled, has a scalable multi-threaded runtime, a very good FFI; and was designed around the notion that large programs should be built by composing small programs.

<comment><USER7> Globalized type inferrence is still a problem when you want to build large programs. You change the implementation of one function and 20 functions further there is a problem and you need to figure out all the interactions on the path between. Rust strikes a great compromise here IMO.

<comment><USER8> I think that these days the Haskell best practices recommend adding a type annotation to all toplevel declarations, to help keep error messages manageable.

</comment></comment></comment></comment><comment><USER9> > I have seen languages that practically force the programmer to run a > heavyweight specialized IDE, and that require 14 words to print 2 words.

I picked up Haskell again last week after a long hiatus and although one does not need a heavyweight IDE, the build system still felt like a bit of a mess. After adding `parsec` (a popular library for parsing) to a stack project, my machine spent over an hour compiling dependencies at which I point I gave up.

<comment><USER10> Try using nix instead. Aside from being a fantastic package manager for many languages it's a godsend for Haskell. The lengthy compilation times with Haskell are one of the not so wonderful parts of the language, but they largely disappear with nix, and the Haskell ecosystem on nix is very well supported, with a large community. Honestly I've been developing Haskell for years and have never once used stack. I did use cabal before I discovered nix, but since then I'd hardly dream of using anything else.

<comment><USER11> how does nix eliminate compile times???

<comment><USER10> It doesn't eliminate them entirely; it's just very smart about allowing packages to be built exactly once, and having a deterministic output such that it can be determined before a package is built whether a prebuilt version is available. This prebuilt version can either be the result of a previous build on your machine, or on another machine served from a repository.

Of course, there are times when you need to compile yourself, but most slow- to-compile packages, such as Aeson, Lens, Servant or the aforementioned Parsec, and many more on top of that have prebuilt binaries available when built from community snapshots (nixpkgs/nixos). You can even pin your package definitions to guarantee that you're building something that will have prebuilt versions available. New project build is usually less than a minute or two, sometimes substantially so (anecdotally). Again, not always, but usually.

</comment></comment></comment></comment><comment><USER12> > Writing code should be comparable to writing prose. A plain text editor with > 80-character columns should suffice. Coding should feel like writing an > email or a novel. If instead it feels like filling out a tax return, then > the language is poorly designed.

So this page has nice statements like those ones, but no justifications. Why should writing code be comparable to writing prose or writing a novel? I don't see why that would result in a better implementation.

Prose is full of obscure and non-well defined rules that often require subjective judgement. That's something I want to avoid when writing programs. Program source codes are better written as clear and unambiguous as possible, limiting potential misunderstanding whenever possible, where a person writing prose will play with rhythm, symbolism, rhymes, atmosphere development, etc and can use potential misunderstanding and multiple meanings to add depth to their work.

Filling a tax return seems to be better IMHO, I don't need to develop my own style over years and years of writing, I learn the (quite strict) rules, apply them, anyone who also knows the rules can easily fix/extend/improve what I've done.

<comment><USER13> Surely the point there is that you should feel like you can write your idea down any way you want, instead of being bound by an extremely tightly constrained form that only lets you put very specific things in certain places. Your tool is a blank sheet of paper and a pen; it's not in your way at all.

"This year was a good year: I made $100,000 at my job although I did lose $500 in the stock market."

</comment></comment><comment><USER14> Given the laziness, you'd think memoizing an arbitrary pure function would be easy in Haskell - at least as easy as Python, where you can do it with a one line decorator.

But no, it's pretty complicated: [https://wiki.haskell.org/Memoization](https://wiki.haskell.org/Memoization) you even have to involve fixed point combinators. Pretty disappointing.

<comment><USER15> I love FP and have programmed Haskell in professional contexts. But I have to admit, I don't like it and it's strong formalisms make so many problems much harder than they have to be.

Take lenses for example. All of this unnecessarily complicated shit because Haskell doesn't have any reasonable record syntax.

I appreciate Haskell as a research project and it's clearly pioneered many important FP concepts: monads, free monads, trampolines, etc. But I would never ever choose it for a new project. OCaml, F#, and Scala would be my go to. Nice FP, but not so opinionated to cripple/slow you down when you want to dip your toes in mutation. And in my experience, almost all non-trivial programs require at least a little bit of mutation. And when it's required, I really don't want to waste my time with IORefs or STRefs or whatever.

<comment><USER16> I'd like someone to blog about Haskell who has say an average IQ, has learned Haskell (used it professionally) and then can come back and talk to points like this.

It seems a lot of Haskellers have super high IQ, and can grok Haskell Lens like it's a toy truck. Then they write a blog post that's pretty hard for a beginner to disect.

Or maybe they struggled with Lens but by the time they spent 5 years with other gurus in a professional setting they finally got it, but have forgotten how hard it is to learn this stuff.

<comment><USER17> See the "monad tutorial fallacy": [https://byorgey.wordpress.com/2009/01/12/abstraction- intuiti...](https://byorgey.wordpress.com/2009/01/12/abstraction-intuition- and-the-monad-tutorial-fallacy/)

<comment><USER16> Absolutely - that's why I added the professional experience caveat. Someone who has just got a concept 5 minutes ago shouldn't write a tutorial about it.

</comment></comment></comment></comment></comment><comment><USER18> Nice, but it misses the point that `IO` is actually pure (referentially transparent) in Haskell:

      let x = putStrLn "hello"
      in do x ; x

is equivalent to:

      do putStrLn "hello" ; putStrLn "hello"

<comment><USER19> I though purity was about having no side-effects. Or, in other terms. If you call the a pure function twice with the same arguments, you get the same output.

<comment><USER20> Those two statements aren't actually equivalent.

Haskell isn't pure. A truly pure programming language would be completely useless as it wouldn't be able to actually manipulate state at all.

<comment><USER21> No! Haskell programs are actually pure!

The main function returns a _description_ of the actions it's going to do; it doesn't actually execute those actions. You can pass these descriptions around as values, extend them, match on them and what not.

Think of it like Command pattern in OOP. When you pass a command around the command doesn't actually execute. It's a value that at some later stage will be executed.

<comment><USER22> Is there a way to distinguish between a main function that "actually" executes the actions, and one that does not? I think that laziness makes this a subtle question.

<comment><USER21> there are no functions that actually execute actions. That function is in the Haskell RTS, and not in your program.

<comment><USER23> Isn't that very close to being a vacuous semantic distinction at this point? I don't see much of a difference to "My C# main never actually executes. It's the .NET runtime that interprets the IL bytecode."

I'm still a beginner, but having to figure out when and where to flush text to the console doesn't make haskell feel different from other imperative languages.

<comment><USER24> > I don't see much of a difference to "My C# main never actually executes. > It's the .NET runtime that interprets the IL bytecode."

You can't actually reason about C# programs in those terms - e.g. you can't really say whether two C# programs are equivalent except in the vacuous sense of being equal as strings or ASTs. Some basic C# functions offer only operational semantics, so you have to reason about how and when those functions are "actually executed" if you want to be able to understand programs that call those functions. E.g. you can't know whether "(foo(), foo())" is equivalent to "x = foo(); (x, x)" without thinking about "how foo() is actually executed". In contrast you can reason about Haskell programs that contain IO actions without having to understand how those IO actions are executed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> I thought it was neat that they talk about trying to parse the "J" programming language.

<comment><USER26> Yes, direct link[0]. Though most of the subjects are interesting in my opinion.

[0] [http://www-cs-students.stanford.edu/~blynn/haskell/jfh.html](http://www- cs-students.stanford.edu/~blynn/haskell/jfh.html)

</comment></comment><comment><USER27> Due to the purity, programming in Haskell is like learning how to configure a system, instead of coding.

Configuration is always pure, only the underlying runtime system is not.

</comment><comment><USER28> the post focusses on the practicality of haskell and addresses purity but leaves the biggest problem out: laziness, which is more or less the reason haskell exists, is the wrong default. In particular lazy I/O which can introduce horrible bugs or straight up mess with execution order of critical code, which in my opinion is an absolute no-go in an industrial language.

<comment><USER29> _> lazy I/O which can introduce horrible bugs or straight up mess with execution order of critical code_

I've never seriously programmed Haskell, so honest question: I understand the first point, but how is the second possible? Isn't the point of passing RealWorld around that you enforce the order of execution through data dependencies rather than expression order? It always seemed like a very elegant (and incredibly impractical :) ) solution to me.

<comment><USER30> OP is somewhat conflating two different things: non-strict function evaluation and lazy IO. With lazy IO, you can get, for example, a String from a file. That string is actually a lazily-constructed chain of Cons cells, so if you're into following linked lists and processing files one char at a time, then it's fun to use. The dangerous bit comes in when you close the file after evaluating its contents as a string:

        fd <- open "/some/path"
        s <- readContentsLazy fd
        close fd
        pure $ processString s

Now, processString is getting a string with the file's contents, right? Nope, you have a cons cell that probably contains the first character of the file, and maybe even a few more up to the first page that got read from disk, but eventually as you're processing that string, you'll hit a point where your pure string processing actually tries to do IO on the file that isn't open anymore, and your perfect sane and pure string processing code will throw an exception. So, that's gross.

That's a real issue that will hit beginners. There's been a lot of work done to make ergonomic and performant libraries that handle this without issues; I think that right now pipes[0] and conduit[1] are the big ones, but it's a space that people like to play with.

[0] - [https://hackage.haskell.org/package/pipes](https://hackage.haskell.org/package/pipes) [1] - [https://github.com/snoyberg/conduit](https://github.com/snoyberg/conduit)

<comment><USER31> Seems like the problem is that file close is strict, whereas the file handle should be a locked resource that is auto-closed when the last reference is destroyed (and "fclose" just releases the habdle's own lock).

In other words the problem seems to be (in this example) that the standard library mixes lazy and strict semantics. A better library wouldn't carry that flaw.

<comment><USER32> So that's actually how it works if you just ignore hClose. The problem is that it sometimes matters when things get closed, so they do "need" to expose the ability to close things sooner.

<comment><USER31> Sort of. It eventually gets cleaned up by the garbage collector, yes. But that could be after an indeterministic amount of time if the GC is mark-and-sweep. My point is that in this circumstance reference counting could be used regardless so that as soon as the last thunk is read, the file is closed. The 'hClose' is basically making a promise to close the file as soon as it is safe to do so.

<comment><USER32> > as soon as the last thunk is read, the file is closed.

That's probably doable. It's true that when the only reference to the handle in question is the one buried in the thunk pointed at by the lazy input, it should be safe to close it when a thunk evaluates to end-of-input (or an error, for that matter).

I'm not sure whether or not it'd be applicable enough to be worth doing. The immediate issues I spot are that a lot of input streams aren't consumed all the way to the end, and that you'd have to be careful not to capture a reference anywhere else (or you'll be waiting for GC to remove that reference before the count falls to zero).

<comment><USER31> Also things like unix pipes or network sockets, where the "close" operation means something different as there are multiple parties involved. Arguably the same is true of files as you could be reading a file being simultaneously written to by others.

<comment><USER32> Right. It's easy to handle the simple case, but honestly "let the GC close it" works fine in the simplest cases.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> Used to code quite a bit in Haskell, but I've moved on. I believe in the philosophy "Simple things should be easy, hard things should be possible"; Haskell forgets the first part.

</comment><comment><USER34> Languages influence each other. Few people have used OCaml but most will get to use OCaml-influenced features in a mainstream language like Swift, Rust, Kotlin, Scala, etc.

</comment><comment><USER16> I read the article, but I am confused. Where is the "Fan Site". Is this a tutorial for creating a fan website?

<comment><USER35> I believe it's all the links at the bottom represent his fan site.

</comment></comment><comment><USER36> Here's a chunk of code from a haskell project I work on that shows how concise and nice haskell can be:

        class EntityStore b m => TagStore b m where
            -- | Add a new tag
            addTag :: b -> Tag -> m (Either DBError (ModelWithID Tag))

            -- | Get all tags
            getAllTags :: b -> Maybe Limit -> Maybe Offset -> m (Either DBError (PaginatedList (ModelWithID Tag)))

            -- | Find tags by a given ID
            findTagsByIDs :: b -> [TagID] -> m (Either DBError (PaginatedList (ModelWithID Tag)))

That bit at the start (`EntityStore b m => TagStore b m`) roughly reads "Given that types 'b' and 'm' exist that satisfy the typeclass 'EntityStore', they satisfy the typeclass 'TagStore' if they implement the following methods".

If your eyes glazed reading the sentence above -- this is a way of composing interfaces. Any TagStore-capable thing is required to be EntityStore-capable.

And here's that being used:

        createTag :: ( HasDBBackend m db
                     , HasCacheBackend m c
                     , MonadError ServantErr m
                     , TagStore db m
                     ) => SessionInfo -> Tag -> m (EnvelopedResponse (ModelWithID Tag))

        createTag s t = requireRole Administrator s
                        >> validateEntity t
                        >> getDBBackend
                        >>= \db -> getCacheBackend
                        >>= \cache -> addTag db t
                        >>= ifLeftEnvelopeAndThrow Err.failedToCreateEntity
                        -- invalidate cached tag listing & FTS results
                        >>= \res -> invalidateTagListing cache
                        >> invalidateTagFTSResults cache
                        >> pure (EnvelopedResponse "success" "Successfully created new tag" res)

I prefer the explicit 'bind' syntax (>>/>>= are pronounced 'bind') to do notation, because of the clarity you get when the code is laid out, and how it encourages modular functions

All those `HasDBBackend m db` and `TagStore db m` incantations mean that this function knows about the world is that it has a DB backend, a cache backend, a tag store, and it knows something about the kind of errors it can throw (`ServantErr`). Then come what the actual function does (after the =>) -- Take in a SessionInfo, a Tag, and produce an "action" that when run will produce a EnvelopedResponse (ModelWithID Tag) value.

This style is called mtl and it's just _one_ of the big patterns in the haskell community, but the big feature here is that isolation -- this function can only do things that it knows about by way of constraints (`TagStore db m` means a `TagStore`-capable thing is accessible to you) -- this is much safer than having functions that can just do anything at any time.

I've said it numerous other times, but the kind of stuff you do in haskell trickles into other languages -- see Florian Gilcher's talk from RustLatam 2019[0] -- it's basically on this same concept but in Rust (one of the reasons I absolutely love rust, they've bolted on a fantastic type system).

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

</comment><comment><USER37> Haskell is fun, lots of fun, but it is not a practical language by virtue of it being strongly typed.

By practical I mean strongly typed PLs are not forgiving as your world and perceptual view of the world changes over time -- as it does for any business.

Your program must pass a proof to execute. For the most part you do not need to explicitly express your types; Haskell can infer them. This is often pointed at by Haskell enthusiasts as some kind of nicety. But it's not because (1) the types are still there; your program still has to cohere wrt to the type system; (2) strongly typed programs with explicit type annotations are much easier to read and manipulate, so you should use them anyway.

As your world and assumption changes over time you will find yourself having to do a ton of work to have everything cohere for the type proof again. Haskell enthusiasts also like to say things like with strong typing "Refactoring is easier". This is incorrect. What they are pointing at is that Haskell will of course catch certain (type mismatch) bugs during a refactor, but it will also find many many things that would not be a bug were you using a lighter or no static type system. So ironically this in my experience _discourages_ refactoring because you become exhausted from all the unnecessary labor required to make rather nominal changes to your domain model.

Dynamic languages on the other hand, when in the right hands, don't obligate this whole unnecessary labor of effort.

I feel that there's an elephant in the room whenever I talk to someone who is enthusiastic about strong typing in a business or real world context. And that's this: that their enthusiasm is more to do with the pure fun of manipulating a type check/prover and playing in these weeds than actually getting real stuff done over time.

Another common retort from the strong typing enthusiast is they will point back at a dynamically or loosely typed system they've worked on and point out what a mess it is and then proceed to show how they don't run into certain classes of bugs any more, like null pointer exceptions. What goes unanalyzed is the competence of the team that made the mess, that it was the fault of the skills at play and not a necessary fault of not having types. What also goes unanalyzed is whether the extreme cost of playing the strong typing game is worth an occasional NPE (which are of the immensely easy and fixable kind of bugs) here or there -- in a standard business (ie, not mission critical) context.

I realize this is going to be hotly contested and that I'm stepping on toes here, but I think all of this is true.

Learn Haskell by all means, but be honest with yourself when comparing it to the successes of more pragmatically designed languages. This should also be no surprise; Haskell is a research langauage born in academia, NOT born out of long practitioner experience. Compare to Elm -- another strongly typed language for the frontend -- which was born out of a doctorate with limited real world experience. Then compare to, say, a Clojure (another esoteric language) but which was born from extensive pragmatic experience and look at the choices it made and how in many cases they run against Haskell's.

<comment><USER38> > with strong typing "Refactoring is easier". This is incorrect.

I can't tell if you're just trolling, but have you ever done a large refactor in a dynamically typed language such as Python? It's a runtime minefield, taking a huge amount of testing effort to gain any level of confidence that you got it correct. In a language like Haskell or Rust, it's usually as simple as getting the thing to compile.

<comment><USER39> IME a code base with high test coverage lets me refactor far more securely than an expressive static type system. Static typing is useful, but if I had to pick one it would be tests all the way.

<comment><USER40> The cost of a high test coverage could be an additional 3x lines of code for the tests. While you still need tests with an expressive type system you can basically cut the code coverage to a fraction. And maintain the same level of confidence in refactoring.

<comment><USER39> _While you still need tests with an expressive type system you can basically cut the code coverage to a fraction._

Where on earth do you get the idea that static typing lets you cut the code coverage to a _fraction_? I am going to need specific examples to believe this claim.

<comment><USER40> Using a comprehensive and a well crafted type system limits the choice you can input to your functions. Drastically. If you utilize the type system right it essentially forbids you from supplying faulty data as input to your functions.

After a large range of (faulty) inputs are already forbidden by the type system you're left to write tests that actually test the business logic. I don't see how this would not cut the required test coverage compared to for example dynamic type systems where virtually any input is allowed and has to be covered by tests.

<comment><USER37> This is all false.

You can get input data verifications dynamically or statically. You don't have to use static type verification to verify data inputs and dynamic validations are much more expressive and simpler. See the immensely expressive Clojure spec or Ruby Validations and compare to any type system.

<comment><USER40> Couldn't find anything on Ruby validations (drop me a link?) just something about the db ORM/engine.

However, Clojure's specs indeed seem to be runtime checks. Seems very different from a type system, really just packages functionalities for the primitives rather than having an expressive type system.

I may be understanding this wrong but I fail to see what's the added benefit of moving checks to runtime in contrast with the performance penalty it produces. Or maybe it's just an improvement to an otherwise dynamic language, like Erlang/Elixir has Dialyzer.

Seems to me it's more of a mechanism to handle the errors or produce code that handles inputs a static type system would prevent from being used in the first place.

<comment><USER37> Runtime checks are much, much more flexible (because they are ad hoc), more compose-able (they are written using the PL itself), _and_ more capable (you have the full breadth of the PL semantics).

I could go on with concrete examples to demonstrate each of these merits but here is a big one:

In a statically typed architecture you typically see a typed domain object (ADT) used -- eg, Person -- and you let the type itself "validate" (eg, Person.name, Person.age are non-null/required fields, etc). And _wherever_ Person flows you are obligated to adhere to this form/validation requirements OR you must create a new type and map from/to these two types. This is already obviously a bad idea.

In a dynamic language you can define specs universally (like you are obligated to in the static typing case) or you can define a spec for different scenarios and different functions.

Let's say I have a process (sequence of function calls) that ultimately cleanses/normalizes a person's name (I'm making up a use case here). This code _does not need age_ but in a statically typed system you will be passing around a Person object and all sources of data must "fill in" that age slot. Now there are a lot of responses from the statically typed people to this scenario [1] but if you follow them all down honestly, you will end up with a dynamic map to represent your entity and you will best be within a dynamic system like Clojure to optimally code and compose your code.

[1] The only other response is to say who cares if I have to "fill in" age and to this person I say I feel sorry for the people six months, one year, etc that have to build on top of your code.

Here's the Ruby link you asked for-- it's actually rails,b ut it ca be fully decopuled from ActiveRecord fwiw: [https://guides.rubyonrails.org/active_record_validations.htm...](https://guides.rubyonrails.org/active_record_validations.html) (Spec is far more decoupled and designed for general use.)

<comment><USER41> Not an expert on spec, but I suspect that there are a lot of data that are not representable with combinations of predicates: GADTs, rank-n types, existential types, type families, data families, and other more advanced type system features.

Either way, the tradeoff is this: statically typed languages are guaranteed to be free of type errors, but no such guarantees can be made with runtime assertions. Whether or not you use a tool like spec to help you make those assertions, the fact that they happen at runtime prevents them from making any guarantees about type safety. Even if you use spec literally everywhere, as you suggest (and no one actually comes close to doing anyway), you are still not guaranteed of type safety. Dijkstra explains why: [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html)</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Anyone getting constant youtube 'sorry video no longer available' problems? - <AUTHOR>

For the last few month I'm getting the 'were sorry this video is no longer available' for almost every video on youtube.  Sometimes refreshing a few times work, but lately even that doesnt fix it. For example this vid: http://www.youtube.com/watch?v=AyzOUbkUf3M<p>(and its not just me. pretty much everyone around me here in South Africa report the same issues) <comment><USER2> use this link, click on YouTube and you are away <http://www.soaleaders.com/index.php>

</comment><comment><USER2> use this link, click on YouTube and you're away <http://www.soaleaders.com/index.php>

</comment><comment><USER3> download an .flv player and try keepvid.com :)</comment>


Ask HN: If I use GSuite does Google mine my data for their own purposes? - <AUTHOR> If I pay for GSuite and I browse the web while logged on to my GSuite account using Chrome, for example, does Google mine my data/metadata/behavior for the purposes of advancing their business model? Or just to "help deliver my services" <comment><USER2> (I'm a software engineer on Google Drive.)

The answer is no. To the point where it's actually a pain in the ass for us because developing any ML-assisted capabilities for G Suite requires us to only get training data from specific subsets of customers who are under special contract conditions.

If you buy G Suite from a reseller then they might be doing shady shit but we'd terminate their reseller account if we found out about it.

I know people like to bitch about this kinda shit on HN but honestly I and my coworkers spend so much time on protecting our customers' data from literally everyone -- including ourselves -- that I want the chance to bitch back about how hard my job is.

<comment><USER3> I wonder if this commitment is reflected in any official terms or pledges?

<comment><USER2> "Google Cloud Security and Compliance Whitepaper" linked elsewhere on this thread: [https://storage.googleapis.com/gfw-touched-accounts- pdfs/goo...](https://storage.googleapis.com/gfw-touched-accounts-pdfs/google- cloud-security-and-compliance-whitepaper.pdf)

Relevant bits start at page 12:

"G Suite customers own their data, not Google."

"There is _no_ advertising in the G Suite Core Services, and we have no plans to change this in the future"

etc.

Ultimately the biggest cudgel you have to wield here is in the sales contract you're signing, but my understanding is that the baseline privacy guarantees are standard for all customers at the strictest level -- people actually opt to reduce the restrictions on their data so that new features get built with their use cases in mind (otherwise we wouldn't know what those actual use cases were).

A _lot_ of companies use G Suite and a lot of them have very strict privacy + security requirements. This is the same platform used by fintech companies, healthcare companies, MegaCorps, etc.

Sort of a thing with all non-web-search Google products: I can't fathom how people see the $5B/quarter "other revenue" line on our earnings statements and think that just doesn't matter and somehow we have to get the "real" money from ads. We definitely did ads-supported-consumer first and we've been doing it the longest and it makes the most money, but how many email providers would kill to have half of that quarter as their _annual_ revenue? G Suite, Cloud, etc are very real businesses in their own right and that's even while being very young and coming from a company that didn't start with any inherent strengths in enterprise markets.

</comment></comment></comment><comment><USER4> I believe Google is a surveillance company, and I like to think that anything they do has something to do with that. I would love someone to prove me wrong though, because what they're doing is so dystopian.

<comment><USER5> > would love someone to prove me wrong though

The burden of proof lies on the person making claims. I'm not asserting that your claims are wrong, but if you want people to take your statements seriously you need to provide proof.

In order to practice what I teach, here's an article: [https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)](https://en.wikipedia.org/wiki/Burden_of_proof_\(philosophy\)).

EDIT: Fixed paragraph formatting

<comment><USER6> I mean, it's literally no secret that Google collects user information, contents of emails, browsing history, etc and uses it to target advertisements to users. If you use a google product or service for more than 5 minutes, you literally see it happening.

<comment><USER5> OK, I guess that depends on how you define surveillance. I think of surveillance as having some kind of relation to the state, for example a private investigator looking into a court matter, a company sharing information with the government (outside of warrants), etc. If we're taking surveillance to mean general tracking, then yes the OP's statement probably doesn't need further evidence.

<comment><USER6> I think most folks associate surveillance with this definition of the word: "continuous observation of a place, person, group, or ongoing activity in order to gather information"

</comment></comment></comment></comment></comment><comment><USER7> Google will capture your data whether you're a paying customer of not. They will tell you they capture "some data" to personalise their service and make your life more convenient. In reality, they capture everything they can and it's all grist to their advertising mill.

But Google is not the only company doing this. Facebook and Amazon will track you across the internet, and even Microsoft is now adopting similar strategies.

Your best defence is to minimise the attack surface. Own your own data by paying for cloud storage and email. Use a browser like Brave, or Firefox with the new privacy control turned on. Don't post anything to social media you wouldn't be happy for the whole world to know.

<comment><USER7> If you can cope with living in a walled garden, replace all your devices with Apple products.

<comment><USER8> I find it really hard to tell if you are cynical or not :-)

Not making any statement about the current Apple, of course... which I know next to nothing about since I've never owned any Apple devices.

<comment><USER9> Apple makes some pretty strong claims about your privacy as a customer:

[https://www.apple.com/privacy/](https://www.apple.com/privacy/)

</comment></comment></comment></comment><comment><USER10> Yes, and they are known to scan it and kick people off for "inappropriate" content under a very subjective and not equally enforced set of standards. This is why I don't recommend Google Cloud to clients.

<comment><USER11> Do you mean they scan your files and will kick you off for running a porn business because of the content in your slides/sheets/files. Or are you saying, if you run a church they will kick you off for occasional porn browsing?

Using porn as an example of possibile subjective inappropriateness

<comment><USER12> It means that storing child pornography on the cloud is against the tos.

</comment></comment></comment><comment><USER13> Yes on two levels:

1\. If you're logged into Chrome or using Google properties, they're using your behavior along with everyone else's to see what patterns people have, what sites are popular, which ads convert, etc. If they were to stop doing that tracking whenever you're logged into a GSuite account, they'd publicize that loudly and clearly as a selling point. Given that they don't, I think it's reasonable to believe that they treat GSuite customers' behavioral data the same as all other users'.

2\. Specifically your use/behavior of the GSuite products they will also use to improve the GSuite products themselves (and sell more, thereby advancing their business model). For example, if they see that nobody is using a particular feature, they may change where it shows up or eliminate it.

What they clearly publicize that they don't do is mine the content of your documents or put advertising inside the GSuite products themselves. But all the behavioral data/metadata you generate will still be used alongside everyone else's.

</comment><comment><USER14> Page 12 [https://storage.googleapis.com/gfw-touched-accounts- pdfs/goo...](https://storage.googleapis.com/gfw-touched-accounts-pdfs/google- cloud-security-and-compliance-whitepaper.pdf)

<comment><USER15> I used to pay for GSuite and still found my content being mined. With all due respect to Google, I find it hard to believe that they're as consistent as they believe with filtering paid vs free accounts across the service.

I could be, and am open to being, wrong, though. I'm not Google. Just found myself with substantially less targeted advertising once I left.

And actually that's slightly interesting - how does one determine a bug re: being the recipient of targeted ads when you shouldn't be? Probably wording it wrong without coffee in me, but I hadn't thought of it like that.

<comment><USER16> > found my content being mined

How?

<comment><USER15> turc1656 (other direct reply to you) noted what I was getting at, but to expand on it...

I'm pretty careful about what I share with various services. Facebook (Instagram, etc) are all silo'd off to separate access points, phone is devoid of any of them, you get the gist. The only thing I didn't mind was Google, since I was paying for it, and it's easy to think that paying for it means it'll work how you expect it to and your privacy is intact.

Thus I'd keep Google apps signed in to the account, and I'd keep a tab open with Gmail all day, so short of incognito tabs, I was almost always signed into it.

Your _email_ isn't scanned, but Google doesn't even do that for free email accounts since..., what, 2014? Most people who decry the whole Gmail reading emails angle don't seem to understand this. They still track you as you move around for advertising purposes, though, and that was enough to make me just not want a Google account.

Siloing social media probably reduced my targeted advertising by 20%, and the absolute biggest reduction I found in my life was by getting rid of Google. It's honestly jaw dropping how much tailored content you get shoved at you that "waking up" from it can blow your mind (read: less depression, fomo, and so on, which more people seem to be catching on to).

YMMV though. I don't hate advertising and think it certainly has a place in society, and some people find it useful/fine/acceptable. Just noting my experiences.

<comment><USER17> > They still track you as you move around for advertising purposes, though, > and that was enough to make me just not want a Google account.

Firefox containers solved[1] this for me. They are probably the biggest privacy boost I've felt for a decade. I've got three separate Google containers (private Google account and general Google properties like youtube, and two separate Gsuite accounts), individual Facebook, Reddit and HN containers, a separate containers for various banks I interact with, another separate for online purchases (plus goodreads, because I don't want Amazon to leak), and an individual Pandora one (because why not?).

1: Well, "solved" in that it's harder for them. They can still track me, but at least now they get conflicting cookies from different types of sites but the same IP which might confuse their metrics some. I'm aware I'm probably just making it harder to state anything about me with too much confidence at most.

<comment><USER15> Yes, but Firefox on Mac is honestly nowhere near the level of polish that other browsers are, so I only use it for social media. My default browser is Safari, which never sees a Google signin anymore. _shrug_

Highly recommended tho.

</comment></comment></comment></comment></comment></comment><comment><USER18> It looks like a lot of people went straight to "Google said they don't scan your documents for advertising purposes" and skipped over your actual question, which was "does Google scan everything I do in Chrome when I'm logged in even if I pay for GSuite" and I'm pretty sure the answer is yes.

</comment><comment><USER19> I'd be very surprised if Google _wasn 't_ doing that with your data. It's their business model.

<comment><USER20> Except when someone's paying them cold hard cash for something like G Suite, you'd think that _should_ be enough of a business model for them...but I think you're right to remain skeptical of that. :\

</comment></comment><comment><USER21> Officially not.

In reality, nobody knows, and given their business model I wouldn't be surprised if they did anyway.

<comment><USER22> Based on the Googler's comment above, I think both are true. I can fully believe that test data has to be obtained from certain sources for development and whatnot. But once the algorithm is in production , I'm sure its sifting though your stuff as you are browsing just like everything else.

</comment></comment><comment><USER23> Ill link to the official docs from Google:

[https://gsuite.google.com/learn-more/security/security- white...](https://gsuite.google.com/learn-more/security/security- whitepaper/page-6.html)

</comment><comment><USER24> If you want an answer from someone who actually knows, consider contacting your gsuites account rep or asking on the support forum for gsuite. It is apparent from the other responses find their root in uninformed paranoia rather than actual knowledge.

(I don't actually know either, and I think it depends on what you mean by "scan" and what program you're worried is doing said scanning. It also depends what you mean by "for their own benefit.")

</comment><comment><USER25> Anecdotally, a couple of weeks ago I made a "budget" spreadsheet in google sheets and since then I've been getting the same youtube ad for a money management app, over and over again. I hadn't seen the ad before and the spreadsheet is the only change in my behaviour on google services that I can think of.

<comment><USER26> Did you search for anything budget related?

</comment></comment><comment><USER27> I don't belive they scan the contents of your documents/emails, but I do beleive they use metadata and behavior.

I'm conflicted because part of me thinks using their paid services encourages them to pursue a more Apple-link business model where advertising dollars are not the end goal, but it just doesn't seem to be their mission at all.

</comment><comment><USER28> Your data are on their server? If yes you simply can't no and (the need of) trust is a weakness. Since you can only trust them you are in a weak position as a user, be confident enough than that your data's will be used is some way.

</comment><comment><USER29> Of course they do. How could you be so naive?

</comment><comment><USER30> No.

</comment><comment><USER31> This is one of the reasons why I wrote my essay/overview, to investigate these problems.

</comment><comment><USER32> it's a FAANG world and we just live under it.</comment>


Chrome to get lazy load below-the-fold images and iframes - <AUTHOR> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/jxiJvQc-gVg <comment><USER2> This feature seems to be involved. In order to layout the html page you need to know the image sizes(unless they are explicit), and for that you still need to download the image header, and the headers are of different sizes for different returned image formats. And some images change when you load them second time.

So it seems the only way to correctly implement that is to open a connection to load an image and stall it after receiving the content-type and appropriate image header and hope that the server will not close the hanging connection(?)

PS: Seems that chrome will download the first 2K if byte-ranges are supported. If there is no dimensions in the first 2kb or byte-ranges are not supported, the full image will be downloaded non-lazily [https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...](https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#)

<comment><USER3> There's a link explaining how it's done!

It tries things in this order:

1\. If the full image is present and fresh in the cache, then use that.

2\. Otherwise, if the server supports range requests, and the image dimensions can be decoded from the first 2KB of the image, then generate and show an image placeholder with the same dimensions.

3\. Otherwise, fetch the entire full image from the server as usual.

So, it'll only lazy-load images if it's in the cache or certain criteria is met. Also, it seems like it's opt-in using an attribute, so the implementer of the website can avoid it if they're worried. But overall, there won't be any reflow issues.

[https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...](https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#)

<comment><USER4> Why does it download the 2kb if the image dimensions are specified?

<comment><USER5> The doc states 2 reasons:

\- If the image is fits in 2kb (icons/ui elements) then they can just do a full decode and not have to lazy load these ui items as the page scrolls.

\- It allows them to load low resolution versions of progressive image formats rather than stick up a generic placeholder (marked as a future improvement right now).

<comment><USER4> For your first point, reading the specified dimensions from the page would be sufficient to tell the browser whether it's a small image to skip lazy loading.

</comment></comment></comment></comment></comment><comment><USER6> No need to rely on IntersectionObserver() or even for JavaScript to be enabled -- Adtech vendors (like Google) can now detect scroll position server-side!

<comment><USER7> What? As far as I know this feature is completely client-side.

<comment><USER7> I see.. but this would only make a difference for people who disabled JS, and these people can probably also disable lazy loading.

<comment><USER5> Assuming lazy loading remains a flag. Chrome just removed the flag to disable hyperlink auditing and that one was even blatantly about privacy.

</comment></comment></comment></comment><comment><USER8> Why they say they are pushing this:

* "Speed up the load of above-the-fold content, since there will be less competition for network resources during the initial page load"

Why don't they just set a low priority for offscreen images and resources? Isn't this the entire premise for HTTP/2, that multiplexing with priorities and flow control would load the important data first? Do servers not implement the spec correctly? So this reason is BS as the data saved is immaterial.

* "Reduce memory usage."

Even commodity phones come with several gigabytes of RAM, the memory may have to be used anyway if the user scrolls, and if you have unlimited scroll or massive scroll something will need to unload data anyway. So this reason is marginal at best.

* "Save network data by avoiding downloading any deferred content that the user doesn't end up scrolling to"

Most phone plans are unlimited or have data capable of watching movies. On Google's own Fi plan "less than 1% of individual Fi users ... use above 15 GB". So this is another BS reason as the data saved is immaterial.

So why are they _actually_ pushing this?

Under "privacy considerations": "so slightly more information about the user's scrolling position on the embedding page is exposed" and "a deferred cross- origin image gets an additional piece of information about the user's scrolling position".

This is not hard to figure out - they are barely even trying to hide it. Same thing as pushing HTTP/2, which I contend was at least partly to track people using socket IP:port address (for instance by keeping a single connection to google-analytics open that all domains' data goes through and boosting the connection keep alive from a few minutes to like half an hour, which they did).

<comment><USER9> Wow, how can this conspiracy-theory-like nonsense be voted to the top of the comments? I thought Hacker News was a rational place.

The reality is that lazy loading images really does help webpage performance, especially on mobile. You cannot properly implement it in the browser without additional information from the page developer - because you'll never know which images are so important that they will _always_ need to be loaded, and which ones can be lazy loaded once they're almost in view.

We're talking about the addition of one attribute to the <img> tag here. There's no conspiracy, and there's no ulterior motive.

<comment><USER8> No we're talking about every website having to make this work because the default is to not require loading the resources or else be blamed for not being compliant with a spec forced on them by Google through their browser monopoly.

Google should need some really good evidence to support this.

What points do you disagree with, and why? Where are the metrics? If it's better performing than just priorities and flow control then by how much, and how do you justify breaking sites to achieve that margin?

<comment><USER10> Then just don't specify the loading=lazy tag...

<comment><USER11> Doesn't matter. The actual discussion on blink-dev is pretty clear about the plan being for lack of that attribute to mean "use some heuristics of Google's choice to decide whether to lazy-load".

</comment></comment></comment></comment></comment><comment><USER12> The downside of this is that it assumes that I am always online, and I can never know if a page has finished loading. Say I load an article in a background tab to read later, then go somewhere without WiFi like, say, an airplane. I read the first page, hit the space bar, and see gray boxes. Now I need to either scroll all the way through any article I want to read later (unless "infinite scroll" happens), or save it as a web archive (if that even still works).

<comment><USER13> Tons of web pages (especially e-commerce sites where initial visible page load time is critical) already do this, just with more complicated code.

<comment><USER12> And mobile browsers randomly purge and reload pages when they're low on memory, and news sites do lazy image loading with miscellaneous Javascript. It all sucks, and it's too bad that Google wants to (i.e. will) "make it official."

<comment><USER13> You think this sucks? So instead of optimizing for the 99% case where I go to a site and want to see the images on the page as fast as possible and defer loading what I can't see initially, you instead want to prioritize "Say I load an article in a background tab to read later, then go somewhere without WiFi like, say, an airplane."???

Thanks, I'll take Google's solution.

</comment></comment></comment></comment><comment><USER14> I've had the idea of doing a similar thing in application code for XHRs. For example, if you have a React app and you structure your code so that components declare their own data dependencies, then you can have a framework- level solution where you measure component positions on mount and give priority to data fetching for components above the fold.

I never actually implemented it, though, just seemed like a nice idea. Anyone know if existing data fetching frameworks (e.g. Apollo Client) can do anything like that?

</comment><comment><USER15> How is this only now getting implemented? I'm very surprised.

Also, do we yet unload images (from memory) after a user scrolls far past them?

I'm always surprised how slow "long" webpages become.

<comment><USER16> > do we yet unload images (from memory) after a user scrolls far past them?

Last time I looked, the answer was no for images but yes for background images. I implemented a lazy-loader which did the latter for a pretty significant measured improvement on gallery pages.

</comment></comment><comment><USER17> The post says "Firefox: No public signals" \- does that mean there is no word from Firefox if it'll be implemented in Firefox?

<comment><USER18> There is an open Firefox bug about it:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1535749](https://bugzilla.mozilla.org/show_bug.cgi?id=1535749)

But the last comment raises concerns about privacy implications it may have. So, I think that right now it is unclear whether Firefox will eventually implement it and in what form.

<comment><USER19> That's not this. Bug 1535749 is about lazy-loading images on the new tab page, not about implementing native support for the "loading" attribute on img tags.

</comment></comment></comment><comment><USER20>
      On Android Chrome with Data Saver turned on, elements with loading="auto" or
      unset will also be lazily loaded if Chrome determines them to be good
      candidates for lazy loading (according to heuristics).

I don't agree with this design decision to make the default ("or unset...") allow for lazy loading, even if limited to Data Saver enabled phones. Doesn't this mean every site on the planet that deems Android >= 7.0 web traffic important and makes use of pixel-based or iframe-enclosed tracking will have to go through testing and potential modification?

</comment><comment><USER21> How will this affect analytics with tracking pixels, etc?

<comment><USER22> I think that this could be a boon to pixel tracking. From my understanding, a site could embed multiple tracking pixels on a page to give a good approximation of how far the user scrolls and how long it takes them to scroll down the page, all without JavaScript.

I would be curious if this would also be apply to email clients that render using Chrome.

</comment></comment><comment><USER23> So that means the ads load right away and then the content loads later, if at all?

</comment><comment><USER24> Previous discussion [https://news.ycombinator.com/item?id=19596458](https://news.ycombinator.com/item?id=19596458)

</comment><comment><USER25> The new attribute's value names look poorly chosen. "Lazy" and "eager". Why don't they use existing vocabulary like "deferred" for lazy, and a new, equally professional word for eager.

<comment><USER26> "lazy" and "eager" _are_ the pre-existing widely used terms for this.

</comment></comment><comment><USER27> Firefox is also planning to add support for off-screen image lazy-loading.

[1]: [https://bugzilla.mozilla.org/show_bug.cgi?id=1535749](https://bugzilla.mozilla.org/show_bug.cgi?id=1535749)

<comment><USER19> That's incorrect. See clarification at [https://news.ycombinator.com/item?id=19604145](https://news.ycombinator.com/item?id=19604145)</comment></comment>


December Does Not Exist In Android 4.2 - <AUTHOR> http://www.androidpolice.com/2012/11/17/sorry-santa-google-cancels-december-in-android-4-2/

<comment><USER2> Look, we have all been there. Counting while starting at zero is fucking hard.

<comment><USER3> It isn't surprising that a programmer made an off-by-one error, they happen all the time. But it is surprising that it made it through a release without being caught by some sort of QA process.

</comment></comment><comment><USER4> <http://news.ycombinator.com/item?id=4798930></comment>