I've vibe-coded TypeScript and Rust with great success.
I've vibe-coded Haskell to great disappointment.
I just can't accept how verbose and ugly it gets.
Which, for some reason, I'm totally okay with when coding Rust and TypeScript.
I mean, I obviously aim for simplicity and will refactor and simplify things.
But I don't hugely care about a few extra lines or indentation levels.
I just care that it breaks formatters all the time; I have a pre-commit hook that runs the formatter at this point, so I only need to repeat the commit command once after adding the formatting diff. Feels like I should make it run the formatter every time it completes something, but I'm not sure how to make it consistently do that (I must remember to initialize every time by saying "Here's your CONTEXT.md!")
The author is overlooking the need for enterprise server software that needs to be safe, stable, extendable to large systems and easily maintainable above anything else.
None of his three languages fits that bill. Python is not (type) safe enough. Typescript is meant for running in browser. And Rust, although it has a good type system, is meant primarily for system software. Compared to garbage collected languages such as Java, it loses on maintainability and extendibility because you don't want to be bothered with stuff like data ownership or ints with specific bit lengths in large systems that need to deal only with business logic.
Rust is not only about ownership or ints with specific bit lengths. It is about powerful type system which is quite important in business logic (if you have enough knowledge to use it properly).
I suspect it's too early to make predictions about which languages are going to become dominant moving forward, but in my experience robust type systems do seem to improve the accuracy of responses that I get from the various LLMs. I've been writing JS/TS for over a little over a decade now and am regularly impressed with what the best of the current crop of models can turn out. I'm not just seeing decent TS code but also decent explanations as to why the model went one direction vs. another. I'm sure that's at least partially thanks to the sheer quantity of JS/TS code that's out there.
I contrast that with the responses I get back from the LLMs for Elixir. I'm currently learning Elixir/Phoenix/Ash for a personal project. Absolutely loving that environment, but I'm seeing a much lower level of accuracy from the models. Basic questions about Elixir syntax and best practices are usually fine, but with anything more complex the responses are often more of a hinderance.
Phoenix, Ash, and Elixir itself are so well documented that the inaccurate LLM responses aren't slowing me down overall, but I'm very curious about whether the underlying issue has more to do with Elixir itself or just the amount of sample code that's in the wild.
Python and Typescript/JavaScript I largely agree. Those languages frequently top the list of most used languages with probably the most code represented in the popular foundation models. Even though Python has shifted over time the sheer number of examples models have access to makes it more robust than most other languages.
I am less convinced Rust belongs in the list. Rust is far behind the number of examples the large models have access to, the syntax is fairly ham handed, and I don't feel the library story is as strong as with python (though probably on equal footing with JavaScript). My two cents on Rust and LLM compatibility.
If I had to add a third I would pick Go. Guaranteed backwards compatibility, robust and frequently used standard library, rigidly enforced format, and a wonderful type system. Though I actually don't know that for training purposes having perfectly formatted code is actually a good thing. Ironically a more pythonic coding where you can kind of do whatever stretches the models understanding better making it more robust, from what I understand.
> And TypeScript of course runs natively on browsers
As a backend engineer I was thinking, "Whoah, the frontend is moving so fast that browsers support Typescript natively!" But it turns out the author is either uninformed, or, more likely, just being sloppy.
Pity that TypeScript team decided to rewrite its implementation in Go, and there are no plans in sight to rewrite V8, thus C++ addons keeps being the easiest way to extend it.
I have no plans to adopt Python beyond OS scripting tasks, even in the context of AI, other ecosystems are starting to have bindings to the same C++ libraries.
As for Rust, I don't have a use case at work where it is a win over managed compiled languages, maybe if Vercel finally offers first class support for it, instead of the community runtime or via WebAssembly.
So maybe it is a new trifecta for some users, not all of us.
EDIT: Additionally, I think AI will make current languages largely irrelevant, as they increasingly get better at code generation.
12 comments
[ 3.6 ms ] story [ 42.5 ms ] threadI've vibe-coded Haskell to great disappointment.
I just can't accept how verbose and ugly it gets.
Which, for some reason, I'm totally okay with when coding Rust and TypeScript.
I mean, I obviously aim for simplicity and will refactor and simplify things.
But I don't hugely care about a few extra lines or indentation levels.
I just care that it breaks formatters all the time; I have a pre-commit hook that runs the formatter at this point, so I only need to repeat the commit command once after adding the formatting diff. Feels like I should make it run the formatter every time it completes something, but I'm not sure how to make it consistently do that (I must remember to initialize every time by saying "Here's your CONTEXT.md!")
None of his three languages fits that bill. Python is not (type) safe enough. Typescript is meant for running in browser. And Rust, although it has a good type system, is meant primarily for system software. Compared to garbage collected languages such as Java, it loses on maintainability and extendibility because you don't want to be bothered with stuff like data ownership or ints with specific bit lengths in large systems that need to deal only with business logic.
Your LLM is perfectly capable of using https://docs.rs/num/latest/num/struct.BigInt.html or such as needed. Yeah it's not part of the language but many many things in Rust aren't (intentionally).
I contrast that with the responses I get back from the LLMs for Elixir. I'm currently learning Elixir/Phoenix/Ash for a personal project. Absolutely loving that environment, but I'm seeing a much lower level of accuracy from the models. Basic questions about Elixir syntax and best practices are usually fine, but with anything more complex the responses are often more of a hinderance.
Phoenix, Ash, and Elixir itself are so well documented that the inaccurate LLM responses aren't slowing me down overall, but I'm very curious about whether the underlying issue has more to do with Elixir itself or just the amount of sample code that's in the wild.
I am less convinced Rust belongs in the list. Rust is far behind the number of examples the large models have access to, the syntax is fairly ham handed, and I don't feel the library story is as strong as with python (though probably on equal footing with JavaScript). My two cents on Rust and LLM compatibility.
If I had to add a third I would pick Go. Guaranteed backwards compatibility, robust and frequently used standard library, rigidly enforced format, and a wonderful type system. Though I actually don't know that for training purposes having perfectly formatted code is actually a good thing. Ironically a more pythonic coding where you can kind of do whatever stretches the models understanding better making it more robust, from what I understand.
Cough loop iterator semantics changes uncough
As a backend engineer I was thinking, "Whoah, the frontend is moving so fast that browsers support Typescript natively!" But it turns out the author is either uninformed, or, more likely, just being sloppy.
I have no plans to adopt Python beyond OS scripting tasks, even in the context of AI, other ecosystems are starting to have bindings to the same C++ libraries.
As for Rust, I don't have a use case at work where it is a win over managed compiled languages, maybe if Vercel finally offers first class support for it, instead of the community runtime or via WebAssembly.
So maybe it is a new trifecta for some users, not all of us.
EDIT: Additionally, I think AI will make current languages largely irrelevant, as they increasingly get better at code generation.