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

261–270 of 300 posts

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

#261

Post by jeffdavis »

anarazel wrote: post #260
jeffdavis wrote: post #253

Earlier quoted context omitted.

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 conversi…

There are some extension APIs that demand C. But perhaps I dismissed the idea of plrust too quickly and there is room for both?

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

#262

Post by anarazel »

jeffdavis wrote: post #261
anarazel wrote: post #260

Earlier quoted context omitted.

> 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 conversi…

There are some extension APIs that demand C. But perhaps I dismissed the idea of plrust too quickly and there is room for both?

I'd say it'd be better to let PL handlers decide whether they can be used in those cases. IIRC those cases largely exist because you need to be able to deal with pointers which existing pls weren't able to...

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

#263

Post by dllthomas »

steveklabnik wrote: post #175
danenania wrote: post #172

Earlier quoted context omitted.

Is there anything that prevents this conversion of raw pointers to references from being automatable as well?

If C was able to encode Rust's semantics around references, you wouldn't need Rust in the first place. You might be able to get it to work sometimes for a very simple subset . I'd be extremely skeptical that it'd be very useful, though.

I agree with "sometimes, for a very simple subset" but I think there's a good chance that can still be very useful. A lot of uses just are super simple, and that may be obvious to the computer in cases that aren't obvious to the human. If we can remove the need for the human to reason about those, that can be a big help.

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

#264

Post by petters »

Manishearth wrote: post #68
petters wrote: post #23

Earlier quoted context omitted.

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

It's ... debatable. Heartbleed implemented their own memory management system (and had a bug in their use of it). This is pretty unusual even in C. It's extremely unusual in Rust, but who's to say that a similar implementation in Rust would come across the same challenges and implement their own memory management too? And write the same bug? Ultimately this kind of system would be unsafe code anyway, so Rust won't he…

Thank you for the clarification.

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

#265

Post by pjmlp »

fpgaminer wrote: post #234
sidlls wrote: post #177

Earlier quoted context omitted.

I mainly agree that Rust is more than about safety. I just wish these other features had a tenth of the vocal support as Safety. It's even worse here on HN, where the a certain group seem to thrive on blasting not-Rust, especially if that not-Rust is C or C++. I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety. It's terrible.

Criticism is just so much easier than constructive arguments. That's why it's rampant in communities, even HN. And controversial subjects (Bitcoin, health, food, Javascript) will magnify the problem. It's easy to find fault in C/C++. It's easy to parrot the Rust marketing. It's not so easy to actually have spent the time to learn and use Rust, let alone articulate the subtle ways that its design, taken as a whole, is…

The interesting bit is that it was already happening on the PC world, with C only being used for OS APIs on Windows and OS/2, but most people were actually using C++ (OWL, VCL, MFC), Turbo Pascal for Windows followed by Delphi, VB, Eiffel, Ada, Oberon, Component Pascal...

Then the UNIX FOSS, written mostly in C took over, and set us almost 20 years back in security and safety.

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

#266

Post by pjmlp »

akavel wrote: post #245
blub wrote: post #108

Earlier quoted context omitted.

I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many. Anybody who has the faintest clue about both languages should know that.

C is kinda small enough, that I imagine one can maybe have some chance at trying to hold the whole of it, including all nuances/warts, in one's head. Like, maybe even actually write a compiler for it. (See e.g. Dennis Ritchie, Fabrice Bellard.) With C++, good luck even reading and understanding The ISO C++ Standard. Not to say fully internalizing all possible interactions between all nuances. I presume not all of the…

> C is kinda small enough, that I imagine one can maybe have some chance at trying to hold the whole of it, including all nuances/warts, in one's head.

Anyone that is able to keep in mind the documented 200 cases of UB is my hero.

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

#267

Post by pjmlp »

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…

I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety.

This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.

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

#268

Post by blub »

pcwalton wrote: post #206
blub wrote: post #181

Earlier quoted context omitted.

I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.

Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifet... It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.

A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics.

From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.

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

#269

Post by pcwalton »

blub wrote: post #268
pcwalton wrote: post #206

Earlier quoted context omitted.

Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifet... It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.

A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics. From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.

It's worse than C because you can't have UAF in C without explicitly calling free (or a function that transitively calls free). In C++ freeing is implicit.

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

#270

Post by moomin »

tspiteri wrote: post #237
FRex wrote: post #176

Earlier quoted context omitted.

I've never seen Python or Lua community do that so far. But Python is its own animal (which IMO is only highlighting how good it is), it's not supplanting anything. Rust meanwhile both hates C and piggybacks on it (using LLVM, similar syntax, cited compatibility and coexistence with C). Lua is similar, no hate, its own animal, custom syntax, good in its niche (Python's niche seems to be literally everything not super…

I've never seen Python or Lua community do that so far. Back then, wasn't it readable Python versus unreadable Perl?

You have a point. Python was definitely pitched as a perl replacement. We forget because it pretty much won.

Lua has it's own problems, of course, but I don't see it as a language developed as a consequence of frustrations with another.

Post reply on HN