JetBrains sent me a little request to post an interview with Jon Gjengset. I've always found his opinion interesting, and from the little I saw, it didn't look like a pure advertising video, so I have no problem posting that. Hopefully it's the right place to do it.
Here's the link to the video (which I haven't watched entirely yet).
YouTube gave me a recommendation for a jonhoo short that was a short that was advertising this video where it couldn't provide a real link to the video. Incredible.
At two hours, the full watch is still one of the shortest Jon Gjengset videos I've seen.
Ha! I meant their dumb Tiktok like feature, but that works too.
The video above is actually a little under 1h20, so a very short one according to his standard, indeed. 
I found it interesting, though the questions about AI were a little too insistent—FWIW, I thought his stance about the subject was very wise. I suppose that topic is unavoidable these days, and at worst, it'll provide some food for thoughts to those who still think it's a reliable way to write code.
Ah yes, for those who're wondering: the interviewer is Vitaly Bragilevsky, currently developer advocate at JetBrains. He also wrote Haskell In Depth.
Interesting video with a lot of good topics and I watched it till the end. I must say I don't like the way he speaks about other languages. He might sound a bit patronizing and authoritative to other communities here.
His take on Go for example. Why compare a potato (Go) with a celeriac (Rust) as if they can be the same in terms of development speed, time to market, portability, technical debt interest rates, ease of deployment etc. things that also matter outside the scope of software engineering cleverness?
He didn't mince his words about Go, indeed.
Why couldn't those two languages be compared in those terms? I think his point is exactly that the cost of development plus technical debt should favour Rust (for teams that are already proficient), and the fun factor too, though that last one is rather subjective.
He was asked his opinion, and he gave it.
He was also being more honest than most when asked about the SO survey, by giving a rational answer instead of the easy response that Rust was simply more attractive (I've always found that survey misleading). So it's not as he wasn't trying to be objective.
Proficient teams in Rust usually turn out to be significantly more expensive than "normal" teams in Go. So if time to market is closely coupled with proficiency, that'll translate roughly to the same if not more expense either in terms of time, or money.
That's most likely true (I don't know Go, only saw roughly what it's like).
But that's a one-time cost, while the development is a recurring cost. Besides, it's normally not a cost that the company has to pay, or not entirely; they just have to find enough senior developers.
I agree that some things are hard to compare, like the need to bind to other languages' binary code, because they depend on the situation and each company's assets. But I think he made that pretty clear.
$400K for a senior rust dev working in the U.S.? Well, I clearly work for the wrong company. LOL. (Not really. I enjoy my job very much but, wow, $400K?) To my peers earning wages like that, more power too you my friend. I raise my glass to you.
I think if you asked me that question I'd be struggling to find a way to express my position politely 
I'd probably end up with "I know a lot of good software has been written in it" which is absurdly backhanded a compliment. Hopefully it's at least manage to get out "I've only written a few thousand lines a long time ago, I can't really have a strong opinion"
I think in general the interview was looking for controversial answers, so overall Jon did pretty well at not sounding like either a politician or a lunatic.
Yes, I had the same reaction. I have a more demanding and skilled job than that, and it's typically a tenth of that salary (in Europe). I think it's very exaggerated; perhaps something you earn when you get at a top, techno/managerial position in a big company. The average seems at most a fourth of that number, according to recent surveys.
You do know that you have simply turn any https://www.youtube.com/shorts/abcdefxyz link into https://www.youtube.com/watch?v=abcdefxyz to get normal interface, right?
Happy to go into follow up questions if anyone has them by that way! We covered a lot of things in (to me 
) not very much time, so obviously some nuance is lost along the way.
At 14:50 you answer a question about how you'd pitch Rust to a Go team, which leads into a short discussion about how the type system helps with business logic bugs.
As a counter to that, there are a few tech influencers who insist that Rust can help with memory safety, but it can't help with business logic bugs. The charitable interpretation of that is that they mean that it can't help with business logic errors to the same degree it can help with memory safety bugs. But because I've never heard any of them qualify it, I'm going to be uncharitable here and assume they mean it quite literally.
What's your elevator pitch for "Rust can help you reduce business logic bugs as well", in particular to someone who doesn't believe it can?
I think Sguaba is a good counter-example here. That crate is essentially all types; there's very little actual calculation in there. If you ported it to Go or Python, the library arguably doesn't make much sense over a linear algebra library any more. And yet, in Rust, it can buy you a significant amount of confidence in the correctness of your business logic when it comes to coordinate transforms, and thus eliminate an entire class of (business logic) bugs. Chrono is another example of something that can statically eliminate many time bugs. Or Rayon that can give you concurrency with static checking of thread safety.
I think there's maybe a definitional question of what "business logic" means, though I think you quickly get into No True Scotsman territory.
I think the distinction is that Rust acrively prevents memory safety issues unless you do it on purpose. On the other hand, as far as business logic is concerned, it incentivizes and provides tools that help you avoid bugs, but its still up to you to know how to use them. So in those terms, it prevents memory safety issues but not business logic ones.
I disagree. Rust allows you to encode invariants in its rich type system, which you can utilize to also prevent errors in business logic. Of course you need to know the language for that.
If you don't know the language, Rust doesn't even provide memory safety, e.g. when the figurative newbie coming from C wraps everything inside unsafe { ... } and only uses raw pointers, because these lifetimes are weird.