why humans should not code in c: we're finding memory-safety vulnerabilities in c projects that are prevented by default in many other languages.
in the past, finding a simple buffer overflow wasn't enough. you'd need a highly skilled hacker to turn the vulnerability into a working end-to-end exploit.
today, that's a single prompt.
View quoted note →
Login to reply
Replies (13)
libsecp256k1 is a counterexample on C; it's a combination of the right people and the right task, but it's possible, it's just a very narrow field so I'm only like 10% disagreeing there.
On Lightning, yes, there is some kind of generic 'higher complexity' here; e.g. it's obvious you're going to have more attack surface in a coinswap codebase than in a coinjoin codebase.
Where do these projects fit into the picture? Important underlying infrastructure or niche one man projects?


OK. Hear me out.
Go Amish. No tech. No Internet.
The end.
I kan’t believe this happening to our language, but least we have a bakup letter
Time to take memory safety seriously.
thank you, bitcoin red team 🟥
View quoted note →
View quoted note →rrrrruuuuusssssttttttt
idk what is meant by "robust" simple, definitely. it's only a shade more complex than fortran and lisp. Rust is very robust. Zig is another language that lands pretty close to C for simplicity.
I'm in the late stages of developing a fork of Go that eliminates the GC, creates implicit memory ownership semantics that already are visible in the source code {}. it uses arenas instead of a heap and eliminates all shared memory, threads are exclusive owners of their own memory and have a ring buffer that allows them to share data between each other for concurrency. it will be very robust because you can't have any confusion about who owns memory or any handle, and you will be able to transplant code from a memory-based concurrency to a network based concurrency with only changes in the linkage between the elements of the system. and to that end, also, it is the standard pattern that the compiler derives a serialization codec for every type you create, so deep copy and network wire and database/disk encoding are all already done. other than that, it also uses most of the Go syntax, just the semantics change, and it eliminates all of the sync tree of packages and eliminates the distinction of array vs slice because unlike Go, it doesn't have a heap, and arena and stack memory layouts have no performance penalty, where heaps require management (to figure out if anyone still owns it, like a mortician running around checking if everyone still has a pulse).
yeah. it's pretty radical, but it means a language that can be used to build a kernel in a form that resembles the easy to read layout of Go with the same memory safety as Rust and a similar simplicity as C without the ugly problem of what to do about memory ownership when you run parallel threads.
can humans produce optimal code?
What is optimal?
http://poy7mv4bgjnjgxq73hck72x5lnspvev4pnsiea2gdyegt7xpeg3q.b32.i2p/articles/c-language.html
More evidence for us on this eepsite
No. But we can do our best with Excellency.
