Why you should, actually, rewrite some of it in Rust • Hacker News Board

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

#281

Post by naasking » Thu, Jul 13, 2017, 4:57 PM UTC

steveklabnik wrote: post #274

rbehrends wrote: post #227

Earlier quoted context omitted.

> I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. And that's what I was referring to. BDDs inherently require Rc /Arc (as long as you want to be memory-safe, at least) and therefore incur significant overhead (reference counting is one of the most expensive forms of automatic memory management). I use BDDs as an example, because there's no way to work around…

> BDDs inherently require Rc /Arc "Zero-cost abstraction" means "You couldn't have coded it any better yourself." If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. Maybe Bjarne should have called it the "Zero additional-cost abstraction" instead; I think it'd clear the principle up a lot.

> If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math.

His contention is that languages with GC don't require reference count updates, and so manipulating the BDD graph is much cheaper in these languages since the resource accounting overhead is deferred by some non-deterministic time.

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

#282

Post by dbaupp » Thu, Jul 13, 2017, 5:02 PM UTC

kazinator wrote: post #259

dbaupp wrote: post #256

Earlier quoted context omitted.

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

Even the modernest pointers unique_ptr and shared_ptr are dangerous (use after free/move and, e.g., ease of data-racing in the data, respectively). The problems with them are relatively fundamental to C++ and its idioms. The classes you define will need to avoid using fundamental C++ features like references too: anything pointer-like can lead to problems (including `this`)

The "you (and the standard library, including the completely new parts) are holding it wrong" defence is tired, when it is so ridiculously easy to do so: it is okay and important to acknowledge that a tool is powerful but also has a pile of hard-to-avoid sharp edges.

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

#283

Post by pjmlp » Thu, Jul 13, 2017, 5:11 PM UTC

kazinator wrote: post #279

pjmlp wrote: post #278

Earlier quoted context omitted.

Not really, the part you are missing is that it is easier and cheaper not to have C or C++ compilers available at all.

No, what I mean that if those same people were running a C++ shop rather than a Java shop, they could be equally and just as effectively draconian in their enforcement.

Ah I get your point, but static analysers and sanitizers aren't able to find all unsafe issues, specially if binary dependencies are involved.

This is why on Solaris there is OS support via SPARC instructions to enforce bounds and valid pointer use, for example.

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

#284

Post by pjmlp » Thu, Jul 13, 2017, 5:25 PM UTC

naasking wrote: post #280

rbehrends wrote: post #249

Earlier quoted context omitted.

> Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your original claim. As you just said, you can use Rust's unsafe escape hatch to preserve your desired performance where it's critical and you haven't lost anything from C/C++, but you can still enjoy the safety benefits where unsafety is not needed. I'm not compari…

> The unsafe approach would be to do use an array representation, use indices instead of pointers, and roll your own garbage collector. Or manually remove unnecessary reference count updates whenever you can prove that they are unnecessary. Both of which cannot be easily hidden behind a safe zero-cost API. There are potentially many unsafe approaches, and possibly even some safe ones. > The entire Wirth family of lan…

> Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions.

Says someone that never wrote a single line of Eiffel.

That is what local variables defined as expanded classes are for.

    local
       array: expanded ARRAY[INTEGER];
    do
       array := >
       sorter.sort(array)
       ....
    end

> Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation.

Says someone that never wrote a single line of Modula-3.

    TYPE
       Time = RECORD
          seconds: INTEGER;
          milliseconds: [0..999]
       END; 

    PROCEDURE MyProc =
    VAR
       t: Time; (* Stack Allocated *)
    BEGIN
       t.seconds := 0;
       t.milliseconds := 0   
    END MyProc;

Being verbose is a virtue in large scale software development.

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

#285

Post by kibwen » Thu, Jul 13, 2017, 8:07 PM UTC

moomin wrote: post #270

tspiteri wrote: post #237

Earlier quoted context omitted.

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.

Lua was developed for legal reasons: huge tariffs on foreign software meant that Brazilian companies often found it cheaper to develop custom toolchains, which is what gave us Lua.

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

#286

Post by steveklabnik » Thu, Jul 13, 2017, 8:19 PM UTC

naasking wrote: post #281

steveklabnik wrote: post #274

Earlier quoted context omitted.

> BDDs inherently require Rc /Arc "Zero-cost abstraction" means "You couldn't have coded it any better yourself." If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. Maybe Bjarne should have called it the "Zero additional-cost abstraction" instead; I think it'd clear the principle up a lot.

> If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math. His contention is that languages with GC don't require reference count updates, and so manipulating the BDD graph is much cheaper in these languages since the resource accounting overhead is deferred by some non-deterministic time.

You can still write a GC in Rust and use it for those types.

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

#287

Post by Paul-ish » Thu, Jul 13, 2017, 9:13 PM UTC

pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> Runtime arithmetic overflow checks have saved me many times. Knowing I have this safety net I can be cavalier about using smaller integer types.

As a note to others, arithmetic checks doesn't happen in release builds unless you used something like checked_add, add "debug-assertions = true" to [profile.release], or use -C overflow-checks flag with the compiler.

https://github.com/nox/rust-rfcs/blob/master/text/1535-stabl...

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

#288

Post by Paul-ish » Thu, Jul 13, 2017, 9:22 PM UTC

dikaiosune wrote: post #85

ZoFreX wrote: post #72

Is it really the time, yet, to start advocating for rewrites in Rust? Worth considering for new projects, definitely. Using to write new components of existing projects, maybe. But rewriting existing work? I'm concerned if we start pushing that too much too early, the initial friction will burn people. You only get one first impression. For anyone who thinks "yes, now is the time" I have questions for you: Have you r…

I believe Firefox as of recent versions requires a Rust compiler to be available, and that's a pretty bread-and-butter application to have in your distro's package repository.

You should only need a rust compiler to compile Firefox.

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

#289

Post by dikaiosune » Thu, Jul 13, 2017, 10:50 PM UTC

Paul-ish wrote: post #288

dikaiosune wrote: post #85

Earlier quoted context omitted.

I believe Firefox as of recent versions requires a Rust compiler to be available, and that's a pretty bread-and-butter application to have in your distro's package repository.

You should only need a rust compiler to compile Firefox.

Most distributions require that packages in the repositories are built with tools from the distribution.

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

#290

Post by Manishearth » Fri, Jul 14, 2017, 4:57 AM UTC

blub wrote: post #104

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…

Some corrections: * option and result are also available in C++, the former is even standardised. * random numbers support is quite good. * C++ compilers will warn if not all members of an enum have been handled in a switch. It's also easy to assert/throw in the default case as a safety measure. * tuples are likewise supported * I believe something like your opaque types could be done with templates and tag classes i…

std::optional don't enforce exhaustiveness; you can get away with accidentally unwrapping it. In Rust this requires an explicit check or explicit call to unwrap()/expect().

To me, this is super important. But yeah, it's still a good thing to have!

IIRC there are TMP-implemented versions of this that are safer (though a bit ugly to use) though.