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

151–160 of 242 posts

Re: Rewrite Everything in Rust

#151

Post by masklinn »

0xcde4c3db wrote: post #44
reality_czech wrote: post #12

Earlier quoted context omitted.

Have you even looked at the source code to glibc? It's stuffed full of macros and #ifdef hell. Not to mention symbol versioning, the use of gcc-specific compiler extensions, and ancient-UNIX-beard performance hacks. You'd have more success teaching a chimpanzee to play the violin, than automatically translating glibc into anything.

I've seen a lot of weird preprocessor (ab)use in GNU code. The coreutils true/false (of all programs to invoke clever preprocessor tricks...) has this gem: in true.c (all told, an 80-line file): /* Act like "true" by default; false.c overrides this. */ #ifndef EXIT_STATUS # define EXIT_STATUS EXIT_SUCCESS #endif false.c, of course, contains only: #define EXIT_STATUS EXIT_FAILURE #include "true.c" On my current system…

But BSD true doesn't support --version, how are you going to check your version of true without a locale-aware version string (and yes, gnu true is locale-aware, and contains 2k of strings including 48 encoding names and 36 format strings — 10 of which are duplicates, and for some reason refers to the SHA2 utilities)

(I dimly remember an essay about similar issue in a similar mainframe command (maybe in JCL?) taking a bunch of revisions to actually get right?)

Re: Rewrite Everything in Rust

#152

Post by kibwen »

pjmlp wrote: post #144
kibwen wrote: post #139

Earlier quoted context omitted.

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.

I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.

Re: Rewrite Everything in Rust

#153

Post by roca »

throwawyr424415 wrote: post #147

Doesn't modern C++, with smart pointers, auto, and the rest, cover most of the same ground rust does, and isn't the Rust community somewhat toxic, with activists pushing "Codes of Conduct" and other non-technical agendas?

With modern C++ you can still easily shoot yourself in the foot and trigger memory-unsafe behaviour.

Whatever your opinion of Codes of Conduct, lots of projects have them now. And IMHO not having a Code of Conduct encourages its own sort of toxicity.

Re: Rewrite Everything in Rust

#154

Post by kibwen »

kyllo wrote: post #143
kibwen wrote: post #123

Earlier quoted context omitted.

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.

Indeed, this isn't meant as a knock against Haskell in particular, merely an observation on unfamiliarity. :)

Re: Rewrite Everything in Rust

#155

Post by pjmlp »

kibwen wrote: post #152
pjmlp wrote: post #144

Earlier quoted context omitted.

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

I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.

Have you seen the CppCon presentation?

About 1% of the audience answered affirmatively to Herb's question about who was using some kind of static analysis tools.

Outside HN and Reddit circles, very few C and C++ developers, at least the typical enterprise ones, don't really care about such tools.

Back on my C++ days, just one company cared to pay for Insure++ and I was probably the only one using it.

This is way I am looking forward to use it eventually, but don't have high hopes for wider adoption from other C++ vendors.

I guess need to update to Update 2 when it goes to RTM ready.

Re: Rewrite Everything in Rust

#156

Post by nostrademons »

sgrove wrote: post #145
bluejekyll wrote: post #79

Earlier quoted context omitted.

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/ ?

Wouldn't that require pulling in the OCaml garbage collector? Much of the reason people use glibc or other low-level libraries rather than a managed runtime is so they don't need to link in a managed runtime.

Re: Rewrite Everything in Rust

#157

Post by XorNot »

nitrogen wrote: post #125
rubiquity wrote: post #18

Earlier quoted context omitted.

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…

If someone wants to pay me to rewrite glibc in Rust, I'd gladly do it, as I'm sure lots of other devs would. It's actually something I've thought about doing as a hobby, but there are a million other hobbies above it on the list.

What we need is a way to coordinate the effort I suspect. Given we have glibc as a standard interface, a site which matched up function tests with implementations and made it obvious where to jump in could build a decent community.

Re: Rewrite Everything in Rust

#158

Post by roca »

pjmlp wrote: post #155
kibwen wrote: post #152

Earlier quoted context omitted.

I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.

Have you seen the CppCon presentation? About 1% of the audience answered affirmatively to Herb's question about who was using some kind of static analysis tools. Outside HN and Reddit circles, very few C and C++ developers, at least the typical enterprise ones, don't really care about such tools. Back on my C++ days, just one company cared to pay for Insure++ and I was probably the only one using it. This is way I am…

Extra-lingual static analysis tools are OK at finding bugs. They're not good at proving the absence of whole classes of bugs; that is what we should be striving for, and what Rust and other languages can provide.

So what I'm looking for from Herb Sutter is not just a set of good guidelines and tools to check for them, but also a proof --- or at least an argument --- that if the tool finds no errors in a piece of code then that code cannot be the source of memory safety bugs.

Re: Rewrite Everything in Rust

#159

Post by GolDDranks »

throwawyr424415 wrote: post #147

Doesn't modern C++, with smart pointers, auto, and the rest, cover most of the same ground rust does, and isn't the Rust community somewhat toxic, with activists pushing "Codes of Conduct" and other non-technical agendas?

It's the opposite; the Rust community feels very welcoming, well-behaved and indeed – non-toxic.

Re: Rewrite Everything in Rust

#160

Post by Manishearth »

shmerl wrote: post #108
iherbig wrote: post #105

Earlier quoted context omitted.

Genuine question: What do virtual objects enable that cannot be done through the Trait system?

Problems that Rust can't now address are listed in that RFC. Such as sharing of fields between definitions for instance. Traits don't address that. See also these posts: * http://smallcultfollowing.com/babysteps/blog/2015/05/05/wher... * http://smallcultfollowing.com/babysteps/blog/2015/05/29/clas... * http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt... * http://smallcultfollowing.com/babysteps/blog/2015/…

Note that while many OOP patterns are hard to express in Rust, there are equivalent patterns that handle the use cases.

To give some context on those blog posts; they exist to figure out how to add single inheritance to Rust. One of the strongest arguments for single inheritance in Rust is "Servo and similar things need it to model the DOM". I.e; the strongest argument out there is that modelling cross-language things with languages that _do_ have single inheritance is hard.

That's not a very strong argument. That's a pretty niche use case (which Servo itself has moved past; we have a setup emulating inheritance that works pretty ok now).

So while I do agree that Rust can't model these patterns easily; I'm skeptical that that can be an issue for the large majority of Rust users.

Post reply on HN