Brian Goetz - Stewardship: the Sobering Parts

To add on to that... Even though, I haven't been involved in the contributing process for Clojure, but I thought it was interesting that Brian Goetz's keynote at the Conj 6 months ago was about stewardship, in particular, stewardship of the Java language: [this video] It gave me a better appreciation for the differing concerns of someone using a language or contributing a patch vs. someone designing & maintaining a language. In my day-to-day, I use languages other than Clojure, and I sorely miss the cohesive and good design. Brian Goetz's talk nails it on the head why the languages in my day-to-day are sub-optimal, even if they're currently the "new hotness"... at least for now...

Against my better judgement I did a reverse image search and found the post that you found that screenshot from [1]. The post is full of people having exactly the sort of problems you would expect from an automatic software updater, along with instructions from Jeff on how to manually update using SSH and git. These things happen. The world is messy, and whether due to technical inadequacy or run-of-the-mill software updater bugs, web backends will not always be updated. As you've noted, this could eventually lead to security problems, and I agree -- but that doesn't justify intentionally breaking their code. To say that their breakage is justifiable because they'll be 0wned at some point anyway is an absurdly darwinian argument. To address your last question, the way you update a system like the web is exactly the way we always have -- accretion . With very few exceptions, websites from the early 90s still work today. We didn't remove the `table` tag when we introduced flex boxes. We add new APIs while preserving existing functionality. If you want to see a fantastic talk on this exact subject, watch "Stewardship: The Sobering Parts" by Brian Goetz [2]. It is well worth your time. [1] [link] [2] [this video]

It was raised in one of the initial proposals, back in 2002 [link] but that looks like a dead link and no wayback archive.. IIRC, basically it's because some parts of the JVM use stack unwinding to figure out what userland code is calling certain system code.. also the current stack frame has metadata about lock status used for allowing re-entrant locks that you lose if you elide the entire recursive call (which the initial proposal did by only removing the few bytecode instructions that set up the callstack frame and return from it). A more informal proposal from ~2016 allows for soft tail calls and hard (annotated) tail calls, with some restrictions that evidently avoid issues with system calls and lock/reentry maintenance: [link] And a video by one of the JVM architects at Oracle about adding TCO for Scala [this video] Also previously featured here on HN, a way to do it that avoids security concerns, by using goto instead of strictly deleting bytecode instructions: [link]