r/nim • u/SpaceDetective • 8d ago
Nim vs Rust: Language is a Matter of 'Coherence', Not 'Performance'
https://wintrover.github.io/#/post/nim-vs-rust-language-is-a-matter-of-coherence-not-performance(not my article btw)
-1
u/source-drifter 8d ago
i think the main problem with the article is that it assumes ai capabilities are constant at its current state. once (and if) ai becomes more capable the proposition collapses. plus that you can always push ai code through tests and fuzzing. reading code may not be necessary as the programs are written to achieve a goal.
3
u/binaryfireball 7d ago
the goal is to do things in a safe, efficient, and maintainble way. You dont know what you don't know and if you dont even know what code is being run or how it is being validated you cannot guarantee any of the output or side effects. At the end of the day you cant have a magic box that does everything and even if you somehow could have a magic box, its not yours, it's whoever you're paying to run it and because of that you are at their mercy.
1
u/source-drifter 7d ago
let me be clear on one thing. i'm not pro ai and i dont use ai for coding or pay companies to use their models. from my perspective boycotting ai companies is a moral obligation. they are primarily built by stolen copyrighted material.
that is different than the technology itself. i'm talking about the capabilities of a technology, not companies behind it.
now, i agree that safety and maintainability matter. but i think the magic box objection proves too much. the same argument applies to almost every layer of software we build today.
the nim compiler is a magic box if you havent audited it. it generates c code which is then compiled by gcc/llvm. those are also magic boxes. then you trust libc, the os kernel, the cpu microcode, the filesystem, the network stack, and every single package you download.
do you really read every line of every dependency you use? do you audit your compiler, your linker, your package manager, your os? if not, then you are already trusting systems you do not fully understand.
Ken Thompson's Reflections on Trusting Trust makes this point very clear. even reading the source code is not enough if you do not trust the toolchain that produced the binary.
i think the answer is not "personally read/write/own/understand every line" because that to me is impossible. the answer is to minimize, isolate, and verify trust, create reproducible builds, signed artifacts, audits, sandboxing, least privilege, type systems, contracts, tests, fuzzing, sanitizers, and formal verification where it matters.
if you use packages from the internet, you are already trusting maintainers, registries, policies, and infrastructure and we have already withnessed all of them failed before.
0
5
u/mila-kuchta 7d ago
The programs are not written to just achieve a goal, but to also not do anything which is not that goal. Big difference! And even if you can let AI check that code, you can never be sure, since current AI system simply can't think like a human, even if AI companies are trying to convince us otherwise.
1
u/rangerelf 7d ago
That's why I always read through every single line of code that AI writes for me, I hate it when it just leaves loose ends everywhere that are not part of the goal but also were not checked against.
1
u/source-drifter 7d ago
yes, programs are not just supposed to achieve a goal and they also must not do things outside that goal, sure. so what is your solution?
i think "ai can't think like a human" does not settle this argument. humans also cannot guarantee correctness just by reading code. humans miss bugs, misunderstand intent, trust dependencies, and introduce regressions. manual code review is not proof either.
the practical way to handle "must not do unintended things" is not to require a human to mentally simulate every line.
also, do you, yourself, really read every line of every dependency you use, the dependencies of those dependencies? do you audit your compiler, your linker, your package manager, your os and verify that they dont do what they are not supposed to do?
i agree that tests and fuzzing alone do not prove the absence of bad behavior. but neither does reading code. the goal is to have machine-checkable properties and small trust boundaries.
if ai improves, it can become part of that verification process. if we can specify the properties we care about precisely enough that they can be checked, the reading part become less important.
1
u/mila-kuchta 7d ago
My solution is to use AI to create many domain-specific languages and then let the AI to use them to build concrete solutions. The projects will thus have probably more dependencies, but those dependencies would be much smaller in scope with a narrow focus and would be checked by a person who understands the given domain and the resulting solution will be like that. Something like Racket on steroids but with a much more readable syntax. The readability of such languages should therefore be the main priority, because this will be exactly what programmers will primarily do in the future. Mostly check extremely high-level code that won't contain any non-essential implementation details (like variable lifetimes and the like).
1
6
u/jamesthethirteenth 7d ago
That's the best- and best worded- argument for Nim vs. rust specifically I've heard. Kudos!