18 Hacker News comments link this video. Each one links back to its thread.
gwNov 2017Strongly recommends
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
in “Chrome breaks the Web” · View on HN
filereaperSep 2017Strongly recommends
Brian Goetz the Java Language Architect addressed the very points you raised in a talk called "Stewardship: the Sobering Parts" [1] I highly recommend anyone with these very valid concerns to view it once. [1] ▶ this video
in “Moving Java Forward Faster” · View on HN
filereaperJul 2016Strongly recommends
On the topic of stewardship, I highly recommend this talk by Brian Goetz titled "Stewardship: the Sobering Parts" [1] Brian goes about how important compatibility is for the language, the concept not throwing customers code under the bus by bringing breaking incompatibilities. (ie Python 2 --> 3) Java has its warts and isn't "cool" but I respect their design decisions. [1] ▶ this video
in “Oracle and the fall of Java EE” · View on HN
elangocMay 2015Strongly recommends
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...
in “Contributing to Clojure” · View on HN
nickikDec 2014Strongly recommends
Watch this awesome keynote by Brian Goetz, he talks about valie types and generics. Brian Goetz - Stewardship: the Sobering Parts ▶ this video
in “Introducing .NET Core” · View on HN
dgb23Aug 2023Recommends
Thank you for sharing this one! Also there are interesting talks published on YT where he discusses data/functional programming, OOP etc. Multiparadigm (including plain old procedural) seems to be the most pragmatic approach to me, because I don’t need to bend over backwards to express something in a particular way. Aside: It’s really fascinating how Java and the JVM manage to evolve while retaining reliability. He talks about that here: ▶ this video
in “Dart 3.1 and a retrospective on functional style programming in Dart” · View on HN
Show 12 more comments
devinSep 2020Recommends
I recommend Brian Goetz’ talk about language stewardship. I don’t think what you’ve said here is true, and it kind of bums me out because some of these features took years to develop so they wouldn’t break people on ancient versions. That deserves much respect and appreciation. ▶ this video
in “Checked exceptions: Java’s biggest mistake (2014)” · View on HN
carimuraSep 2020Recommends
Things are innovating faster than ever, but, the trick is always to address the challenges of both today and tomorrow, while staying true to compatibility and stability. Check out Brian's talk on Stewardship: ▶ this video
in “JDK 15” · View on HN
carimuraSep 2020Recommends
And by telling I think you mean that over time Java has very thoughtfully evolved in a way that respects backwards compatibility, or that once a feature is in the language it'll very likely stay there for the next 25 years. Yes, innovation is very important (and happening faster than ever now with the 6-month release cadence), but a majority of the work isn't in deciding what goes in, it's deciding what stays out and if something does go in how does it satisfy both audiences of "move slow don't break" and "move faster we want features". A good video on this process: ▶ this video
in “JDK 15” · View on HN
wgingMay 2018Recommends
As far as speed-of-evolution, it is worth understanding that the slower speed is at least partly a by-product of different goals. This talk, "Stewardship: The Sobering Parts" by Brian Goetz, is informative and well worth the watch: ▶ this video
in “Java 10 and beyond – a look at the potential language change” · View on HN
dlooseMar 2016Recommends
See Brian Goetz's talk on language stewardship ( ▶ this video ). I'm sure nobody wants to add new and interesting features to Java more than the people who work on the language every damn day, but they've made a strong commitment to the community to not break existing code.
in “JEP 286: Local-Variable Type Inference” · View on HN
serve_yayDec 2014Recommends
It is only tangentially related, but I recommend this video from Brian Geotz, a Java language architect. He breaks down the challenges of adding features to the language, in a room full of Clojure devs no less. Worth a watch: ▶ this video
in “Java Doesn’t Suck” · View on HN
kevindammJul 2025Cites it
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]
in “My first verified imperative program” · View on HN
dstineApr 2025Cites it
In this 2014 talk, Brian shows a slide in which he characterizes a visible fraction of his job as “regretting serialization” (somewhat tongue-in-cheek). ▶ this video Link is to the start of a sequence of three slides, the third of which is the slide in question. For a more recent update on serialization, watch this talk “Serialization: A New Hope”: [link]
in “JEP draft: Prepare to make final mean final” · View on HN
wgingOct 2020Cites it
Rich Hickey is supposed to have said that he created Clojure because he was tired of telling people to read that book. Best I can find as a source for now is ▶ this video -- I thought there was a link somewhere to Hickey himself saying this, but can't find it.
in “Java Concurrency – Understanding the Basics of Threads” · View on HN
throwdbaawayJun 2020Cites it
For python 2/3, it was because the BDFL made a wrong call. But we are past that now, and we collectively learnt something from the debacle, including the BDFL himself: > As for "Machiavellian Python maintainers", that's real. There have been explicit attempts to apply pain to Python 2.7 users. This has decreased since von Rossum got stuck maintaining Python 2.7 code at Dropbox as his day job. ( [link] ) For java 8/9, it was because Brian Goetz still has a boss. We can just compare ▶ this video to [link] . Hopefully some lessons were learnt as well.
in “Old Code Gets Younger Every Year” · View on HN
_CodemonkeyismOct 2018Cites it
Brian Goetz has been a role model on how to lead [0] a language for a long time now for me. Thanks for all the great work Brian. [0] "Brian Goetz - Stewardship: the Sobering Parts", ▶ this video
in “Entering the next phase of Project Valhalla” · View on HN
pjmlpDec 2014Cites it
> No tail calls support Due to the way JVM does bytecode verification. It will be fixed in future versions ▶ this video > no (optional and confined) unsafe pointer arithmetics www.docjar.com/docs/api/sun/misc/Unsafe.htm Will be replaced by an official API in Java 9. > no value types [link] > pathetic limit on a method size makes it an extremely shitty target for any language other than Java. Java Virtual Machine
in “Java Doesn’t Suck” · View on HN