Rendered at 08:54:58 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
amai 15 hours ago [-]
"Not necessarily Rust — Go, Zig, and anything else with a real type system and compile-time checks gets the same tailwind. Rust just happens to have the strictest compiler and the most to gain when “strict” stops being a cost. "
You either have a strict compiler for your language or you have to write more tests for your code.
While rust protects against passing and assigning the wrong types and leaving dangling pointers, it does not protect against writing inefficient garbage.
niobe 1 days ago [-]
What you say is interesting. I never did care much for Dylan now that you mention it.
justonepost2 1 days ago [-]
python, and humans
if you’re practically irrelevant (unusable or unemployable) youre existentially irrelevant (dead)
this is the fate of man and we must discern the trajectory of that which is beyond us before we bow out
dvhh 1 days ago [-]
confirming that Rust popularity is in great part due to the advent of LLM for generating code.
deafpolygon 1 days ago [-]
FYI, a good chunk of the article was LLM-ified.
weare138 1 days ago [-]
Last month I wrote a dynamic malware analysis tool in Rust. About 20,000 lines of it. Process management, threading, memory management, the whole stack. I don’t know Rust
And I won't be using that...
wiseowise 20 hours ago [-]
Absolute garbage of an article with lots of dumb takes that are plain out wrong.
instig007 14 hours ago [-]
> Token density
If you really cared about that, you wouldn't have picked Rust. Nim or Haskell are terser languages.
> Every language we’ve built defaults to sequential execution with parallelism bolted on.
False and misleading statement. Array languages have been around for a long time, but you didn't care to learn them.
> Formal verifiability. Move beyond type checking to compile-time proofs.
Good luck with your tokens budget for proof providing. LLMs won't solve that for you. If you believe that proofs are as simple as matching API calling inerfaces you're wrong.
> Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced.
Good functions are pure functions that have no effects. Good design tries to minimize the number of effects needed and maximize the footprint of pure functions mapped over inputs and outputs. If you insist that every function needs an explicit effect annotation, you don't know the topic and you haven't worked with effect systems much.
altmanaltman 1 days ago [-]
> With Rust, the actual compiler did the babysitting. The agent could be sloppy and the language wouldn’t let the sloppiness ship.
If you really don't know Rust or its best design patterns (which the authors says they dont), your agent can absolutely write garbage code that still fails. Rust doesnt make writing bad code impossible or is some magical solution to computer languages. What a nonsense article
You either have a strict compiler for your language or you have to write more tests for your code.
if you’re practically irrelevant (unusable or unemployable) youre existentially irrelevant (dead)
this is the fate of man and we must discern the trajectory of that which is beyond us before we bow out
And I won't be using that...
If you really cared about that, you wouldn't have picked Rust. Nim or Haskell are terser languages.
> Every language we’ve built defaults to sequential execution with parallelism bolted on.
False and misleading statement. Array languages have been around for a long time, but you didn't care to learn them.
> Formal verifiability. Move beyond type checking to compile-time proofs.
Good luck with your tokens budget for proof providing. LLMs won't solve that for you. If you believe that proofs are as simple as matching API calling inerfaces you're wrong.
> Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced.
Good functions are pure functions that have no effects. Good design tries to minimize the number of effects needed and maximize the footprint of pure functions mapped over inputs and outputs. If you insist that every function needs an explicit effect annotation, you don't know the topic and you haven't worked with effect systems much.
If you really don't know Rust or its best design patterns (which the authors says they dont), your agent can absolutely write garbage code that still fails. Rust doesnt make writing bad code impossible or is some magical solution to computer languages. What a nonsense article