Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

251–260 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#251

Post by FRex »

akavel wrote: post #228
FRex wrote: post #151

Earlier quoted context omitted.

To help protect you from these unsafe programs in obsolete languages I compiled a small list of software in C or C++ that you need to delete ASAP to ensure your safety: 1. Windows OS. 2. Windows kernel (mobile too). 3. Linux kernel (android too). 4. Bash, zsh, csh, fish, etc. 5. C#, Java, Ruby, Python, etc. 6. Parts of Rust backend, namely LLVM :(. 7. Apache, nginx, etc. 8. Filesystems. 9. Most drivers. 10. Router so…

[ edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely…

I am not saying C++ and all the stuff listed is always safe, just that it's good enough for daily use, including professional use where lives are on the line. As I said before, you used extreme words and made C++ sound like Java applets - something no one ever should use nowdays outside of truly exceptional circumstances (a.k.a. not something as widely used as OSes, browser and the HotSpot JVM).

I'm sure you have seen BS codebases in Java, C#, PHP, Python, etc. as well, I've seen weird interactions with GC in WildFly (I can't comment more because I'm not a Java programmer), spooky action at a distance, globals, using one huge table in a DB to store everything thus missing the point of a relational DB, etc. all in non C nor C++ and it'd not help these things if they were in Rust.

Not all bugs come from the language itself either, some are just true programmer errors. I just google for PHP SQL tutorial (not an English one) and the result is of course pasting input together with SQL to form a query, 0 escaping... Sony had a leak like that. Many Windows issues are pure ignorance like having SMB (that turned out to be buggy, but still) running by default, similarly stuff like misconfiguration, default passwords, Apple's goto fail won't be solved if people are copy pasting code and formatting it badly (unless Rust enforces that, I'm not sure, I don't know Rust yet). Rust will not prevent these kinds of mistakes (maybe the last one if the compiler itself detect inaccessible code and maaybe the SQL one if it marks the variable from user input unsafe at first and cascades that through the function calls to see if it was pasted and passed to SQL) unless it has extremely deep understanding of what's going on.

Additionally, despite all the bugs in Windows there (sadly) wasn't a huge exodus to Linux (which too has tons of bugs and is in C and has lots of programs in C++), it just works "well enough" despite the flaws, there no disaster hanging over our heads.

Re: Why you should, actually, rewrite some of it in Rust

#252

Post by _dcwr »

AnimalMuppet wrote: post #248
_dcwr wrote: post #244

Earlier quoted context omitted.

I'm an outsider and there is a war every damn time the word Rust comes up on HN. I've yet to see bashing any language to that degree in Erlang threads, Python threads, etc. Something has to be up with that. I'm not using C and C++ professionally at all so the only place Rust has to fit in is fun or potential long term professional opportunity (assuming Rust is a fair bit more widespread than now by then, otherwise C…

Up until about six months ago, I saw it a lot from Haskell proponents here on HN. But with them, it was pretty much against everybody (except maybe users of F#). Either the most obnoxious ones left, or they learned that this was not a productive approach. It's been refreshingly quiet lately... But I disagree that there's a war every time Rust comes up, as a general thing. Many of the Rust proponents here are quite re…

I've never seen Haskell people (I'm relatively fresh here, 2 weeks, as evident in my lack of fitting into echo chambers) and Haskell is entirely different beast so that's different, especially if they were okay with F#. Rust is pretty much claiming to be doing same stuff in same niche (efficient native code) as C and C++ except better, it's like reverse of Haskell vs. the world except F#, it's Rust vs. C and C++.

I wasted an hour and a half or even two here today as well, I at least got a reply from a Rust core team member who responded to me (yay), was nice enough and told me the community rules disallow wars, that's something I'd not get otherwise, but still, this feels very very unproductive in the end...

Re: Why you should, actually, rewrite some of it in Rust

#253

Post by jeffdavis »

anarazel wrote: post #229
jeffdavis wrote: post #220

Earlier quoted context omitted.

I've made some progress. Not quite as thin as I had hoped ;-) I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author.

> I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author. Why exactly is that? I'd have expected a C wrapper to take care of most of that? Are you concerned about the Datum native type C macros? Are you planning/hoping for this to be all safe, or is there going to be unsafety in the wrapper?

Creating a new module or UDF requires exporting new special symbols for V1 calling convention.

Rust's hygenic macros don't let you do that. So defining a UDF has a bunch of boilerplate, unless I am missing something.

Procedural macros should alleviate this, but it will be a while. I might just release and document the boilerplate needed.

EDIT: Yes, I am trying to be mostly safe. I will see how close I can get for at least the basic stuff.

Re: Why you should, actually, rewrite some of it in Rust

#254

Post by AnimalMuppet »

akavel wrote: post #228
FRex wrote: post #151

Earlier quoted context omitted.

To help protect you from these unsafe programs in obsolete languages I compiled a small list of software in C or C++ that you need to delete ASAP to ensure your safety: 1. Windows OS. 2. Windows kernel (mobile too). 3. Linux kernel (android too). 4. Bash, zsh, csh, fish, etc. 5. C#, Java, Ruby, Python, etc. 6. Parts of Rust backend, namely LLVM :(. 7. Apache, nginx, etc. 8. Filesystems. 9. Most drivers. 10. Router so…

[ edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely…

> It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue.

Most fundamentally, that's a corporate culture issue. That should not be regarded as normal in any sane environment. (And, yes, such environments do exist.)

> The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted.

But not thinking it's a problem when the app crashed multiple times a day? That sounds like architecture astronauts, not good programmers.

> I know there are tons of them [data races] sleeping undetected in any multithreaded C++ code.

No. I've worked on real-time multithreaded code that had no data races, thanks to judicious use of mutexes. (Now, I can't prove that, and you could argue that they're there, and I just don't know it.)

It's possible to do much better with C++ than what you experienced - to write solid stuff that doesn't crash every day, still less multiple times a day; to write multithreaded code that isn't riddle with race conditions; and so on. Mostly, what it takes is a team (or corporate) culture that insists on quality code, from start to finish - good design, good development, good testing and debugging.

Re: Why you should, actually, rewrite some of it in Rust

#255

Post by Rusky »

lossolo wrote: post #250
Rusky wrote: post #190

Earlier quoted context omitted.

Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority. And for now, there are definitely ways to handle signals using libraries.

> Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority. Do you have any source that can confirm that? Because what you wrote seems really wrong. I see linuxes/bsd/unix EVERYWHERE (Android/iOS/OSX/almost all backend servers etc.)

I'm thinking of embedded systems and desktop machines- the first tends not to use an OS nearly that big (if any at all), and the second tends to use Windows.

Re: Why you should, actually, rewrite some of it in Rust

#256

Post by dbaupp »

kazinator wrote: post #239
akavel wrote: post #235

Earlier quoted context omitted.

Ah, but I never called to delete any C/C++-based code! That's a strawman from you here. Also, especially I didn't say it's impossible to write anything substantial and/or useful in C++, oh, most certainly it is! But truly, I did and do claim it's humanly impossible to write anything safe in those. As to doing a programmer's job wrong, sorry if you got such impression. Wasn't my intention. C++ is powerful, and in many…

You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine. For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null ter…

Higher level constructs like iterators, references and smart pointers are all relatively easy to misuse. It is definitely possible to have safe abstractions like std::string's + and they're one reason why C++ is an improvement over C, but there's still many other dangerous edges that are nearly impossible for a human to keep track of at scale.

Re: Why you should, actually, rewrite some of it in Rust

#257

Post by curun1r »

FRex wrote: post #170
vvanders wrote: post #143

Earlier quoted context omitted.

I think you see some of that since quite a few people have spent decades in C/C++(myself included) and have had exposure to experiencing these exact problems. I'm still a huge fan of C++ but Rust gets me to where I want to go with C++ with much less fuss and a lot more confidence.

I'm a big fan of Python lately but neither I nor Python community at large goes "you fucking scrub, use Python, fuck you, wtf are you doing, stop making broken progs for ppl and wasting your time, omg, obsolete shit you use" and instead highlight upsides of it like readability, plentiful modules, widespread use of it, etc. Meanwhile Rust community seems full of negative advertising in the tone of "fuck C, fuck C++, R…

I think what you're seeing is less the Rust community and more the community of computer users that have been forced to use C/C++ software for decades now. Up until Rust, there were many easy reasons why developers could justify their choice to use C/C++. And so users had to live with the frustrations of running code written in those languages because there really were few well-known alternatives.

Now Rust comes along with its safety claims (which are mostly true) and suddenly these computer users have what they believe is a legitimate complaint. They now see the frustrations with running C/C++ software as no longer facts of life but, instead, development externalities that users are forced to pay based on the decisions of the developers.

And so you have a bunch of people who've likely never written much in either C/C++ or Rust who are trumpeting Rust because they're sick of dealing with CVEs, segfaults and all the other 1970s baggage that the C-cosystem imposes. And it doesn't help that C/C++ developers tend to react defensively and take the advocacy as an impugnment of their developer honor. Saying "It's only inept C/C++ developers that write code with UB or memory safety issues. Disciplined developers can write safe C code!" just infuriates people even more since the weight of evidence suggests that any non-trivial C program will eventually have a bug or vulnerability of this kind. Humans make mistakes. That's an immutable fact that we need to take into account when relying on humans to do anything. Programming is a thing that is part of that anything. To err is human, to catch as many of those mistakes as possible is the compiler's job.

But I think both the Rust community and the Rust-resistant community should be wary of those trumpeting Rust who are part of neither of those groups. There are many good reasons to use Rust and some good reasons not to. Often times a hybrid Rust/C solution would be the best. We should be careful to try to take ego out of the decision making process as much as possible. And we should remember that when users are asking for Rust, what they're really asking for is an end to the pain that they've had to deal with. If it can be accomplished in some other way, then that works too.

Re: Why you should, actually, rewrite some of it in Rust

#258

Post by Dowwie »

_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

I came across this comment before your others. Initially, I thought you were an innocent bystander, and maybe you were, but man did that change quickly. You criticized Rust / C++ bare knuckle boxing but then immediately afterwards jumped into the ring.

Re: Why you should, actually, rewrite some of it in Rust

#259

Post by kazinator »

dbaupp wrote: post #256
kazinator wrote: post #239

Earlier quoted context omitted.

You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine. For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null ter…

Higher level constructs like iterators, references and smart pointers are all relatively easy to misuse. It is definitely possible to have safe abstractions like std::string's + and they're one reason why C++ is an improvement over C, but there's still many other dangerous edges that are nearly impossible for a human to keep track of at scale.

There are things in the C++ standard library that are not very well designed, yes.

For instance, erasing from some containers causes undefined behavior if iterators that were created before the deletion continue to be used.

Some of the various smart pointers for managing memory are not so smart; they have been redesigning new ones and deprecating old ones so many times now. It used to be "your code isn't exception safe: use auto_ptr, you dolt!". Then, "you idiot, don't use auto_ptr, use this instead" and so on.

You can avoid all that by defining your own classes that do just what you need, use only the safe stuff from the standard (like the aforementioned strings) and write yourself a perfectly memory-safe, leak-free C++ program.

Re: Why you should, actually, rewrite some of it in Rust

#260

Post by anarazel »

jeffdavis wrote: post #253
anarazel wrote: post #229

Earlier quoted context omitted.

> I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author. Why exactly is that? I'd have expected a C wrapper to take care of most of that? Are you concerned about the Datum native type C macros? Are you planning/hoping for this to be all safe, or is there going to be unsafety in the wrapper?

Creating a new module or UDF requires exporting new special symbols for V1 calling convention. Rust's hygenic macros don't let you do that. So defining a UDF has a bunch of boilerplate, unless I am missing something. Procedural macros should alleviate this, but it will be a while. I might just release and document the boilerplate needed. EDIT: Yes, I am trying to be mostly safe. I will see how close I can get for at…

> Creating a new module or UDF requires exporting new special symbols for V1 calling convention.

Right - but I don't think you need to do so. That'd only be required if you'd use language 'C' - why not instead use language 'rust'. That'll force a simple wrapper function which looks up and calls the real function, but that's fairly harmless, no? Might actually be good, because you can do some extra checks and conversions there.

Post reply on HN