[HN Gopher] Compiler Explorer and the promise of URLs that last ...
___________________________________________________________________
Compiler Explorer and the promise of URLs that last forever
Author : anarazel
Score : 172 points
Date : 2025-05-28 16:28 UTC (6 hours ago)
(HTM) web link (xania.org)
(TXT) w3m dump (xania.org)
| jimmyl02 wrote:
| This is great perspective about how assumptions play out over
| longer period of time. I think that this risk is much greater for
| _free_ third party services for critical infrastructure.
|
| Someone has to foot the bill somewhere and if there isn't a
| source of income then the project is bound to be unsupported
| eventually.
| tekacs wrote:
| I think I would struggle to say that free services die at a
| higher rate consistently...
|
| So many paid offerings, whether from startups or even from
| large companies, have been sunset over time, often with
| frustratingly short migration periods.
|
| If anything, I feel like I can think of more paid services that
| have given their users short migration periods than free ones.
| lqstuart wrote:
| Counterexample: the Linux kernel
| charcircuit wrote:
| How? Big tech foots the bill.
| shlomo_z wrote:
| But goo.gl is also big tech...
| iainmerrick wrote:
| Linux isn't a service (in the SaaS sense).
| cortesoft wrote:
| Nah, businesses go under all the time, whether their services
| are paid or not.
| amiga386 wrote:
| https://killedbygoogle.com/
|
| > Google Go Links (2010-2021)
|
| > Killed about 4 years ago, (also known as Google Short Links)
| was a URL shortening service. It also supported custom domain for
| customers of Google Workspace (formerly G Suite (formerly Google
| Apps)). It was about 11 years old.
| zerocrates wrote:
| "Killing" the service in the sense of minting new ones is no
| big deal and hardly merits mention.
|
| Killing the existing ones is much more of a jerk move.
| Particularly so since Google is still keeping it around in some
| form for internal use by their own apps.
| mananaysiempre wrote:
| May be worth cooperating with ArchiveTeam's project[1] on Goo.gl?
|
| > url shortening was a fucking awful idea[2]
|
| [1] https://wiki.archiveteam.org/index.php/Goo.gl
|
| [2] https://wiki.archiveteam.org/index.php/URLTeam
| MallocVoidstar wrote:
| IIRC ArchiveTeam were bruteforcing Goo.gl short URLs, not going
| through 'known' links, so I'd assume they have many/all of
| Compiler Explorer's URLs. (So, good idea to contact them)
| shepmaster wrote:
| As we all know, Cool URIs don't change [1]. I greatly appreciate
| the care taken to keep these Compiler Explorer links working as
| long as possible.
|
| The Rust playground uses GitHub Gists as the primary storage
| location for shared data. I'm dreading the day that I need to
| migrate everything away from there to something self-maintained.
|
| [1]: https://www.w3.org/Provider/Style/URI
| kccqzy wrote:
| Before 2010 I had this unquestioned assumption that links are
| supposed to last forever. I used the bookmark feature of my
| browser extensively. Some time afterwards, I discovered that a
| large fraction of my bookmarks were essentially unusable due to
| linkrot. My modus operandi after that was to print the webpage as
| a PDF. A bit afterwards when reader views became popular
| reliable, I just copy-pasted the content from the reader view
| into an RTF file.
| flexagoon wrote:
| By the way, if you install the official Web Archive browser
| extension, you can configure it to automatically archive every
| page you visit
| petethomas wrote:
| This a good suggestion with the caveat that entire domains
| can and do disappear: https://help.archive.org/help/how-do-i-
| request-to-remove-som...
| vitorsr wrote:
| > you can configure it to automatically archive every page
| you visit
|
| What?? I am a heavy user of the Internet Archive services,
| not just the Wayback Machine, including official and
| "unofficial" clients and endpoints, and I had absolutely no
| idea the extension could do this.
|
| To bulk archive I would manually do it via the web interface
| or batch automate it. The limitations of manually doing it
| one by one are obvious, and the limitations of doing it in
| batches requires, well, keeping batches (lists).
| internetter wrote:
| recently I've come to believe even IA and especially
| archive.is are ephermal. I've watched sites I've saved
| disappear without a trace, except in my selfhosted archives.
|
| A technological conundrum, however, is the fact that I have
| no way to prove that _my_ archive is an accurate
| representation of a site at a point in time. Hmmm, or maybe I
| do? Maybe something funky with cert chains could be done.
| akoboldfrying wrote:
| There are timestamping services out there, some of which
| may be free. It should (I think) be possible to basically
| submit the target site's URL to the timestamping service,
| and get back a certificate saying "I, Timestamps-R-US,
| assert that the contents of https://targetsite.com/foo/bar
| downloaded at 12:34pm on 29/5/2025 hashes to abc12345 with
| SHA-1", signed with their private key and verifiable (by
| anyone) with their public key. Then you download the same
| URL, and check that the hashes match.
|
| IIUC the timestamping service needs to independently
| download the contents itself in order to hash it, so if you
| need to be logged in to see the content there might be
| complications, and if there's a lot of content they'll
| probably want to charge you.
| XorNot wrote:
| Websites don't really produce consistent content even
| from identical requests though.
|
| But you also don't need to do this: all you need is a
| service which will attest that it saw a particular
| hashsum at a particular time. It's up to other mechanisms
| to prove what that means.
| 90s_dev wrote:
| My solution has been to just remember the important stuff, or
| at least where to find it. I'm not dead yet so I guess it
| works.
| TeMPOraL wrote:
| It was my solution too, and I liked it, but over the past
| decade or so, I noticed that even when I remember where to
| find some stuff, hell, even if I just remember _how_ to find
| it, when I actually try and find it, it often isn 't there
| anymore. "Search rot" is just as big a problem as link rot.
|
| As for being still alive, by that measure hardly anything
| anyone does is important in the modern world. It's pretty
| hard to fail at thinking or remembering so badly that it
| becomes a life-or-death thing.
| nonethewiser wrote:
| A reference is a bet on continuity.
|
| At a fundamental level, broken website links and dangling
| pointers in C are the same.
| lappa wrote:
| I use the SingleFile extension to archive every page I visit.
|
| It's easy to set up, but be warned, it takes up a lot of disk
| space. $ du -h ~/archive/webpages
| 1.1T /home/andrew/archive/webpages
|
| https://github.com/gildas-lormeau/SingleFile
| davidcollantes wrote:
| How do you manage those? Do you have a way to search them, or
| a specific way to catalogue them, which will make it easy to
| find exactly what you need from them?
| 90s_dev wrote:
| You must have several TB of the internet on disk by now...
| internetter wrote:
| storage is cheap, but if you wanted to improve this:
|
| 1. find a way to dedup media
|
| 2. ensure content blockers are doing well
|
| 3. for news articles, put it through readability and store
| the markdown instead. if you wanted to be really fancy,
| instead you could attempt to programatically create a
| "template" of sites you've visited with multiple endpoints so
| the style is retained but you're not storing the content.
| alternatively a good compression algo could do this, if you
| had your directory like /home/andrew/archive/boehs.org.tar.gz
| and inside of the tar all the boehs.org pages you visited are
| saved
|
| 4. add fts and embeddings over the pages
| ashirviskas wrote:
| 1 and partly 3 - I use btrfs with compression and deduping
| for games and other stuff. Works really well and is
| "invisible" to you.
| macawfish wrote:
| Use WARC: https://en.wikipedia.org/wiki/WARC_(file_format) with
| WebRecorder: https://webrecorder.net/
| andai wrote:
| Is there some kind of thing that turns a web page into a text
| file? I know you can do it with beautiful soup (or like 4 lines
| of python stdlib), but I usually need it on my phone, where I
| don't know a good option.
|
| My phone browser has a "reader view" popup but it only appears
| sometimes, and usually not on pages that need it!
|
| Edit: Just installed w3m in Termux... the things we can do
| nowadays!
| XorNot wrote:
| You want Zotero.
|
| It's for bibliographies, but it also archives and stores web
| pages locally with a browser integration.
| taeric wrote:
| That assumption isn't true of any sources? Things flat out
| change. Some literally, others more in meaning. Some because
| they are corrected, but there are other reasons.
|
| Not that I don't think there is some benefit in what you are
| attempting, of course. A similar thing I still wish I could do
| is to "archive" someone's phone number from my contact list. Be
| it a number that used to be ours, or family/friends that have
| passed.
| rubit_xxx16 wrote:
| > Before 2010 I had this unquestioned assumption that links are
| supposed to last forever
|
| Any site/company whatsoever that promises that anything will
| last forever is seriously deluded or intentionally lying,
| unless their theory of time is different than that of the
| majority.
| diggan wrote:
| URLs (uniform resource locator) cannot ever last forever, as it's
| a _location_ and locations can 't last forever :)
|
| URIs however, can be made to last forever! Also comes with the
| added benefit that if you somehow integrate content-addressing
| into the identifier, you'll also be able to safely fetch it from
| any computer, hostile or not.
| 90s_dev wrote:
| I've been making websites for almost 30 years now.
|
| I still don't know the difference between URI and URL.
|
| I'm starting to think it doesn't matter.
| diggan wrote:
| > I still don't know the difference between URI and URL.
|
| One is a location, the other one is a ID. Which is which is
| referenced in the name :)
|
| And sure, it doesn't matter as long as you're fine with
| referencing _locations_ rather than the actual data, and
| aware of the tradeoffs.
| Sesse__ wrote:
| It doesn't matter.
|
| URI is basically a format and nothing else. (foo://bar123
| would be a URI but not a URL because nothing defines what
| foo: is.)
|
| URLs and URNs are thingies using the URI format;
| https://news.ycombinator.com is a URL (in addition to being a
| URI) because there's an RFC that specifies that https: means
| and how to go out and fetch them.
|
| urn:isbn:0451450523 (example cribbed from Wikipedia) is an
| URN (in addition to being an URI) that uniquely identifies a
| book, but doesn't tell you how to go find that book.
|
| Mostly, the difference is pedantic, given that URNs never
| took off.
| 90s_dev wrote:
| It's almost like URNs were born in an _urn_! [1]
|
| [1]: _ba dum tss_
| marcosdumay wrote:
| An URI is an standard way to write names of documents.
|
| And URL is an URI that also tells you how to find the
| document.
| layer8 wrote:
| URLs in the strict sense are a subset of URIs. They specify a
| mechanism (like HTTP or FTP) for how to access the referenced
| resource. The other type of URIs are opaque IDs, like
| doi:10.1000/182 or urn:isbn:9780141036144. These technically
| can't expire, though that doesn't mean you'll be able to
| access what they reference.
|
| However, "URL" in the broader sense is used as an umbrella
| term for URIs and IRIs (internationalized resource
| identifiers), in particular by WHATWG.
|
| In practice, what matters is the specific URI scheme ("http",
| "doi", etc.).
| postoplust wrote:
| For example: IPFS URI's are content addresses
|
| https://docs.ipfs.tech/
| olalonde wrote:
| > This article was written by a human, but links were suggested
| by and grammar checked by an LLM.
|
| This is the second time today I've seen a disclaimer like this.
| Looks like we're witnessing the start of a new trend.
| tester756 wrote:
| It's crazy that people feel that they need to put such
| disclaimers
| layer8 wrote:
| It's more a claimer than a disclaimer. ;)
| psychoslave wrote:
| This comment was written by a human with no check by any
| automaton, but how will you check that?
| actuallyalys wrote:
| It makes sense to me. After seeing a bunch of AI slop, people
| started putting no AI buttons and disclaimers. Then some
| people using AI for little things wanted to clarify it wasn't
| AI generated wholesale without falsely claiming AI wasn't
| involved at all.
| 90s_dev wrote:
| Some famous programmer once wrote about how links should last
| forever.
|
| He advocated for /foo/bar with no extension. He was right about
| not using /foo/bar.php because the _implementation_ might change.
|
| But he was wrong, it should be /foo/bar.html because the _end-
| result_ will always be HTML when it 's served by a browser,
| whether it's generated by PHP, Node.js or by hand.
|
| It's pointless to prepare for some hypothetical new browser that
| uses an _alternate_ language _other than HTML_ and that _doesn
| 't_ use HTML.
|
| Just use .html for your pages and stop worrying about how to
| correctly convert foo.md to foo/index.html and configure nginx
| accordingly.
| Dwedit wrote:
| mod_rewrite means you can redirect the .php page to something
| else if you stop using php.
| shakna wrote:
| Unless mod_rewrite is disabled, because it has had a few
| security bugs over the years. Like last year. [0]
|
| [0] https://nvd.nist.gov/vuln/detail/CVE-2024-38475
| 90s_dev wrote:
| Found it: https://www.w3.org/Provider/Style/URI
|
| Why did I think Joel Spolsky or Jeff Atwood wrote it?
| Sesse__ wrote:
| > Some famous programmer once wrote about how links should last
| forever.
|
| You're probably thinking of W3C's guidance:
| https://www.w3.org/Provider/Style/URI
|
| > But he was wrong, it should be /foo/bar.html because the end-
| result will always be HTML
|
| 20 years ago, it wasn't obvious at all that the end-result
| would always be HTML (in particular, various styled forms of
| XML was thought to eventually take over). And in any case,
| there's no reason to have the content-type in the URL; why
| would the user care about that?
| 90s_dev wrote:
| There's strong precedence for associating file extensions
| with content types. And it allows static files to map 1:1 to
| URLs.
|
| I agree though that I was too harsh, I didn't realize it was
| written in 1998 when HTML was still new. I probably first
| read it around 2010.
|
| But now that we have hindsight, I think it's safe to say
| .html files will continue to be supported for the next 50
| years.
| crackalamoo wrote:
| I use /foo/bar/ with the trailing slash because it works better
| with relative URLs for resources like images. I could also use
| /foo/bar/index.html but I find the former to be cleaner
| 90s_dev wrote:
| It's always bothered me in a small way that github doesn't
| honor this:
|
| https://github.com/sdegutis/bubbles
|
| https://github.com/sdegutis/bubbles/
|
| No redirect, just two renders!
|
| It bothers me first because it's semantically different.
|
| Second and more importnatly, because it's always such a pain
| to configure that redirect in nginx or whatever. I eventually
| figure it out each time, after many hours wasted looking it
| up all over again and trial/error.
| esafak wrote:
| If it's always .html, it's cruft; get rid of it. And what if
| it's not HTML but JSON? Besides, does the user care? Berners-
| Lee was right.
|
| https://www.w3.org/Provider/Style/URI
| 90s_dev wrote:
| If it's JSON then name it /foo/bar.json, and as a bonus you
| can _also_ have /foo/bar.html!
|
| You say the extension is cruft. That's your opinion. I don't
| share it.
| marcosdumay wrote:
| The alternative is to declare what you want on the Accept
| header, what is way less transparent but is more flexible.
|
| I never saw any site where the extra flexibility added any
| value. So, right now I do favor the extension.
| swyx wrote:
| idk man how can URLs last forever if it costs money to keep a
| domain name alive?
|
| i also wonder if url death could be a good thing. humanity makes
| special effort to keep around the good stuff. the rest goes into
| the garbage collection of history.
| johannes1234321 wrote:
| Historians however would love to have more garbage from
| history, to get more insights on "real" life rather than just
| the parts one considered worth keeping.
|
| If I could time jump it would be interesting to see how
| historians inna thousand years will look back at our period
| where a lot of information will just disappear without traces
| as digital media rots.
| swyx wrote:
| we'd keep the curiosities around, like so much Ea Nasir Sells
| Shit Copper. we have room for like 5-10 of those per century.
| not like 8 billion. much of life is mundane.
| rightbyte wrote:
| Imagine being judged 1000s of year later by some Yelp
| reviews like poor Nasir.
| woodruffw wrote:
| > much of life is mundane.
|
| The things that make (or fail to make) life mundane at some
| point in history are themselves subjects of significant
| academic interest.
|
| (And of course we have no way to tell what things are
| "curiosities" or not. Preservation can be seen as a way to
| minimize survivorship bias.)
| cortesoft wrote:
| Today's mundane is tomorrow's fascination
| shakna wrote:
| We also have rooms full of footprints. In a thousand years,
| your mundane is the fascination of the world.
| mrguyorama wrote:
| I regularly wonder if modern educated people do not journal
| as much as previous century educated people who were kind of
| rare.
|
| Maybe we should get a journaling boom going.
|
| But it has to be written, because pen and paper is literally
| ten times more durable than even good digital storage.
| swyx wrote:
| > pen and paper is literally ten times more durable than
| even good digital storage.
|
| citation needed lol. data replication >>>> paper's single
| point of failure.
| internetter wrote:
| > i also wonder if url death could be a good thing. humanity
| makes special effort to keep around the good stuff. the rest
| goes into the garbage collection of history.
|
| agreed. formerly wrote some thoughts here:
| https://boehs.org/node/internet-evanescence
| s17n wrote:
| URLs lasting forever was a beautiful dream but in reality, it
| seems that 99% of URLs don't in fact last forever. Rather than
| endlessly fighting a losing battle, maybe we should build the
| technology around the assumption that infrastructure isn't
| permanent?
| nonethewiser wrote:
| >maybe we should build the technology around the assumption
| that infrastructure isn't permanent?
|
| Yes. Also not using a url shortener as infrastructure.
| hoppp wrote:
| Yes.
|
| domain names often exchange hands and a URL that is supposed to
| last forever can turn into malicious phishing link over time.
| emaro wrote:
| In theory a content-addressed system like IPFS would be the
| best: if someone online still has a copy, you can get it too.
| devnullbrain wrote:
| >despite Google solemnly promising that "all existing links will
| continue to redirect to the intended destination," it went read-
| only a few years back, and now they're finally sunsetting it in
| August 2025
|
| It's become so trite to mention that I'm rolling my eyes at
| myself just for bringing it up again but... come on! How bad can
| it be before Google do something about the reputation this
| behaviour has created?
|
| Was Stadia not an expensive enough failure?
| creatonez wrote:
| There's something poetic about abusing a link shortener as a
| database and then later having to retrieve all your precious
| links from random corners of the internet because you've lost the
| original reference.
| nonethewiser wrote:
| Didnt they just use the link shortener to compress the url?
| They used their url as the "database" (ie holding the compiler
| state).
| Arcuru wrote:
| They didn't store anything themselves since they encoded the
| full state in the urls that were given out. So the link
| shortener was the only place where the "database", the urls,
| were being stored.
| nonethewiser wrote:
| Yeah but the purpose of the url shortener was not to store
| the data, it was to shorten the url. The fact that the data
| was persisted on google's sever somewhere is incidental.
|
| In other words, every shortened url is "using the url
| shortener as a database" in that sense. Taking a url with a
| long query parameter and using a url shortener to shorten
| it does not constitute "abusing a link shortener as a
| database."
| cortesoft wrote:
| Except in this case the url IS the data, so storing the
| url is the same as storing the data.
| nonethewiser wrote:
| Its incidental. The state is in the url which is only
| shortened because its so long. Google's url shortener is
| not needed to store the data.
|
| It's simply a normal use-case for a url shortener. A long
| url, usually because of some very large query parameter,
| which gets mapped to a short one.
| rs186 wrote:
| Shortening long URLs is the intended use case for a ... URL
| shortener.
|
| The real abusers are the people who use a shortener to hide
| scam/spam/illegal websites behind a common domain and post it
| everywhere.
| creatonez wrote:
| These are not just "long URLs". These are URLs where the
| _entire_ content is stored in the fragment suffix of the URL.
| They are blobs, and always have been.
| wrs wrote:
| I hate to say it, but unless there's a really well-funded
| foundation involved, Compiler Explorer and godbolt.org won't last
| forever either. (Maybe by then all the info will have been
| distilled into the 487 quadrillion parameter model of
| everything...)
| layer8 wrote:
| Thanks to the no-hiding theorem, the information will live
| forever. ;)
| layer8 wrote:
| I find it somewhat surprising that it's worth the effort for
| Google to shut down the read-only version. Unless they fear some
| legal risks of leaving redirects to private links online.
| actuallyalys wrote:
| Hard to say from the outside, but it's possible the service
| relies on some outdated or insecure library, runtime, service,
| etc. they want to stop running. Although frankly it seems just
| as possible it's a trivial expense and they're cutting it
| because it's still a net expense, goodwill and past promises be
| dammed.
| Scaevolus wrote:
| Typically services like these are side projects of just a few
| Google employees, and when the last one leaves they are shut
| down.
| mmooss wrote:
| Another possibility is that it's a distraction - whatever the
| marginal costs, there's a fixed cost to each system in terms
| of cognitive overhead, if not documentation, legal issues
| (which can change as laws and regulations change), etc.
| Removing distractions is basic management.
| sdf4j wrote:
| > One of my founding principles is that Compiler Explorer links
| should last forever.
|
| And yet... that was a very self-destructive decision.
| sedatk wrote:
| Surprisingly, purl.org URLs still work after a quarter century,
| thanks to Internet Archive.
| 2YwaZHXV wrote:
| Presumably there's no way to get someone at Google to query their
| database and find all the shortened links that go to godbolt.org?
___________________________________________________________________
(page generated 2025-05-28 23:00 UTC)