chriskrycho

Yeah, I’ve actually been thinking about adding a toggle, because some folks really like having the slides there, and some folks do not. A better layout for talks (side-by-side, e.g.) could help, too.

I debated including XKCD 2347 in the talk but figured it was “too easy”: everyone was already thinking of it anyway!

Edit: Went ahead and added an inline toggle on the page for showing/hiding the slides. I will think about how to generalize it/tweak it in the future, but that should help for this one, at least!

I think you read into the article some things that weren’t there. The question from the colleague was why I was even interested in learning something we all knew (me included!) we wouldn’t use there. At no point did I propose using Rust at that .NET shop! The whole point was that I was curious about and enthusiastically learning—on the side, on my own time!—a technology that was totally unrelated to my job. Pretty sure the closest that shop ever got to Rust was when I shared interesting bits about it in the company’s wide-open tech talk series, but that series also included folks sharing things like “this cool thing I did with a Raspberry Pi” and “look at what cool hacks you can do with Amazon Alexa” and so on. Long story short, you’re not even responding to what I actually wrote, but to something else that you (probably for good reasons in your own experience) get button-mashed by! (Me too, for what it’s worth!)

If you enable the watchman integration, then you actually get very close to this: your current change’s evolution log and the repo operation log will have every change which was persisted to disk. There are tradeoffs to that, of course, but it’s a very powerful capability—and notice that it’s something that would be a huge pain to cobble together somehow in GitHub which Just Works in Jujutsu. It falls cleanly out of making the working copy a commit.

It does not implement Git worktrees, but instead implements its own notion of workspaces which frankly I find much nicer (unsurprisingly!). As with most things jj: just as much or more power than Git, but less hassle.

Working with submodules natively (see steveklabnik’s sibling comment for the “non-native” bit) will definitely be a big win.

I actually find jj great for (1). The project I reference working on in this post is in exactly that bucket, and the kinds of things I do with it are not “complicated” but jj is still much, much better than working with Git—not least for the kind of workflow I showed in this post!

Thanks to the feedback in this discussion, the article now does discuss 5at line; much obliged to all the folks who helped me fix a substantial error.

Yeah, a thing I implemented years ago to handle the ability to hide the side nav on wide screens never worked quite the way I expected. Making it not do that except when specifically toggling the nav has always been on the “to-do”, just never made it to the top of my priority list.

