61–70 of 242 posts
Off topic, but it's surprisingly refreshing to see someone put "Christian" next to their name in the same place they put "Mozilla hacker." The vast majority of programmers either aren't religious or hide it so well that you couldn't possibly tell if they were. (Not that being overt about it is better, either.) I understand that it's generally best not to talk religion in the professional workplace, but a person's own…
I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
1: So a new generation, new rewrite of everything... Then hitting brand new problems (sometimes old ones avoided by previous designs) not foreseen by majority. A new language spawns with the coming of a new generation, addressing some of these problems. Rewrites everything. Hits another set of problems. Goto 1.
Anyone downvoting a question care to comment what's so wrong with this?
Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…
There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids.
I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are all the same borrow rules, and I know I have a bunch of TODOs in the code to go fix things like extra clones. The IDEs, while good, are not on par with other languages yet.
Basically it's a lot of work. And I commend the individuals who've paved the way for me with the std library in Rust, but we still have so much more work to do until there is a full OS env like GNU.
Earlier quoted context omitted.
This is why I personally think the OSS community should be more encouraging of "salary" style funding. There is a loud, poisonous minority of advocates that seem to think that asking for money is just plain evil. That attitude is a material disservice to OSS in general: it makes OSS weaker and less capable, for the sake of some weird puritan reflex. N.B.: I have never and will never ask for, nor accept any income fro…
Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?
I.e., if you start paying; you have to continue paying.
Predictably Irrational http://whistlinginthewind.org/2013/01/15/predictably-irratio...
Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. We live in a C world and I don't see that…
Of course it won't because every time an out-of-bounds array access gives attackers free reign of a system and some one says "hey guys this whole C thing is clearly blatantly terrible" every one else says "Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production."
As if the libraries have been utterly static for decades and aren't infact full of holes and bugs, which is exactly what brings on the call to rewrite things in Ada/Rust/SML/Lisp
Then they always say "There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe." As if there's no reason trying to improve things unless you can jump directly to perfect.
they make excuses like "A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today." as if we still lived in those innocent times.
And then they inevitably wave the call to action off by appealing to the status quo with some line like "We live in a C world and I don't see that changing any time soon." and so even though there's no reason we couldn't start re-writing things (especially in Unix an OS that constantly brags about being built from loosely coupled parts) in a better language we never get a critical mass together.
See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/
For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.
C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.
Earlier quoted context omitted.
This is why I personally think the OSS community should be more encouraging of "salary" style funding. There is a loud, poisonous minority of advocates that seem to think that asking for money is just plain evil. That attitude is a material disservice to OSS in general: it makes OSS weaker and less capable, for the sake of some weird puritan reflex. N.B.: I have never and will never ask for, nor accept any income fro…
Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?
But Google does run a security-engineering focussed bounty program: https://www.google.com/about/appsecurity/patch-rewards/
So if you're looking for some smaller scale rewards, that might help.
1: So a new generation, new rewrite of everything... Then hitting brand new problems (sometimes old ones avoided by previous designs) not foreseen by majority. A new language spawns with the coming of a new generation, addressing some of these problems. Rewrites everything. Hits another set of problems. Goto 1.
Iteration is not bad. Iteration without progress is bad. Which one do you think would happen?
So what I see is iteration with some progress and some regress (wrt to empowering programmers and simplicity). It's good to have a new generation enthusiastic creating their own world, yet if they are as human as previous generation, most likely they would hit the same problems. Like a genetic algorithm, a slight mutation to current solution runs for a certain time and we see how the generation fares. But maybe we need completely different approach to get out of local optima technology seems to be right now. Quantum Rust? ;-)