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

181–190 of 300 posts

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

#181

Post by blub »

pcwalton wrote: post #137
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.

I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.

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.

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

#182

Post by faragon »

fuwafuwa wrote: post #138
faragon wrote: post #115

Earlier quoted context omitted.

E.g. ABI compatibility, multi-platform support, tools, open source code base, community, etc.

ABI compatibility: Not really solved in C++ - see MSVC versus Mingw. If you're coming from the standpoint of using a Linux distro or BSD you enjoy a sanitized environment from the start. Multi-platform support: Pray that your project's build system makes it straightforward to get all the dependencies going on every platform. Pray that your dependencies are easy to access and of the correct version. Pray that the manu…

My point was explicitly about C, not C++. All these points are solved in C, decades ago.

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

#183

Post by steveklabnik »

FRex wrote: post #180
steveklabnik wrote: post #145

Earlier quoted context omitted.

In official Rust spaces, attacks like that are not allowed. We don't directly reference other languages in any official docs and such, to not promote this kind of attitude. It is true that we built Rust to address shortcomings of C and C++, some some form of crtitique has to happen. But many Rust programmers, and especially Rust leadership, will gladly say there's still some good reasons to write C and/or C++ today.…

There's critique (and I have lots towards both C and C++ but nothing fits my hobby better and all libs I like are in it and I know them the best so..) and there's just being downright stupid and insulting("stars aligning to write C", "humanly impossible to write C++", etc.). In any case Rust is still solidly on my list of things to learn to become a T-shaped person with lots of insight from different angles but it's…

I absolutely agree. Being stupid and insulting is not good, both in general and for the language. Not acknowledging other languages' successes means that we have blind spots for improvements, not to mention things like you've commented all over this thread.

As others have said, I think this is more of an HN issue than anything else; you won't see this kind of discourse in Rust-centric spaces. I know that's not super helpful, but I'm not a HN moderator, so...

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

#184

Post by Animats »

danenania wrote: post #167
Animats wrote: post #165

Earlier quoted context omitted.

That doesn't convert C to Rust. It compiles C into Rust as a target language, bugs and all. Raw pointers in C become raw pointers in Rust.

Yeah, I suppose the larger challenge is how to convert unsafe C to safe Rust.

Most of the problems revolve around "how big is it". (The three big problems in C are "how big is it", "who owns it", and "who locks it". C has no language constructs for any of those, while Rust does.)

If a C program works at all, there has to be some computable expression for the length of a C array. Code that uses an array passed as a pointer has to know how big the array is, even though C lacks a language construct for this. The problem is finding that expression. For many cases, it can be automatically inferred, especially if you have cross-module analysis and can see where the original array came from.

I once proposed an extension to C to allow expressing array size information.[1] Discussions indicated it was technically sound but politically too much trouble. It gives a hint, though, of how to approach size information in C. Instead of

    int read(int fd, char buf[], size_t len);
one would write

    int read(int fd, char& buf[len], size_t len);
Same generated code for the call, but now the source code contains size information, which could be used for subscript checking by the caller and callee. A serious C to Rust converter needs to be able to detect relationships like that.

It doesn't have to be 100% automatic. If the converter could knock off most of the easy cases (especially those involving strings), and accept hints on the hard ones, it could be usable.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

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

#185

Post by ameliaquining »

rbehrends wrote: post #156
anp wrote: post #81

Earlier quoted context omitted.

Can you be specific about which languages you include in the category of "fast and SAFE"?

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory- unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitat…

That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past.

That said, plenty of applications can easily afford to pay the runtime cost of a tracing garbage collector and don't need to be using Rust. (You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.) In general I tend to think of Rust as a better replacement for C++, and useful for approximately the same use cases.

I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it. I don't think I count techniques that aren't available in any language less obscure than Cyclone.

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

#186

Post by pjmlp »

sqeaky wrote: post #127
pjmlp wrote: post #123

Earlier quoted context omitted.

> I am riding on on the idiomatic C++11/14/17 train right now. How do you see it? Nowadays I only use C++ on hobby projects or when Java/.NET need some kind of integration work. To me it seems that as code bases grow organically, it will become very hard to get which code is in which ANSI version, specially problematic given some of the changes that took place between standard revisions.

At both of my jobs, I am working way too much, I am working in pre-C++11 codebases which now allow C++11. Both are working to for -Werror everywhere and that helps a huge amount, and we can try to get more warning listed and make broad but subtle changes to the codebases. At one place we are in a race before a tight deadline and at the other we are breaking a large monolith into smaller packages. At one place we impl…

Thanks for the overview.

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

#187

Post by cyphar »

ZoFreX wrote: post #118
steveklabnik wrote: post #110

Earlier quoted context omitted.

Totally! That's far different than "no major package manager accepting or even ready to accept programs written in Rust yet", though. Oh, I thought of something better than just the compiler: https://github.com/burntsushi/ripgrep#installation * homebrew * chocolatey * arch * gentoo * fedora * RHEL/CentOS * Nix All have at least one Rust program packaged :)

For RHEL/Centos/Fedora (the only ones there I would call "major") you have to enable a separate repo, which isn't really the same as being in the official repos.

Also openSUSE and SLES. Yes, we're still around and doing interesting stuff.

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

#188

Post by nine_k »

snakeanus wrote: post #15

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.

The runtime, of course. No GC, etc.

BTW Haskell has been used to write OS kernel modules: [1], [2]. It's still quite a bit cumbersome.

I also wonder why ATS language does not receive enough love in this area.

[1]: http://www.pfq.io/ [2]: https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has...

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

#189

Post by jacquesm »

sidlls wrote: post #177
fpgaminer wrote: post #75

Earlier quoted context omitted.

Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…

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.

It's actually harming Rust. And not just a little bit.

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

#190

Post by Rusky »

CalChris wrote: post #161
Rusky wrote: post #159

Earlier quoted context omitted.

Why is setjmp such a major issue for you? It's a C language feature, not a "real low level to the metal systems programming" requirement.

If you are calling C or assembly and there is any sort of processor exception, you need to establish a signal() handler and you will need setjmp/longjmp to re-establish a safe stack frame. Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.

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.

Post reply on HN