I just published an update to the post which corrected the title, URL, and content, and also published an additional post calling attention to the error and explaining it (https://v5.chriskrycho.com/notes/corrections-using-drop-safe...). Thanks again for flagging it up, @dathinab!

Ah, you’re totally right; I badly misstated that. I’ll update it tomorrow accordingly. Thank you for the correction. Your last comment before the edit is one part of what I was trying to get at; the other was that Drop itself must uphold the relevant constraints in its own operation. Like I said, great clarification/ correction and I’ll be glad to fix it!

In some sense even the best talks are an attempt to distill things we have learned into a tight enough package that it helps people (a) think a little differently and (b) go read and learn more themselves. Sometimes that turns into self-promoting puffery, but I don’t claim to have anything particularly original to say in this talk. To the contrary: the whole point and structure of the talk is “This stuff is out there, let’s pull it together and get thinking about it!”—pointing to good work other people have done.

Now, maybe it lands that way and maybe it doesn’t, but I think that our industry could use lots of “discovering something mundane and wrapping it up as a TED talk” if it helps us to be more serious practitioners of the discipline. Most of what we need is mundane, after all! But that doesn’t mean it is unimportant, and it doesn’t mean everyone already knows it.

I suggest never beginning an introduction with "this is the best talk I've ever given".

Heh, this is fair, and I actually just edited the intro in response to that feedback. In my defense, the talk itself doesn’t start that way; that was how I introduced for the folks who read my blog via feed or email subscription. Might need to iterate on having ways to add “feed-only content” for that kind of thing, because I think it’s reasonable to say that in the context of folks who already follow your work, but you’re right that it’s weird at the start of a “regular” blog post for people coming to it fresh!

Sorry to hear the rest of it didn’t land for you. Can’t win them all!

Thanks! The books and essays are fantastic, and if I get a few people to read them, this will have been a successful talk!

Re: LinkedIn—Ha! I debated on how much to include/not-include specific references to my previous employer there, and erred on the side of “let’s keep this grounded in specific real-world experience at least a little”. I think you might get mildly tipsy, but not terribly drunk.

Thanks – looking forward to chatting!

SEEKING WORK - remote only, Colorado

- Short-form résumé: https://cdn.chriskrycho.com/resume.pdf

- Long-form CV: https://v5.chriskrycho.com/cv

- Services page: https://v5.chriskrycho.com/services

I help teams with front-end web strategy development, TypeScript adoption and conversion, and Rust adoption. I am just kicking off more consulting work after spending the summer working on a new chapter of _The Rust Programming Language_ (the official book) on async programming in Rust.

Up until this time last year, I was tech lead for the LinkedIn.com desktop app, where I spearheaded LinkedIn’s adoption of TS and was the tech expert for the effort—when other folks hit an area they couldn’t figure out how to write safe and accurate types for, they pinged me.

I am also happy to provide 1:1 coaching and mentoring. See my site for more, or email me: hello@chriskrycho.com

  Location: Monument (45min S of Denver), Colorado, United States
  Remote: Yes, only
  Willing to relocate: No
  Technologies:
    - TypeScript and JavaScript (including Node)
    - Rust
    - CSS, HTML

    Long ago, also Postgres.

I also have significant experience with Rust education: I ran the New Rustacean podcast 2015–2019, and this summer I wrote a new chapter on async/await for the official Rust book (currently in revision!).

Looking for roles with a particular kind of impact on the world (https://v5.chriskrycho.com/journal/next/role/), but fairly wide open about the details—though I particularly love and excel at framework and API design, and open source leadership and ecosystem development. I also have a passion for, but am relatively new at, PL work.

As a bonus, I am a very good teacher, mentor, and public speaker; you can find a number of talks by me on YouTube, including most recently at StaffPlus New York (https://www.youtube.com/watch?v=VkSGJdPyLxQ).

Author here, and I agree that Rust shouldn't represent the end of history for programming language evolution. Vehemently. I have been saying for the better part of a decade now that I hope very much Rust is the first of a new breed of memory-safe systems-level languages, and that I also believe that we can do better with learnings from Rust as a stepping stone. Safety is really important along some of the axes I called out in the piece (“can you hand this to an unsupervised junior, or for that matter me on a bad day?”) but it is not the only important axis, and indeed Rust’s success has been in part because of many other very important things it got more right than predecessors or competitors in the same space (Cargo!).

But I am immensely encouraged to see Swift and Hylo and Vale all taking swings at the same problem space with very different emphases and approaches, and while I differ with Zig on some fundamentals I can totally imagine a language that grabs many of its good ideas along many of those from Rust which Zig drops, and goes somewhere better than either has managed so far.

I don't, though, agree at all about natural language solving problems here—rather the opposite, in fact. I think that in many cases, things like memory safety (and other kinds of safety!) are going to be more important to solve at language and framework level in a world where there is massively more code generated by prompting LLMs.

This is, indeed the type of stuff most people run into if their career spans more than a couple years, touches large organizations, etc. That is why I thought it would be useful to share: it is the kind of thing that would’ve been really helpful for me in the first few years of my career to understand some of the dynamics, including what can go well, and what can go less well, and the kind of mistakes one might try to avoid, as well as what it means to stick with one’s convictions, even when that might be costly.

Whether it is “unprofessional“ or not is something I thought about quite a bit. I think I walked the line of being fairly politic and avoiding dragging real people’s names through the mud, while still getting into some of what that kind of real world engineering and associated politics is like. At the same time, I can see how someone would take the view that none of this kind of thing should be shared outside the company. Your mileage may vary. I hope at a minimum you can understand why someone might choose to air a little bit of it while trying not to be nasty about it.

Yeah, and I have it on good authority that there are JS/TS apps more than 10 times larger than that at Google. Scale is relative.

A bit of clarification from some of the nuance that (reasonably) had to get cut from the episode for time:

- Propose a 5-year-plan: yeah, “lol” is about right. It was never going to win any hearts or minds. It was also our least favorite plan. But it was also the only one we felt we could actually bring to our executive leadership given what they were telling us prior to that, which was basically “Even for a migration we are asking you for, do not slow down product iteration velocity at all.” How do you do that? Welllll…

- I’m not really sure what you’re referring to about leading the incident with blame instead of leadership. It’s possible something got lost in translation with the amount we cut, but I actually aimed very much to do the opposite. We didn’t blame the people who lowered the memory thresholds, the people who typo’d a bad value in YAML, or anyone else. I just insisted that we actually solve the root issues instead of leaving them to fester for the next poor person who happened to be around when it inevitably blew up again.

- “Speaking about problems more than solving problems”: really not sure what you mean here. I didn’t spend a ton of time bragging about what I had pulled off on the show because wow would that ever have been in poor taste, but… I did pretty well in the problems I solved there.

- Lack of relationship building: yeah, I called that out on the episode! It was my weakest area. I had a really good rapport with engineers, and failed pretty miserably at building cachet with management, especially with management above me.

I wouldn’t say in the end that it was just down to not knowing how to perform in the environment, though. Some of it was also a choice, in the end, not to perform in ways that I could see would be successful in the environment but which I simply did not believe in. I think a lot of the engineers I respect most are like this: can and will do the political dance for something they believe in… but not for things they don’t believe in.

They started a rewrite-from-scratch of all the apps, including mobile, using a custom in-house server-driven UI framework with a Kotlin DSL backing it, without so much as doing a proof of concept to find the tricky parts first. And by “started” I mean “committed to it” before anyone had so much as written a line of code to spike it out. Which, YMMV, but to me that seemed then, and still seems now, just wild.

This is a reasonable take, and I mostly share it. None of us were especially happy about that plan! However, and I alluded to this on the episode, it wasn’t actually a five year plan to get to a very specific endpoint. It was, instead a 3–5-year plan to make steady incremental changes to our entire system in ways that meant that if we realized our end destination needed to change (e.g. from React to Svelte or something not even built yet) 2 years along, that was totally fine.

For what it’s worth I don’t think what you’re describing here is the same thing I meant by “finger guns” at all! What you’re describing looks to me like good incremental development.

With my “fingers guns mode” phrase, I really had in mind a blithe disregard for any of the real-world engineering problems and constraints that we knew we would hit (because they just inhered in what we knew the solution needed to do). You don’t have to solve those right up front, but you do need to (a) acknowledge that they exist and (b) have some notion of what your approach to them will be.

I’m extremely in favor of taking a small team of veterans (who are open to doing something novel!) on a new system, as you say—let them leverage all their expertise, while being careful to avoid Second System Syndrome, to build something by using all of the knowledge about those pitfalls/problems/etc. to avoid them. (The risk there is that you can end up overfitting on previous experience! That’s real!)

LinkedIn actually chose Ember well before React had won, and definitely before it had become the new “no one gets fired for buying IBM.” That all preceded my time there, but the evaluation was late 2014 and the LinkedIn.com web app rebuild in Ember was kicked off in 2015 if I recall correctly. React only came out in 2013, and while it was definitely on a rocket ship it was way less obvious in late 2014 that it was going to be the de facto standard that it was by late 2016–early 2017.

Bonus note: One factor that was really not obvious at the point they were doing the evaluation was how much TypeScript and TypeScript-powered tooling was going to matter. TS shipped support for JSX/TSX in TS 1.6, in late 2015, and I contend that while JSX had a lot of pros and cons, the one absolutely unambiguous win it had over everything else from that point forward was that whether you were writing JS or TS, you got outstanding editor support in basically every editor in the world courtesy of the TS language server backing your JS or TS development. Just absolutely massive.

The fact that the TS team baked support for JSX into TS itself and that it's not pluggable is (a) totally understandable and reasonable from a maintenance effort POV, especially given that Microsoft uses React extensively, and (b) extremely frustrating for everyone not using JSX. Vue, Angular, Svelte, and Ember all had to build the exact same infrastructure to get that support, and that was a huge productivity hit for devs using those frameworks compared to React in the meantime.

This is a great summary. Obviously I bring my own perspective to this, because, well… it happened to me, and I “lost”. But my read was that the folks I disagreed with and ultimately parted ways with were falling into the bucket you label ‘there won’t be any obstacles what do you mean?’.

The tradeoff around “do we migrate to TS?” is a great example here, by the way. A huge part of our decision-making last year around the big app at LinkedIn was on exactly that question: If you are going to stop and throw the entire thing away, you should waste exactly zero time migrating any of it. On the other hand, if the thing is going to be migrated incrementally, you should accelerate the TS effort because it will make it so much easier to code-mod the code base.

(I don’t agree that it’s a “cartoon” podcast description, but it is definitely extremely compressed and Adam and I chose to focus on the personal dynamics over the technical details, because diving into the latter would have made for a 5-hour episode. Also: it’s really tricky to do any of this kind of public discussion in a way that doesn’t just end up reading as a one-sided self-defense!)

There's an element of truth to this! I alluded to this (and Adam totally reasonably cut even more of it for time) but I definitely was not as effective organizationally as I could have been; that is one of the major things I learned from my time at LinkedIn. The biggest challenge for DX teams remains figuring out how to (a) communicate but more importantly (b) align their work with the key priorities of the business. I got to be okay at (a) but never particularly succeeded at (b) in my time at LinkedIn. Some of that is on me! Some of it… is on LinkedIn.

That said, in this case, the person telling me “You’re too idealistic” literally meant it in the sense of “You should not care about anything unless it directly moves the bottom line,” and I reject that to my bones. The bottom line matters. So, though, do things like user experience, developer experience, and for that matter just basic ethics about what we build (though happily the latter wasn’t in view here).

Might have been a lack of clarity on my part. When you split, you are actually choosing "what goes first". The issue workflow-wise today is primarily a lack of tooling designed to represent this process visually in an easy way.

Ah, you’re right. I will try to clarify that in edits tomorrow or Monday. Thanks for flagging it up!

I initially thought the same but have come around. The problem at this point is the lack of tooling that understands and supports it. You could, quite reasonably, say they should have made a different choice based on what works best with tooling today, and that would be fair; but I think that would leave us in a bit of a local maximum. My hope is that if and as it catches on, tools will grow feature and modes to work with it—just like they did to work with Git’s index.

This is a fair criticism. I struggled with how to organize that section and I might go back and add an example of what I meant, or even pull that phrase out (it’s actually from a much earlier version of the piece when it was more experience report and less introduction to the tool). I also debated about showing various bits of log output for exactly this reason, but decided not to since there are multiple examples of it in the asciinema recordings. Also, “a bit too tired to keep reading” is indicative of the other reason: this is already a mammoth piece of writing to work through! There is room to deep dive on any of the pieces as their own standalone pieces, too, but at some point I just had to publish the dang thing.

The first couple weeks there was definitely some friction, especially because having the working copy be a commit itself takes some real getting used to. Once I got over that and learned that I did not need to name every branch and could just work away and name branches only for pushing to Git remotes, the switch flipped very hard the other way. Git feels awful now.