3 ms·

The biggest productivity gain I've seen in my programming life has not been from Claude or ChatGPT. It's from the Rust compiler. A good compiler that catches er

by mlsu 2y ago

The biggest productivity gain I've seen in my programming life has not been from Claude or ChatGPT. It's from the Rust compiler. A good compiler that catches errors at compile time instead of runtime, that makes writing tests and pulling down dependencies easy, that makes documentation easy. Good old fashioned tooling. "Let's train an LLM that can decode C++ compiler error strings!" No, let's make better tools.

noch 2y ago
> "Let's train an LLM that can decode C++ compiler error strings!" > No, let's make better tools. LLMs exist and they pass the Turing Test, which was something we couldn't have said or even hoped for a few years ago. Additionally, they have an IQ of 90 - 120, depending on which one you are working with. But LLMs aren't good at all things nor in all ways, and they have strange failure modes. And so what will happen now, and is already happening, is that we'll (re)design programming tools and languages such that they are the kind of thing that LLMs are suited to using well. This will be part of the process of figuring out how LLMs work. There will be a virtuous cycle, and it has begun. Better tools will increasingly mean, "tools that LLMs are good at using." That's where the puck will be.
noch 2y ago
> A good compiler that catches errors at compile time instead of runtime, that makes writing tests and pulling down dependencies easy, that makes documentation easy. For a week I was fumbling through a ream of type and API errors from a Rust codebase I was hired to work on, migrate to new libraries, debug and update dependencies, etc. I found myself thinking: The Rust compiler is giving me these very long logs of well described errors that are nonetheless obscure to me. If the compiler knows the errors, why doesn't it simply fix them and report the fixes for me to test? This is what LLMs are for, and will soon do well by default: The compiler knows the errors. It should then fix them and let me decide which diffs I want to keep.

by mlsu 2y ago

noch 2y ago

> "Let's train an LLM that can decode C++ compiler error strings!" > No, let's make better tools. LLMs exist and they pass the Turing Test, which was something we couldn't have said or even hoped for a few years ago. Additionally, they have an IQ of 90 - 120, depending on which one you are working with. But LLMs aren't good at all things nor in all ways, and they have strange failure modes. And so what will happen now, and is already happening, is that we'll (re)design programming tools and languages such that they are the kind of thing that LLMs are suited to using well. This will be part of the process of figuring out how LLMs work. There will be a virtuous cycle, and it has begun. Better tools will increasingly mean, "tools that LLMs are good at using." That's where the puck will be.

noch 2y ago

> A good compiler that catches errors at compile time instead of runtime, that makes writing tests and pulling down dependencies easy, that makes documentation easy. For a week I was fumbling through a ream of type and API errors from a Rust codebase I was hired to work on, migrate to new libraries, debug and update dependencies, etc. I found myself thinking: The Rust compiler is giving me these very long logs of well described errors that are nonetheless obscure to me. If the compiler knows the errors, why doesn't it simply fix them and report the fixes for me to test? This is what LLMs are for, and will soon do well by default: The compiler knows the errors. It should then fix them and let me decide which diffs I want to keep.