Personally, I use LLMs to write code that I would have never bothered writing in the first place. For example, I hate web front-end development. I'm not a web dev, but sometimes it's cool to show visual demos or websites. Without LLMs, I wouldn't have bothered creating those, because I wouldn't have had the time anyway, so in that case, it's a net positive.
I don't use LLMs for my main pieces of work exactly due to the issues described by the author of the blogpost.
It’s used incorrectly. Hallucination has (or used to have) a very specific meaning in machine learning. All hallucinations are errors but not all errors are hallucinations.
Rust is great, but one thing I’d like to see is an interpreted, dynamic, less strict version of it that could be used for prototyping and gradually typed into compiling Rust code. In other words, a new programming language doing to Rust the reverse of what Mojo is trying to do to Python.
I believe the main Mojo use cases are scenarios in which you'd need dependencies anyway. Code that you can't write in Python due to performance concerns, so you'd need to call C/C++/Rust/CUDA/Triton/etc anyway.
I'm sure Chapel has its merits, but one of the main selling points of Mojo is the aspiration to be part of the Python ecosystem, and so far I haven't seen any other programming language offering a similar promise, other than Python itself coupled with DSLs or other extensions for high performance.
Not an expert in East Asian languages, but GPT tokenizers are generally byte-based. Meaning that the basic unit to do the merges is a single byte, not a character.
I’d add that while languages should die, code written in it shouldn’t. So, even if a language is deprecated, we still should be able to run, call and interoperate with all the legacy code that was written in it.
I don't use LLMs for my main pieces of work exactly due to the issues described by the author of the blogpost.