AMP is bad for the open web. Google is touting AMP as a way to reduce page load times, but it’s actually about pushing their proprietary HTML standard.
Google could easily reduce page load times if they penalized slow loading sites, but they won’t, because doing so doesns’t help push their agenda.
“…it’s actually about pushing their proprietary HTML standard.”
I don’t think that is quite it. AMP is Google’s equivalent of the Facebook walled garden, not socially, but attempting to constrain you to their walled off part of the internet. The longer they can keep you on a google server the better tracking they can do. See also gmail, YouTube, android, chrome. Don’t get me wrong, it’s still horrible, but I think tracking is the exact reason they created/bought all these products.
:) Very entertaining read. I’ve been picking up some smaller components in GO lately. I’ve also rewritten a component I originally built in Python in GO. Which gives a nice but anecdotal comparison:
Python: 11 days of development, performance, 160ms for ranking 3600 activities
GO: 3 days of development, performance, 6ms for ranking 3600 activities
The project is quite simple. It reads a ranking formula and turns it into a function which runs scoring on a large list of activities. Here’s an example ranking config:
So you basically you need to parse the score expression, translate it to AST, configure the defaults in the context, setup partials for the specified functions, add a bunch of builtin functions and create a huge set of test cases to make sure you’ve covered every possible way in which people can break it :)
With Python most of the time was spent on benchmarking and performance optimization. The GO code started out at 15ms and with some super simple optimization came down to 6. (GO also had the unfair advantage of a better expression parsing library being available.)
I used to believe that GO gives you better performance at the cost of developer productivity. For certain projects it definitely seems to beat Python at both productivity and performance though.
Is it possible that some of the drop in development time was due to being familiar with the application because you had already written it once before?
You beat me to it. There’s been a lot of rewrite stories debunked because the developers just got better at solving the problem since the first try. That included one with formal methods at IBM that got me where nobody mention it was a second implementation.
The proper comparison is doing them both the same way with same primitives. That is closer to apples to apples.
Yeay, it’s comparing apples and oranges :) On the other hand this was my first non-hello world GO project. I’ve been working with Python for 10 years now. GO is super easy to switch to if you’ve been working with Python.
Most of the time with the Python version was spent on performance optimization. I think GO hits a sweet spot. The language is easy to use and quite productive. Maybe not as easy as Ruby or Python, but pretty close. GO is also not as fast as C++ or Java (it depends a bit on the code you’re running, but in general it’s a little bit slower).
Basically you get close to C++ level performance at close to Python level ease of use. Now for most use cases i’d still recommend Python. (usually it’s just glue between heavily optimized databases and the overhead of python doesnt matter). But for use cases where the language performance matters, GO really hits a sweet spot.
Nit: it’s Go, not GO.
People are never going to get this right. It’s Go: not Golang, GO, Google’s Go, etc.
haha, that’s probably the hardest aspect of learning Go :)
Sorry this happened. As a US resident, I didn’t realize how crazy it can be entering or leaving the United States until I did so for the first time. The US was by far the hardest country to get into for me (even though I’m a citizen). It’s a shame that interactions with customs is such a mixed bag, and I worry that it is actually going to get worse for the time being.
I cross the border every single day (not a citizen), and have only ever been brought in once. But I also don’t do anything that would be considered suspicious by anyone.?
“I don’t mind <blank> because I have nothing to hide” is a slippery slope.
I don’t think that @zzing is making that argument.
Is this meant to be ironic? All I see rendered is a blank white page with two URLs and a short orange line on it.
Author here. Could you provide your OS and browser? I’ll look into a fix.
Sure: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 on Debian Jessie with NoScript, but I whitelisted the site in NoScript.
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Should be fixed. Looks like it was a bug in the Fira Sans font itself.
The problem is the web-font used in the article. Just overwrite the font-family-tag of <article> and the text is readable. A shame you have to go through this to read this article…
A quick fix would be to run on the site:
Firefox lets you disable custom fonts for all sites via the UI settings. Chrome has an extension called ‘Disable Web Fonts’. Since I’ve disabled web fonts, I’ve found my web experience has generally improved.
That worked; thanks. Whether the irony was intentional or not, it greatly amused me.