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: [email protected]

  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 have lots of front end infra/engineering effectiveness experience from my almost-5-year tenure working on LinkedIn.com, where I was the tech lead until a year ago. I built the Ember TypeScript team, got LinkedIn’s TS effort funded 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 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.