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

Rewrite Everything in Rust

robert.ocallahan.org

Post reply on HN
Print view View original

141–150 of 242 posts

Re: Rewrite Everything in Rust

#141

Post by daurnimator »

brandonbloom wrote: post #132
daurnimator wrote: post #80

Rust has major unsafeness around low memory that make it unsuitable in this libc type role. See: https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru... and https://lwn.net/Articles/644708/ Due to this issue that the rust authors seem unwilling to address, I fully recommend against rust for the precise roles it's intended to be good at.

From second link: > Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process. Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue. Excep…

Rust's OOM handler calls abort(). This kills the process, and cannot be caught.

i.e. to run rust code that uses the standard library without the chance of abort() on low memory, you need to run it in it's own process.

Re: Rewrite Everything in Rust

#142

Post by latenightcoding »

Avshalom wrote: post #66
latenightcoding wrote: post #37

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…

>We live in a C world and I don't see that changing any time soon. 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 th…

I see what you did there

Re: Rewrite Everything in Rust

#143

Post by kyllo »

kibwen wrote: post #123
gnu wrote: post #122

Rust is nice. But the article miss one important point. Modern software engineering is a collaborative effort (well, it has always been, afaik). I write code for others to understand. I find Rust code significantly hard to read (I am saying this as an experienced C/C++ programmer and as an intermediate haskeller). Yes, one can write write-only code in any language. I think it is extremely important to write code that…

And as a Rust and Python programmer, I find C++ hard to read (I can never shake the feeling that the ampersands are always in the wrong place), and I'm nearly hopeless at deciphering Haskell. :P I suppose this is just something that comes with experience.

Haskell syntax is really nowhere near as complex as C++'s or even Rust's. It's not indecipherable, it's just different and not C-like. It's in the same family as SML, OCaml and F# so if you learn one of those, the others come easily.

Re: Rewrite Everything in Rust

#144

Post by pjmlp »

kibwen wrote: post #139
pjmlp wrote: post #127

Earlier quoted context omitted.

It is available to VS 2015 Update 1 users.

I don't believe it is, unless something's changed. To quote MSDN: "The package currently contains checkers for the Bounds and Type profiles. Tooling for the Lifetime profile demonstrated in Herb Sutter’s plenary talk (video at https://www.youtube.com/watch?v=hEx5DNLWGgA ) will be made available in a future release of the code analysis tools." https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...

I thought that the NuGet package already had a few updates since December.

Re: Rewrite Everything in Rust

#145

Post by sgrove »

bluejekyll wrote: post #79
pcwalton wrote: post #47

Earlier quoted context omitted.

I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.

It's true. In my DNS code I have zero unsafe code. Though I did need to add some new unsafe code to the Rust OpenSSL library, but that's really because of the FFI to C. That too would be unnecessary if OpenSSL was rewritten in Rust.

What about binding to the OCaml implementation at https://nqsb.io/ ?

Re: Rewrite Everything in Rust

#146

Post by chipsy »

d0mine wrote: post #65
wspeirs wrote: post #35

Earlier quoted context omitted.

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?

The issue with is that if you substitute social norms with money; it is hard to return to social norms later I.e., if you start paying; you have to continue paying. Predictably Irrational http://whistlinginthewind.org/2013/01/15/predictably-irratio...

True of an individual company or business unit and its major tech decisions, but businesses ultimately die. Thus we have a world where Cobol coexists with Node.js - companies saddled with old software never pay for a new system until it's "beyond too late". But a company with a greenfield project can come in and use whatever hot, hyped-up thing is out there, and it usually in their direct interest if it's free, because at that point they probably aren't terribly concerned about software quality.

Re: Rewrite Everything in Rust

#148

Post by drewm1980 »

castratikron wrote: post #86
panic wrote: post #9

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…

>We need to have incentives for maintaining this foundational software. It's my opinion that contributing to free software is a public good, and so we should have state-funded employees whose full-time job is to work on this software. I think something like this is already done in places like France and Europe, but to my knowledge the majority of paid-for American contributions to FLOSS comes from corporations.

There is a lot of public funding of FLOSS software through universities. Unfortunately, the funding model doesn't work well for big projects or projects lasting more than a few years. A lot of great stuff is developed using public funds and then abandoned when the developer graduates.

Re: Rewrite Everything in Rust

#149

Post by mback00 »

IMO -- Better is to just write better tools for plain olde ANSI-C. We can build tools to check C as well as any other. Let's just not waste time on building further complexity into our toolset and look at building toolkits and best practice at the very flexible level of abstraction that Plain olde C provides. With the right tools and expertise, we can improve the world without the never ending whiz bang rewrite.

Re: Rewrite Everything in Rust

#150

Post by whyever »

jeffdavis wrote: post #128

"[Other safe languages] require complex runtime support that doesn't fit in certain contexts (e.g. kernels)." Complex runtimes are also unsuitable for libraries. If you write a great openssl replacement in Haskell, it's only useful for Haskell applications. Because nobody wants to link the Haskell runtime into many of the applications that use openssl. For widespread libraries, the choices are basically C, C++, and n…

You can provide C bindings for you Rust library.
Post reply on HN